Nghiên cứu đã kiểm chứng nguồn: Binance PAY Order Query
Nội dung bài viết đang hiển thị bằng bản gốc tiếng Anh đã xác minh. Bản dịch sẽ được thêm sau khi rà soát nguồn.
Verified Fact Boundary
1. Binance Pay common rules describe HTTPS transfer, JSON request and response format, UTF-8 encoding and HMAC-SHA512 signature requirements. 2. Binance Pay request headers include BinancePay-Timestamp, BinancePay-Nonce, BinancePay-Certificate-SN and BinancePay-Signature. 3. Binance Pay common rules state that request timestamps are processed within a narrow time window and include INVALID_TIMESTAMP as a business error. 4. Binance Pay Query Order can use either merchantTradeNo or prepayId when one of the two identifiers is present. 5. Binance Pay Query Order response fields include merchantId, prepayId, transactionId, merchantTradeNo, tradeType and status. 6. A merchant reconciliation checklist should not treat a local order row, a callback payload or a user screenshot as final payment evidence without querying the official order state.
Thu gọn
Decision Matrix
Bảng trong bài viết: cuộn ngang hoặc đặt tiêu điểm vào vùng bảng và dùng các phím mũi tên.
| Check | What it means | Practical action | Unknown to keep explicit |
|---|---|---|---|
| Identifier binding | merchantTradeNo and prepayId identify the payment workflow from different sides of the integration | store both identifiers and reconcile them before fulfillment | private merchant database uniqueness errors not visible in public docs |
| Signature layer | HMAC-SHA512 signing proves request construction only when timestamp, nonce and body are correct | verify header construction independently from order business logic | whether a production secret or IP allowlist is already compromised |
| Time window | timestamp drift can invalidate a signed request even when the body is correct | sync server time and log non-secret timestamp skew labels | clock drift during regional outage or worker queue delay |
| Status query | the query endpoint is the official source for order state checks | query status before irreversible fulfillment or refund logic | temporary state transitions between callback receipt and query response |
| Callback boundary | callbacks and push notifications need signature validation and business-state reconciliation | treat callbacks as signals that require confirmation | duplicate retries and delayed webhook delivery |
| Evidence hygiene | use identifiers, status, endpoint name and timestamp labels instead of secrets | redact certificate serials only when internal policy treats them as sensitive | merchant-specific logging policy |
| Stop rule | fulfillment should pause when signature, identifier or official status cannot be reconciled | hold fulfillment until official query state and local order state agree | manual support override conditions |
Source Map
- Binance Developer Docs: API Specification Common Rules (binance-pay-common-rules)
- Binance Developer Docs: Create Order V2 (binance-pay-create-order-v2)
- Binance Developer Docs: Query Order (binance-pay-query-order)
Control Notes
1. Identifier binding
Identifier binding is the decision point where public documentation must become an operating rule. In this package, it means merchantTradeNo and prepayId identify the payment workflow from different sides of the integration. The practical action is to store both identifiers and reconcile them before fulfillment. The unresolved edge is private merchant database uniqueness errors not visible in public docs, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, recovery guarantee, price implication, settlement guarantee or platform ranking.
2. Signature layer
Signature layer is the decision point where public documentation must become an operating rule. In this package, it means HMAC-SHA512 signing proves request construction only when timestamp, nonce and body are correct. The practical action is to verify header construction independently from order business logic. The unresolved edge is whether a production secret or IP allowlist is already compromised, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, recovery guarantee, price implication, settlement guarantee or platform ranking.
The operating test is also narrow. A public page can prove public wording.
3. Time window
Time window is the decision point where public documentation must become an operating rule. In this package, it means timestamp drift can invalidate a signed request even when the body is correct. The practical action is to sync server time and log non-secret timestamp skew labels. The unresolved edge is clock drift during regional outage or worker queue delay, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, recovery guarantee, price implication, settlement guarantee or platform ranking.
The operating test is also narrow. A public page can prove public wording.
4. Status query
Status query is the decision point where public documentation must become an operating rule. In this package, it means the query endpoint is the official source for order state checks. The practical action is to query status before irreversible fulfillment or refund logic. The unresolved edge is temporary state transitions between callback receipt and query response, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, recovery guarantee, price implication, settlement guarantee or platform ranking.
The operating test is also narrow. A public page can prove public wording.
5. Callback boundary
Callback boundary is the decision point where public documentation must become an operating rule. In this package, it means callbacks and push notifications need signature validation and business-state reconciliation. The practical action is to treat callbacks as signals that require confirmation. The unresolved edge is duplicate retries and delayed webhook delivery, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, recovery guarantee, price implication, settlement guarantee or platform ranking.
The operating test is also narrow. A public page can prove public wording.
6. Evidence hygiene
Evidence hygiene is the decision point where public documentation must become an operating rule. In this package, it means use identifiers, status, endpoint name and timestamp labels instead of secrets. The practical action is to redact certificate serials only when internal policy treats them as sensitive. The unresolved edge is merchant-specific logging policy, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, recovery guarantee, price implication, settlement guarantee or platform ranking.
The operating test is also narrow. A public page can prove public wording.
7. Stop rule
Stop rule is the decision point where public documentation must become an operating rule. In this package, it means fulfillment should pause when signature, identifier or official status cannot be reconciled. The practical action is to hold fulfillment until official query state and local order state agree. The unresolved edge is manual support override conditions, so the article keeps that edge explicit instead of turning it into a reward claim, licensing claim, approval claim, recovery guarantee, price implication, settlement guarantee or platform ranking.
The operating test is also narrow. A public page can prove public wording.
Known Unknowns
- private merchant database uniqueness errors not visible in public docs
- whether a production secret or IP allowlist is already compromised
- clock drift during regional outage or worker queue delay
- temporary state transitions between callback receipt and query response
- duplicate retries and delayed webhook delivery
- merchant-specific logging policy
- manual support override conditions
Practical Takeaway
A Binance Pay merchant integration should treat order creation, request signing and order query as separate controls. Binance Pay common rules require HTTPS, JSON, HMAC-SHA512 signatures, timestamp, nonce, certificate serial number and signature headers; the query order endpoint can retrieve status by merchantTradeNo or prepayId and returns fields such as transactionId, tradeType and status. The decision outcome is to reconcile merchantTradeNo, prepayId, timestamp window, signature result and status before fulfillment, rather than treating a local order record as payment evidence. The article stops at the evidence boundary. It helps the reader decide what to inspect next without converting public documentation into a promise that a private account, wallet, callback, policy framework, settlement route or liquidity position will work under every future condition.
Nguồn
03- API Specification Common Rules · developers.binance.com
- Create Order V2 · developers.binance.com
- Query Order · developers.binance.com