面向 BNB 和 BEP-20 支付的 Binance Smart Chain API

如果你搜索的是「Binance Smart Chain RPC」，你大概期望得到的是一个节点 URL。docs.bnbchain.org 上的官方文档列出了公共 JSON-RPC 端点，它们确实能用。但它们把困难的部分留给了你。一个原始的 RPC 连接理解的是 eth_call 和 eth_sendRawTransaction；ABI 编码和 nonce 管理都发生在你的代码里，密钥处理也是。公共端点在负载下还会大幅限速，而这恰恰是你的支付系统最需要它们的时候。

Chaingateway 处于更高的一层。你告诉 API 要发送哪种代币、多少数量、发给谁。它负责构建交易并广播到网络；每一笔通过 API 创建的交易，包括哈希，都列在 GET /api/v2/bsc/transactions 下，你可以直接把用户导向 BscScan。

这个权衡是坦诚的：如果你需要任意的合约调用或归档深度的查询，运行一个节点或使用 RPC 提供商。如果你需要的是支付——也就是收款和付款——REST 层能省去你原本要自己编写和维护的大部分代码。

自 2025 年 6 月 30 日 Maxwell 硬分叉以来，BSC 的目标出块时间是 0.75 秒，gas 也一直保持低廉，在 BscScan 追踪器上通常为 0.1 到 1 gwei。标准的 BEP-20 转账消耗 50,000 到 65,000 gas，按这个价格计算只是几分之一美分。

链上事实变化很快，因此下面给出更完整、带有日期的数字。截至 2026 年 7 月初：

目标出块间隔为 0.75 秒。这是 2025 年 6 月 30 日 Maxwell 硬分叉设定的，BscScan 在激活后不久测得平均约 0.8 秒。2025 年早些时候，Lorentz 硬分叉已经把原本 3 秒的间隔减半到 1.5 秒，因此 BSC 在一年之内把出块时间缩短到了四分之一。

Gas 便宜且一直保持便宜。BscScan 的 gas 追踪器在整个 2026 年一直徘徊在 0.1 到 1 gwei 之间，2026 年 3 月的日均值约为 0.63 gwei。标准的 BEP-20 转账消耗大约 50,000 到 65,000 gas，按这个价格计算大约是 0.00004 BNB。在向客户报出手续费之前请自行核实当前 BNB 价格，但这个结果多年来一直停留在几美分以内的低位。

对收银页面而言，实际结果是这样的：客户的 USDT 转账大约一秒内就会进入某个区块，再经过几个区块（总共几秒钟），你就可以为订单入账。相比之下，以太坊主网仅一个 slot 就需要 12 秒。

每一个标准 BEP-20 合约都能正常工作。USDT、USDC 和 DAI 开箱即用，金额以代币单位而非原始最小单位表示。如果你发行了自己的代币，把它的合约地址传给同一个接口，它的表现会和其他代币一样。由于 API 在各链上是一致的，你为 BSC 编写的代码，只需在 URL 中替换链名段，就能同样运行在 Ethereum、Polygon 或 Arbitrum 上。

BSC 的手续费远低于以太坊主网，这在你处理大量小额付款而非少数大额付款时尤为重要。亚秒级的出块时间让收银流程保持流畅。围绕 PancakeSwap 的 DeFi 生态为 BEP-20 代币提供了深厚的流动性，这条网络多年来一直承载着高日活跃用户量，因此它的故障模式已被充分了解，工具链也很成熟。

BSC 上的支付集成遵循一个循环：

1. 为每位用户提供一个存款地址。如果你的系统已经在管理密钥，可以通过 POST /api/v2/bsc/addresses/import 注册它们。
2. 为该地址挂接一个 Webhook。设置只需几分钟，Webhook 指南中有说明。
3. 客户向该地址发送 USDT。转账大约一秒内进入某个区块，Chaingateway 会把解码后的事件 POST 到你的接口。
4. 你的服务器验证 HMAC 签名并为账户入账。这就是全部流程。

在生产环境中，有三个细节把一个演示项目和一个可以放心不管的系统区分开来。

第一个是地址映射。为每个客户或每个订单存储一行数据：你的内部 ID、存款地址、创建日期。当 Webhook 到达时，payload 中的接收地址就是你的查找键。在地址列上建立唯一索引，意味着无论你周围的代码怎么变化，一笔存款都永远不可能被入账给两个客户。

第二个是幂等性。投递并非严格恰好一次：你通过 API 重新发送的一条失败通知会完整地再次到达。用唯一约束记录每一笔已处理存款的交易哈希，让数据库拒绝重复项。能在同一事件到达三次时仍保持正确的入账逻辑，正是「重发机制保护你」和「重发机制让你多付」之间的区别。

第三个是确认策略。Webhook 告诉你转账已进入某个区块。在 0.75 秒的出块速度下，再等十个区块也远低于十秒，因此为求一点安全边际而等待，在用户体验上几乎不花任何代价。对于一笔 5 USDT 的数字商品购买，收到通知即入账是一个合理的业务决策。对于一笔 50,000 USDT 的存款，多等几秒并用 GET /api/v2/bsc/transactions/{txid} 重新核实交易，再释放任何东西。

存款也会随时间在许多地址上累积。常见的应对方式是定期清扫：一个定时任务，使用同一个 POST /api/v2/bsc/transactions/bep20 调用，把 from 设为存款地址，将累积余额发送到你的资金库钱包。每个被清扫的地址都需要一点点 BNB 用于 gas，在亚 gwei 价格下这几乎可以忽略不计。

如果你的接口曾经无法访问，被错过的投递并没有丢失：GET /api/v2/bsc/webhooks/notifications/failed 列出它们，POST /api/v2/bsc/webhooks/notifications/{id}/retry 可以逐条重新发送。为了对账，你也可以列出 API 发送给你的一切：

curl https://app.chaingateway.io/api/v2/bsc/webhooks/notifications \
  -H "Authorization: Bearer $CHAINGATEWAY_API_KEY"

这一个接口，把「我们是不是漏掉了一笔存款？」从一张支持工单变成了一次与你自己数据库的差异比对。

提现值得和存款同样的细心，因为这里的一个 bug 会把钱发出去，而不是漏收进来。

发送前先校验

流程从 API 调用之前就开始了。在用户提交目标地址的那一刻就校验它：正确的长度、0x 前缀，以及在存在大小写混合字母时的 EIP-55 校验和。校验和失败意味着拼写错误，在表单中捕获它不花任何代价，而在广播之后再发现则无法挽回。API 会在构建交易之前拒绝格式错误的地址，但校验和检查需要你自己来做——等到 API 给出响应时，用户往往已经离开了页面。

在数据库中追踪每一笔付款

在发送之前先把这笔付款写入你的数据库。每笔付款一行数据，附带一个状态列：queued、sent、confirmed。一个工作进程取出状态为「排队中」的行，每行恰好调用一次 POST /api/v2/bsc/transactions/bep20，并把 API 返回的响应立即存储在旁边。交易哈希——你的凭证——会出现在 GET /api/v2/bsc/transactions 中，这是通过 API 创建的一切内容的列表。把它作为一个 BscScan 链接展示给用户，他们就能自行追踪自己的提现确认情况，这能悄悄消除这一类别中最常见的支持工单。

处理超时

真正重要的失败情形是超时。如果你的 API 调用超时，你无法确定转账是否已经发出去。不要凭直觉盲目重试。先检查 GET /api/v2/bsc/transactions 和你自己的记录，只有在确信什么都没有广播出去时才重新发送。由于付款是从热钱包发出的，请在发送地址上保留一份 BNB 浮动余额用于 gas；按当前 BSC 价格，一次小额充值就能覆盖数千笔转账，因此这是每月一次的例行事务，而不是运维风险。

本页每个接口只需加一个请求头，就能运行在 BSC 测试网上：

X-Network: testnet

不需要第二个账户，不需要单独的 API 密钥，除这个请求头外代码也无需改动。测试用 BNB 可以从 BNB Chain 官方水龙头免费获取，因此你可以在不动用真实资金的情况下，把整个循环——从创建地址、经过存款 Webhook 到付款——完整演练一遍。地址格式和交易机制与主网完全相同。

值得做的是那种「糟糕」的演练：在 Webhook 接口关闭时发送一笔存款，恢复接口后，再从失败列表中重新发送投递（POST /api/v2/bsc/webhooks/notifications/{id}/retry），观察它成功到达。通过对自己的接口重放一条通知来确认你的幂等性处理是否生效。在测试网上花十分钟刻意测试各种失败场景，能省下主网上一次事故复盘的时间。当一切都通过时，删除该请求头，同一份代码就已经上线。

Webhook 接口是通往你账务系统的一扇门，应该以此对待它。

在解析任何其他内容之前先验证签名。在个人资料设置中设置一个私密密钥；从那时起，Chaingateway 会在每条通知中发送一个 X-Signature 请求头——对 payload 的 txid 做 HMAC-SHA256 并以该密钥为键，再用 base64 编码。你的服务器根据收到的 txid 重新计算，并以恒定时间比较。校验失败的请求返回 4xx，不做任何进一步处理，无论其 payload 看起来多么可信。具体机制及验证代码见 Webhook 指南。

另一个独立的锁守护着反方向：在账户面板中，你可以把 API 密钥限制在自己服务器的 IP 地址范围内。这份白名单保护的是 API 访问权限——泄露的密钥在其他任何地方都无法转移资金——而不是 Webhook 接口，因此它是签名验证的补充，而不是替代。

重放是仅靠 HMAC 无法阻止的攻击，因为一条被记录下来的有效通知本身依然有效。你的幂等性约束堵上了这个漏洞：已经入账过的交易哈希会被确认但不再处理。只通过 HTTPS 提供该接口，并让 Webhook URL 不携带任何密钥，因为 URL 会出现在你无法控制的系统日志里。

任何集成迟早都会遇到错误，API 会以普通的 HTTP 状态码报告它们，因此你现有的错误处理模式可以直接适用。

401 表示 Bearer 令牌缺失、过期或错误；检查 Authorization 请求头以及你仪表盘中的密钥。4xx 范围内的校验失败，比如地址格式错误或字段缺失，会附带一个说明如何修正的 JSON 响应体。不要重试这些情况：在 payload 改变之前，相同的请求会以相同的方式再次失败。

请求和地址的限额取决于你的套餐；如果你在日常操作中经常触及限额，定价页面列出了限额更高的套餐。服务器端的 5xx 错误和超时对读请求来说可以放心重试。对于发送操作，请套用付款部分提到的超时规则：在再次提交之前先确认没有任何内容被广播出去。

把完整的响应体连同你自己的请求记录一起存下来。当有问题需要支持团队关注时，这样的配对能在被问出来之前回答大多数问题。每个接口的状态码和错误结构记录在 API 参考文档中。

不少团队运行 BSC 完整节点只是为了一个目的：监控存款、广播付款。这个节点需要花费真金白银和精力。存储需求以 TB 级 NVMe 计量，没有快照的话初始同步要花上好几天，仅 2025 年就带来了两次硬分叉——Lorentz 和 Maxwell，每一次都要求在截止日期前完成客户端升级。错过一次，你的节点就会停止跟上链的进度，对支付系统来说，这意味着存款会悄无声息地停止到账。

如果节点的存在完全是为了支付，迁移路径很短。用 POST /api/v2/bsc/addresses/import 导入你现有的密钥，把 eth_getLogs 轮询循环替换为 Webhook 通知，把付款代码指向 POST /api/v2/bsc/transactions/bep20。让两套系统并行运行一周并比对结果；通知列表能把这次比对变成一次查询，而不是一个项目。然后下线该节点，收回硬件预算。

如果你想保留一个节点，或者正在决定是否要从头搭建一个，我们关于搭建 Binance Smart Chain 节点的指南会诚实地介绍硬件、同步和维护方面的内容。这两种方式也可以结合使用：一些团队保留一个节点用于归档查询和合约调用，同时把支付流量通过 API 路由，因为 API 的 Webhook 层正是那部分真正难以自行重建的东西。

Chaingateway 的 BSC 接口上，大多数团队采用两种模式之一。第一种是接受付款：商店或 SaaS 为每笔订单生成一个存款地址，等待 Webhook 后发货，结算只需几秒，而不是几个银行工作日。第二种是规模化的钱包运营：交易所和平台通过同样这几个接口，监控数千个用户地址的存款并处理提现。

同样这些构建模块还能覆盖代币发行（把空投和归属付款脚本化为 BEP-20 转账）、原本电汇要花上好几天的跨境转账、订阅计费的周期性付款，以及需要在交易一确认就立即感知的 DeFi 产品。

套餐及其限额列在定价页面上。每个新账户都以免费的 7 天试用开始，因此你可以在付费之前完成整个 BSC 集成。