출처 검증 리서치: HOW TO Onboard Binance

Decision Matrix

Source Map

• Binance Developer Docs: Binance Pay API: Authentication (binance-pay-authentication)
• 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. Merchant access

Merchant access is the decision point where public documentation must become an operating rule. In this package, it means API key creation depends on authorized Merchant Admin Portal access. The practical action is to confirm the merchant account and owner role before key creation. The unresolved edge is private business verification state, 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. Key custody

Key custody is the decision point where public documentation must become an operating rule. In this package, it means identity keys and secret keys carry production privileges. The practical action is to store secrets outside source control and evidence reports. The unresolved edge is organization-specific secret rotation 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.

3. Clock sync

Clock sync is the decision point where public documentation must become an operating rule. In this package, it means timestamp windows can reject otherwise valid signed requests. The practical action is to sync server time before integration testing. The unresolved edge is worker queue delay in production, 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. Signing fixture

Signing fixture is the decision point where public documentation must become an operating rule. In this package, it means signature generation should be tested independently from order logic. The practical action is to build a non-secret fixture that validates payload construction. The unresolved edge is language-specific serialization differences, 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. Create-order test

Create-order test is the decision point where public documentation must become an operating rule. In this package, it means order creation starts the payment workflow but is not final settlement evidence. The practical action is to record merchantTradeNo and prepayId without exposing customer private data. The unresolved edge is sandbox and production configuration differences, 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. Query-order reconciliation

Query-order reconciliation is the decision point where public documentation must become an operating rule. In this package, it means official order status should gate fulfillment. The practical action is to query by merchantTradeNo or prepayId before irreversible delivery. The unresolved edge is callback retry timing, 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 pause onboarding when keys, signatures or status query cannot be verified. The practical action is to fix custody and reconciliation before accepting live payments. The unresolved edge is manual exception approval owner, 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 business verification state
• organization-specific secret rotation policy
• worker queue delay in production
• language-specific serialization differences
• sandbox and production configuration differences
• callback retry timing
• manual exception approval owner

Practical Takeaway

A safe Binance Pay merchant onboarding path starts with merchant-account access, API identity key creation, request-signing verification and read-style order query testing before production fulfillment. Binance Pay authentication documentation says API keys are managed in the Merchant Admin Portal and should not be shared publicly; common rules specify HTTPS, HMAC-SHA512, timestamp, nonce, certificate serial and signature headers; order endpoints provide create and query workflows. The decision outcome is to complete key custody, clock sync, signing fixture, create-order test and query-order reconciliation before accepting live payments. 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.