Исследование с проверкой источников: Binance PAY Order Query

Decision Matrix

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.