Phát hiện giao dịch, xác nhận chuỗi, liên kết đơn hàng và cung cấp dịch vụ là các bước riêng biệt. Xác minh đúng chuỗi, tài sản, người nhận và số tiền; áp dụng chính sách chấp nhận đã được ghi lại; và thực hiện đối soát theo cách idempotent. Chỉ một tham chiếu giao dịch, ảnh chụp màn hình hoặc nút trên trình duyệt không thể chứng minh rằng một đơn hàng cụ thể đã được thanh toán.
Tách sự kiện chuỗi khỏi sự kiện đơn hàng
Việc ví báo cáo rằng một giao dịch đã được gửi chỉ là bằng chứng về hành động của chính ví đó, không phải quyết định thanh toán đầy đủ. Backend nhận phải quan sát đúng mạng dự định, xác minh giao dịch thực tế và liên kết nó với một đơn hàng. Chỉ khi đó đơn hàng mới có thể áp dụng chính sách chấp nhận của mình. Cung cấp hạ tầng là một bước vận hành khác sau khi chấp nhận thanh toán.
Hãy giữ các chuyển trạng thái này rõ ràng trong cả mã nguồn và ngôn ngữ dành cho khách hàng. Một màn hình có thể hiển thị đang chờ, đã phát hiện hoặc đang xác nhận mà không gọi đơn hàng là đã thanh toán. Đừng để trình duyệt cung cấp số tiền được chấp nhận hoặc ghi đè trạng thái có thẩm quyền. Lưu báo giá do máy chủ tạo và các hướng dẫn của nó để việc đối soát sau này có thể được đánh giá dựa trên đơn hàng gốc thay vì giỏ hàng đang thay đổi.
Dùng quy tắc tin cậy theo từng chuỗi
Các mạng khác nhau mô tả độ tin cậy của giao dịch theo cách khác nhau. Hướng dẫn dành cho nhà phát triển của Bitcoin giải thích cách các nút chọn chuỗi có tổng bằng chứng công việc tích lũy nhiều nhất và cách các khối cạnh tranh có thể xuất hiện. Do đó, một giao dịch mới được thấy gần đây cần có chính sách về độ sâu xác nhận và khả năng thay đổi chuỗi. Không có một số lần xác nhận duy nhất phù hợp với mọi tài sản và rủi ro thương mại.
Tài liệu về proof-of-stake của Ethereum giải thích tính chung cuộc của checkpoint, trong khi Solana ghi lại các trạng thái cam kết đã xử lý, đã xác nhận và đã chung cuộc. Đừng dịch những thuật ngữ này một cách tùy tiện thành một số khối chung duy nhất. Hãy ghi lại quy tắc riêng của từng mạng, nguồn thông tin và hành vi trong trường hợp không chắc chắn. Người vận hành nên xác định ngưỡng chấp nhận dựa trên rủi ro thanh toán và giao hàng, không sao chép một con số từ một quy trình thanh toán không liên quan.
Xác minh tải trọng chuyển thực tế
Xác định người nhận, tài sản và số tiền trên đúng chuỗi. Thanh toán bằng token cần đúng danh tính token dự định, không chỉ là một giao dịch thành công tới một địa chỉ. Xác minh việc thực thi thành công có liên quan và bằng chứng chuyển khoản theo mô hình của chuỗi. Phân tích số tiền dạng số nguyên ở độ chính xác phù hợp của tài sản thay vì tin vào một số thập phân đã được định dạng do trình duyệt cung cấp.
Một hướng dẫn thanh toán phải luôn gắn với tuyến ban đầu của nó. Một giao dịch trên mạng khác, một token khác có cùng ký hiệu hoặc một tham chiếu giao dịch không liên quan không nên thỏa mãn hướng dẫn đó. Hồ sơ xác minh nên giải thích những gì đã được kiểm tra và lưu giữ bằng chứng cần thiết để xem xét quyết định. Hướng dẫn này mô tả các nguyên tắc đối soát thanh toán chung chứ không phải một triển khai dịch vụ cụ thể.
Làm cho liên kết đơn hàng không mơ hồ
Địa chỉ nhận cố định có thể nhận nhiều đơn hàng với số tiền tương tự nhau. Sự tồn tại của một giao dịch khớp không chứng minh khách hàng hoặc đơn hàng nào nên được ghi có. Hãy xác định phương thức liên kết trước khi chấp nhận thanh toán trực tiếp và bao gồm cả việc xử lý xung đột. Tham chiếu giao dịch do người dùng cung cấp vẫn cần được xác thực rằng cùng giao dịch đó chưa được gán ở nơi khác.
Hãy tưởng tượng hai hóa đơn có cùng số tiền trên cùng tuyến trong một khoảng thời gian chồng lấn. Một trình theo dõi thấy một giao dịch. Tự động đánh dấu cả hai là đã thanh toán là sai; chọn một mà không có đủ bằng chứng cũng không an toàn. Hãy để giao dịch chưa được phân bổ hoặc ở trạng thái xem xét cho đến khi chính sách của người vận hành có thể thiết lập một liên kết hợp lệ. Một kết quả khớp mơ hồ là một trạng thái cần xử lý, không phải lý do để tạo ra sự chắc chắn giả tạo.
Định nghĩa trạng thái chấp nhận bằng chứng muộn và thay đổi
Một quy trình thanh toán được hưởng lợi từ một tập hợp nhỏ các trạng thái rõ ràng, trong đó bằng chứng chuỗi tách biệt với quyết định chấp nhận đơn hàng. Bảng minh họa này giải thích các giai đoạn có thể có chứ không mô tả tên trạng thái của một dịch vụ cụ thể. Mỗi chuyển trạng thái nên có lý do đã được xác minh, và việc chấp nhận thanh toán nên vẫn tách biệt với việc cung cấp hạ tầng.
Bao gồm các giao dịch muộn, một phần và vượt mức, hết hạn báo giá và dữ liệu chuỗi tạm thời không khả dụng. Việc hết hạn không làm một giao dịch thực sự biến mất. Một khoản thanh toán muộn có thể cần được xem xét thay vì tự động chấp nhận hoặc từ chối. Nếu một sự kiện chuỗi đã quan sát trước đó thay đổi, hãy đánh giá lại trạng thái theo chính sách đã ghi lại thay vì coi mọi thông báo của trình theo dõi là sự thật không thể đảo ngược.
| Trạng thái minh họa | Ý nghĩa | Quyết định tiếp theo |
|---|---|---|
| Đang chờ | Chưa có giao dịch hợp lệ đã xác minh | Tiếp tục quan sát hóa đơn hợp lệ |
| Đã phát hiện | Đã quan sát giao dịch liên quan | Kiểm tra độ tin cậy chuỗi và liên kết |
| Đang xác nhận | Chưa đáp ứng quy tắc chấp nhận | Quan sát cho đến khi chính sách cho phép quyết định |
| Xem xét | Bằng chứng muộn, một phần hoặc mơ hồ | Giải quyết theo chính sách của người vận hành |
| Đã chấp nhận | Thanh toán đã xác minh và đối soát | Chuyển sang quy trình cung cấp riêng |
Làm cho thử lại an toàn và có thể quan sát
Các trình theo dõi và tác vụ đối soát sẽ thử lại sau khi kết nối bị gián đoạn hoặc tiến trình khởi động lại. Sử dụng một danh tính giao dịch ổn định, chẳng hạn như chuỗi và mã giao dịch hoặc mã chuyển khoản phù hợp, để ngăn ghi có trùng lặp. Lưu giữ tiến độ và quyết định để cùng một sự kiện có thể được xử lý lại mà không cung cấp dịch vụ thứ hai hoặc thay đổi báo giá đã được chấp nhận.
Phân biệt kết quả không xác định với thao tác thất bại. Nếu một yêu cầu hạ nguồn hết thời gian chờ, hãy kiểm tra kết quả có thẩm quyền của nó trước khi gửi lại. Lưu giữ hồ sơ bền vững về các hành động đã được chấp nhận và không chắc chắn. Hạn chế quyền truy cập vào token đơn hàng và bằng chứng nội bộ trong khi vẫn giữ đủ thông tin để điều tra một khoản thanh toán bị tranh chấp. Độ tin cậy ở đây là về các quyết định có thể lặp lại, không phải một hiệu ứng hoạt hình mượt mà trong quy trình thanh toán.
Biết đơn hàng đang chờ vẫn cần gì
Một đơn hàng có thể vẫn đang chờ xử lý vì giao dịch chưa được quan sát, chưa đạt độ tin cậy chuỗi cần thiết hoặc việc liên kết với hóa đơn cần được xem xét. Hãy giữ hóa đơn và tham chiếu giao dịch công khai, kiểm tra các quy tắc chấp nhận đã nêu và sử dụng quy trình hỗ trợ dự định của đơn hàng. Việc cập nhật trạng thái bị chậm, tự nó, không phải lý do để gửi thêm một khoản thanh toán khác.
Làm theo hướng dẫn và trạng thái đã xác minh cho đúng đơn hàng thực tế. Xác nhận thanh toán nên nêu rõ việc chấp nhận giao dịch đã được đối soát, trong khi việc cung cấp dịch vụ có một trạng thái riêng. Giữ token truy cập riêng tư và bí mật ví ngoài các yêu cầu hỗ trợ.
Danh sách kiểm tra thực tế của bạn.
- Lưu báo giá do máy chủ tạo ở dạng bất biến.
- Xác minh chuỗi, người nhận, tài sản và số tiền dạng số nguyên.
- Ghi lại các quy tắc chấp nhận riêng theo từng chuỗi.
- Xử lý xung đột địa chỉ cố định mà không đoán mò.
- Ngăn ghi có trùng lặp và gửi lại thử không an toàn.
- Kiểm thử các trường hợp muộn, một phần, sai tuyến và bằng chứng thay đổi.
Những chi tiết quan trọng.
Một mã giao dịch có đủ để xác nhận thanh toán không?+
Không. Hãy xác minh giao dịch trên đúng chuỗi dự định, dữ liệu tải và độ tin cậy của nó, sau đó xác lập rằng nó thuộc về đơn hàng và chưa được ghi có trước đó.
Mọi mạng có thể dùng cùng một ngưỡng xác nhận không?+
Không. Các mạng thể hiện các mô hình độ tin cậy và tính chung cuộc khác nhau. Người vận hành phải xác định và kiểm thử một chính sách chấp nhận phù hợp với từng tuyến.
Thanh toán đã xác nhận có nghĩa là máy chủ đã được cung cấp không?+
Không. Chấp nhận thanh toán và cung cấp dịch vụ là các sự kiện quy trình riêng biệt. Hãy truyền đạt trạng thái cung cấp từ quy trình có thẩm quyền riêng của nó.
Đến nguồn.
Các tài liệu tham khảo này hỗ trợ các khái niệm kỹ thuật trong hướng dẫn này. Hãy theo dõi tài liệu hiện hành trước khi thay đổi hệ thống sản xuất.
- Hướng dẫn dành cho nhà phát triển Bitcoin: Hành vi blockchain developer.bitcoin.org
- Ethereum: Proof of stake và tính chung cuộc ethereum.org
- Solana: Cam kết trạng thái RPC solana.com
Hướng dẫn biên tập bởi SwissOctet. Các ví dụ chỉ mang tính minh họa. Thông số dịch vụ, tùy chọn có sẵn và điều kiện hợp đồng phải được xác minh riêng.