Binance Smart Chain API for BNB and BEP-20 Payments

If you searched for "Binance Smart Chain RPC", you probably expected a node URL. The official docs at docs.bnbchain.org list public JSON-RPC endpoints, and they work. But they leave the hard part to you. A raw RPC connection understands eth_call and eth_sendRawTransaction; ABI encoding and nonce management happen in your code, and so does key handling. Public endpoints also throttle aggressively under load, which is exactly when your payment system needs them most.

Chaingateway sits one layer higher. You tell the API which token to send, how much and to whom. It builds the transaction and broadcasts it to the network; every transaction created through the API is listed, hash included, under GET /api/v2/bsc/transactions, so you can link your users straight to BscScan.

The trade-off is honest: if you need arbitrary contract calls or archive-depth queries, run a node or use an RPC provider. If you need payments, meaning deposits in and payouts out, the REST layer removes most of the code you would otherwise write and maintain yourself.

BSC has targeted 0.75-second blocks since the Maxwell hardfork on June 30, 2025, and gas has stayed cheap, typically 0.1 to 1 gwei on BscScan's tracker. A standard BEP-20 transfer runs 50,000 to 65,000 gas, which at those prices works out to a fraction of a cent.

Chain facts age quickly, so here are the fuller figures with dates attached. As of early July 2026:

The block interval target is 0.75 seconds. The Maxwell hardfork set it on June 30, 2025, and BscScan measured an average of about 0.8 seconds shortly after activation. Earlier in 2025 the Lorentz hardfork had already halved the old 3-second interval to 1.5 seconds, so BSC quartered its block time within a single year.

Gas is cheap and has stayed cheap. BscScan's gas tracker has hovered in the 0.1 to 1 gwei range through 2026, with a daily average around 0.63 gwei in March 2026. A standard BEP-20 transfer consumes on the order of 50,000 to 65,000 gas, which at those prices works out to roughly 0.00004 BNB. Check the current BNB price yourself before you quote fees to customers, but the result has sat in the low cents for years.

For a checkout page the practical consequence is this: a customer's USDT transfer is in a block within about a second, and after a handful of additional blocks, a few seconds in total, you can credit the order. Compare that with Ethereum mainnet, where a slot alone takes 12 seconds.

Every standard BEP-20 contract works. USDT, USDC and DAI run out of the box, with amounts in token units rather than raw base units. If you have launched your own token, pass its contract address to the same endpoint and it behaves like any other. Because the API is identical across chains, the code you write for BSC also runs against Ethereum, Polygon or Arbitrum once you swap the chain segment in the URL.

Fees on BSC sit far below Ethereum mainnet, which matters when you process many small payments rather than a few large ones. Sub-second block times keep checkout flows snappy. The DeFi ecosystem around PancakeSwap gives BEP-20 tokens deep liquidity, and the network has carried high daily active usage for years, so its failure modes are well understood and its tooling is mature.

A payments integration on BSC follows one loop:

1. Give each user a deposit address. If your system already manages keys, register them with POST /api/v2/bsc/addresses/import.
2. Attach a webhook to the address. Setup takes a few minutes and is described in the webhooks guide.
3. The customer sends USDT to the address. The transfer lands in a block within about a second, and Chaingateway POSTs the decoded event to your endpoint.
4. Your server verifies the HMAC signature and credits the account. That is the whole flow.

In production, three details separate a demo from a system you can leave alone.

The first is the address mapping. Store one row per customer or per order: your internal ID, the deposit address, the creation date. When a webhook arrives, the recipient address in the payload is your lookup key. A unique index on the address column means a deposit can never be credited to two customers, no matter how your code around it changes.

The second is idempotency. Delivery is not exactly-once: a failed notification you re-send through the API arrives again in full. Record the transaction hash of every processed deposit with a unique constraint, and let the database reject duplicates. Crediting logic that survives the same event arriving three times is the difference between a redelivery mechanism that protects you and one that double-pays.

The third is a confirmation policy. A webhook tells you the transfer is in a block. With 0.75-second blocks, ten further blocks arrive in well under ten seconds, so waiting for a small safety margin costs almost nothing in user experience. For a 5 USDT digital purchase, crediting on the notification is a reasonable business decision. For a 50,000 USDT deposit, wait a few seconds longer and re-check the transaction (GET /api/v2/bsc/transactions/{txid}) before you release anything.

Deposits also pile up across many addresses over time. The usual answer is a periodic sweep: a scheduled job that sends accumulated balances from deposit addresses to your treasury wallet, using the same POST /api/v2/bsc/transactions/bep20 call with the deposit address in the from field. Each sweeping address needs a sliver of BNB for gas, which at sub-gwei prices is a rounding error.

If your endpoint was unreachable, the missed deliveries are not gone: GET /api/v2/bsc/webhooks/notifications/failed lists them, and POST /api/v2/bsc/webhooks/notifications/{id}/retry re-sends each one. For reconciliation, you can also list everything the API has sent you:

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

That one endpoint turns "did we miss a deposit?" from a support ticket into a diff against your own database.

Withdrawals deserve the same care as deposits, because a bug here sends money instead of missing it.

Validate before you send

The flow starts before the API call. Validate the destination address the moment the user submits it: correct length, 0x prefix, and the EIP-55 checksum if mixed-case letters are present. A checksum failure means a typo, and catching it in the form costs nothing, while catching it after broadcast is impossible. The API rejects malformed addresses before building the transaction, but the checksum test is yours to run — and by the time the API answers, the user has left the page.

Track every payout in your database

Write the payout to your database before you send it. One row per payout, with a state column: queued, sent, confirmed. A worker picks up queued rows, makes exactly one POST /api/v2/bsc/transactions/bep20 call per row, and stores the API response next to it. The transaction hash — your receipt — shows up in GET /api/v2/bsc/transactions, the list of everything created through the API. Show it to the user as a BscScan link and they can watch their own withdrawal confirm, which quietly eliminates the most common support ticket in the category.

Handling timeouts

The failure case that matters is the timeout. If your API call times out, you do not know whether the transfer went out. Do not retry blindly. Check GET /api/v2/bsc/transactions and your own records first, and only re-send when you are sure nothing was broadcast. Because payouts run from a hot wallet, keep a BNB float on the sending address for gas; at current BSC prices a small top-up covers thousands of transfers, so this is a monthly chore rather than an operational risk.

Every endpoint on this page runs against the BSC testnet when you add one header:

X-Network: testnet

No second account, no separate API key, no code changes beyond the header. Testnet BNB comes free from the official BNB Chain faucet, so you can rehearse the entire loop, from address creation through deposit webhook to payout, without real funds. Address formats and transaction mechanics are identical to mainnet.

The rehearsal worth doing is the ugly one: send a deposit while your webhook endpoint is switched off, bring it back up, then re-send the delivery from the failed list (POST /api/v2/bsc/webhooks/notifications/{id}/retry) and watch it arrive. Confirm your idempotency handling by replaying a notification against your own endpoint. Ten minutes of deliberate failure testing on testnet saves an incident review on mainnet. When everything holds, delete the header and the same code is live.

A webhook endpoint is a door into your accounting system, so treat it like one.

Verify the signature before you parse anything else. Set a personal secret in your profile settings; from then on Chaingateway sends an X-Signature header with every notification — base64 of an HMAC-SHA256 over the payload's txid, keyed with that secret. Your server recomputes it from the received txid and compares in constant time. A request that fails the check gets a 4xx and no further processing, no matter how plausible its payload looks. The mechanics, verification code included, are in the webhooks guide.

A second, separate lock guards the other direction: in the account panel you can restrict your API key to the IP addresses of your own servers. That whitelist protects API access — a leaked key moves nothing from anywhere else — not the webhook endpoint, so it complements the signature rather than replacing it.

Replay is the attack the HMAC alone does not stop, since a recorded valid notification stays valid. Your idempotency constraint closes that hole: a transaction hash that has already been credited gets acknowledged and ignored. Serve the endpoint over HTTPS only, and keep the webhook URL free of secrets, because URLs end up in logs on systems you do not control.

Every integration eventually sees errors, and the API reports them as ordinary HTTP status codes, so your existing error handling patterns apply.

A 401 means the Bearer token is missing, expired or wrong; check the Authorization header and the key in your dashboard. Validation failures in the 4xx range, such as a malformed address or a missing field, come with a JSON body explaining what to fix. Do not retry these: the same request will fail the same way until the payload changes.

Request and address limits depend on your plan; if you bump into them routinely, the pricing page lists plans with higher limits. Server-side 5xx errors and timeouts are safe to retry for read requests. For sends, apply the timeout rule from the payout section: verify nothing was broadcast before you submit again.

Log the full response body next to your own request record. When something needs support attention, that pairing answers most questions before they are asked. The status codes and error schemas for each endpoint are documented in the API reference.

Plenty of teams run a BSC full node for exactly one purpose: watching deposits and broadcasting payouts. That node costs real money and attention. Storage requirements are measured in terabytes of NVMe, initial sync takes days without a snapshot, and 2025 alone brought two hardforks, Lorentz and Maxwell, each a mandatory client upgrade on a deadline. Miss one and your node stops following the chain, which for a payment system means deposits silently stop arriving.

If the node exists only for payments, the migration path is short. Import your existing keys with POST /api/v2/bsc/addresses/import, replace your eth_getLogs polling loop with webhook notifications, and point payout code at POST /api/v2/bsc/transactions/bep20. Run both systems in parallel for a week and diff the results; the notification list makes that comparison a query rather than a project. Then decommission the node and reclaim the hardware budget.

If you want to keep a node, or you are deciding whether to build one in the first place, our guide to setting up a Binance Smart Chain node walks through the hardware, the sync and the maintenance honestly. The two approaches also combine: some teams keep a node for archive queries and contract calls while routing payment traffic through the API, because the API's webhook layer is the part that is genuinely tedious to rebuild.

Most teams on Chaingateway's BSC endpoints run one of two patterns. The first is accepting payments: a shop or SaaS generates a deposit address per order, waits for the webhook and ships the product, with settlement in seconds instead of banking days. The second is wallet operations at scale: exchanges and platforms that watch deposits and process withdrawals across thousands of user addresses, all through the same few endpoints.

The same building blocks cover token launches (airdrops and vesting payouts scripted as BEP-20 transfers), cross-border transfers where a wire would take days, recurring payouts for subscription billing, and DeFi products that need to see transactions the moment they confirm.

Plans and their limits are listed on the pricing page. Every new account starts with the free 7-day trial, so you can finish the whole BSC integration before paying anything.