平台对比

Binance Pay 与 Coinbase 支付 Webhook 签名和对账控制对比

4 分钟

已验证事实边界

1. Binance Pay Merchant API common rules describe HTTPS transfer, JSON payloads and signature checking for API requests and push notification signatures. 2. Binance Pay common rules list timestamp, nonce, certificate serial number and signature headers for request signing. 3. Binance Pay notification documentation says failed notification processing can trigger retry behavior and expects an HTTP 200 OK response with a success body. 4. Coinbase payment documentation describes Payments APIs and payment workflow surfaces for application developers. 5. Coinbase payment documentation is a separate payment stack from Binance Pay Merchant API documentation. 6. A merchant integration must reconcile event identity, signature validity where documented, retry handling and order lookup before treating a callback as final settlement evidence.

收起完整分析

决策矩阵

文章表格:可横向滑动,或聚焦表格区域后使用方向键。

CheckWhat it meansPractical actionUnknown to keep explicit
Signature algorithmprovider-specific signature construction decides whether a callback is authenticverify the exact documented algorithm before parsing business stateprovider-side key rotation timing
Timestamp windowfreshness checks reduce replay risk but depend on clock disciplinesync clocks and log skew without storing secretstransient regional latency
Event identityorder, subscription and notification identifiers are not interchangeablebind each callback to the expected merchant order or subscriptionduplicate event delivery
Retry idempotencywebhook retries can replay the same business eventmake update handlers idempotent before returning successpartial processing before crash
Order lookupa callback is not a substitute for a separate order-status readbackconfirm final state through the provider-supported lookup pathprovider incident detail
Secret handlingwebhook secrets and signing keys prove authenticity but increase breach impactstore only hashed evidence and rotate on exposuremerchant portal-only configuration
Stop rulestop when signature, timestamp, event ID or order lookup disagreeshold fulfillment until reconciliation is coherentsupport-only settlement dispute detail

来源地图

  • Binance Developer Docs:Binance Pay Merchant API Specification Common Rules(binance-pay-common)
  • Binance Developer Docs:Share Account ID Notification(binance-pay-share-webhook)
  • Coinbase Developer Platform:Payments Overview(coinbase-payments-overview)

控制说明

1. Signature algorithm

这一项要求读者先把公开来源翻译成操作规则。这里的含义是:provider-specific signature construction decides whether a callback is authentic。可执行动作是:verify the exact documented algorithm before parsing business state。仍然未知的是:provider-side key rotation timing。因此本文不会把未知部分包装成收益承诺、牌照承诺、审批保证、恢复保证、结算保证、可用性保证、价格暗示或平台排名。

2. Timestamp window

这里的含义是:freshness checks reduce replay risk but depend on clock discipline。可执行动作是:sync clocks and log skew without storing secrets。仍然未知的是:transient regional latency。

操作测试也必须很窄。这就是本节保留边界的原因。

3. Event identity

这里的含义是:order, subscription and notification identifiers are not interchangeable。可执行动作是:bind each callback to the expected merchant order or subscription。仍然未知的是:duplicate event delivery。

操作测试也必须很窄。这就是本节保留边界的原因。

4. Retry idempotency

这里的含义是:webhook retries can replay the same business event。可执行动作是:make update handlers idempotent before returning success。仍然未知的是:partial processing before crash。

操作测试也必须很窄。这就是本节保留边界的原因。

5. Order lookup

这里的含义是:a callback is not a substitute for a separate order-status readback。可执行动作是:confirm final state through the provider-supported lookup path。仍然未知的是:provider incident detail。

操作测试也必须很窄。这就是本节保留边界的原因。

6. Secret handling

这里的含义是:webhook secrets and signing keys prove authenticity but increase breach impact。可执行动作是:store only hashed evidence and rotate on exposure。仍然未知的是:merchant portal-only configuration。

操作测试也必须很窄。这就是本节保留边界的原因。

7. Stop rule

这里的含义是:stop when signature, timestamp, event ID or order lookup disagrees。可执行动作是:hold fulfillment until reconciliation is coherent。仍然未知的是:support-only settlement dispute detail。

操作测试也必须很窄。这就是本节保留边界的原因。

仍需明确的未知项

  • provider-side key rotation timing
  • transient regional latency
  • duplicate event delivery
  • partial processing before crash
  • provider incident detail
  • merchant portal-only configuration
  • support-only settlement dispute detail

实用结论

Binance Pay 与 Coinbase 支付 Webhook 都通过带签名的事件回调推动商户状态变化,但不应被实现成同一套控制。Binance Pay 文档定义了 HMAC-SHA512 请求和通知签名、timestamp 与 nonce header、HTTPS callback 和通知处理失败后的 retry 行为;Coinbase 支付 Webhook 文档提供订阅管理,并暴露用于 webhook signature verification 的 secret。实用结论是:商户把支付状态标记为最终状态前,应先核验 signature、timestamp freshness、event identity、retry idempotency、order lookup 和非秘密对账日志。 本文停在证据边界内,帮助读者决定下一步核验什么,而不是把公开文档改写成私人账户、钱包、回调、政策框架、结算路径或流动性头寸在任何未来条件下都能成功的承诺。

来源与证据

03
  1. Binance Developer DocsBinance Pay Merchant API Specification Common Rules · developers.binance.com
  2. Binance Developer DocsShare Account ID Notification · developers.binance.com
  3. Coinbase Developer PlatformPayments Overview