How to Accept USDT Payments on BSC & TRON: The Complete 2026 Guide

To accept USDT payments you pick one or both of the two networks merchants actually use — Binance Smart Chain (BEP-20) or TRON (TRC-20) — give the customer an address and an exact amount, then watch for a matching transfer and release the product or service once it is settled. The reliable way to do the watching is a payment API: it matches the transfer to the order, absorbs duplicates and reorgs, and calls your server back with a signed webhook the moment the payment is settled.

USDT (Tether) is the most widely held stablecoin: one token pegged to one US dollar, transferred directly between wallets on several blockchains. For a crypto-native customer it is the default way to pay — cheaper and faster than card rails, and it does not require them to own, fund or trust a custodial account. For the merchant it settles like crypto (no chargebacks, no payout cycles) while holding its value like a dollar.

Both networks settle USDT transfers within a few seconds and cost a fraction of a dollar per transfer, so for most merchants the honest answer is: accept on both, and let the customer choose. They differ in the details that bite you later.

If your customers are traders and DeFi users, BSC fits their wallets. If they are shopping-natives and remitters, TRON is where USDT payments overwhelmingly happen. Supporting both behind one address-free API removes the "which chain did you send on?" conversation entirely — you generate a payment per order, so there is nothing to reconcile across chains.

The same USDT token is represented differently on each chain: on BSC it has 18 decimal places and on TRON 6. A "100 USDT" order is raw units of 100 × 10¹⁸ on BSC but 100 × 10⁶ on TRON. Any code that treats raw amounts as ordinary numbers — comparing them, summing them, displaying them — will silently under- or over-count by a factor of a trillion unless it carries the token's decimals alongside the amount.

Once you have a receiving address, acceptance is a question of how you learn that a payment is real and settled. There are three common approaches, and they differ enormously in correctness and effort.

Manual checking and self-hosting both end up re-implementing the same money-sensitive logic — match the receiver and amount, ignore transfers that belong to no open order, refuse duplicates, survive reorgs — and every one of those subsystems is a place a payment can be lost or released early. A payment API gets the merchant past the watching entirely, which is the point: the merchant's job is fulfilling orders, not operating chain infrastructure.

A transfer parachuting into your address is not automatically your order being paid. Making that jump safe is the entire problem of crypto payments, and it has four parts:

• Respect the amount-existence check. The transfer must match an exact expected amount. Overpayments are tempting targets — they are real money, but releasing an overpaid order or settling it to the wrong invoice mints the same double-release losses as a forged transfer.
• Match the sender, not just the address. Incoming-only filters catch this: a transfer you sent out should never count as income to you.
• Count a transfer once. The same transfer re-scanned must not be double-counted; the natural key is network + transaction hash + log index.
• Survive reorgs. A chain can briefly include a transfer and then drop it. A payment that settles early, on a transfer the network later discards, is a payment released with no money behind it.

These are four independent failure modes, and every one of them has cost someone a real refund or a real loss. A payment processor is not "a webhook with extra steps" — it is a system that has decided what each of these means before your money is involved. That decision is the product.

1. Create a payment. One HTTPS request (POST /api/v1/payments) sends the receiving address, the expected amount in raw units, the token and network, and how long the offer stays open.
2. Show the customer the address and the exact amount on the checkout page, with the network named. The payment request is tied to an order, so there is no "which order was this for?" step later.
3. Wait. The merchant does nothing. A worker watches the chain for a matching incoming transfer to that address for that token.
4. Receive the webhook when it settles. The moment a matching transfer is detected, the payment settles and your server is called with payment.detected, then payment.confirmed — a transfer in a confirmed chain log has already been accepted by the network, so settlement is immediate.
5. Verify the signature. Every delivery is HMAC-signed (X-Forypay-Signature); your server checks it and is authoritative. Deliveries are retried with exponential backoff until your endpoint returns 2xx.
6. Release the order. Fulfilment happens only on a response your code chose to trust, never inline during checkout.

A webhook is just an HTTP request to endpoints you also expose publicly. Anyone who can reach that endpoint can POST to it, so the receiving server must be able to tell a real delivery from a forged one. An HMAC signature over the payload proves the delivery came from the processor and was not tampered with in flight — and because it is cryptographic rather than "trust this IP", it holds up even when the delivery is proxied or retried.

The rule is simple: verify the signature, then trust the payload. A merchant whose release logic triggers on an unsigned or unverified callback is one request away from giving goods away for free.

Merchants worry about three edge cases before they launch, and the correct stance on each is: decide once, enforce everywhere.

• Underpayment: does not settle the order. If the customer sent less than the expected amount, the payment stays open until its expiry — no auto-release on partial money.
• Overpayment: does not settle the order either. Only an exact amount matches an open order, so a surplus is never credited to it — it is recorded for manual handling. Refund an accidental extra the same way you would any other outgoing transfer.
• Refund: USDT has no "cancel". A refund is a new outgoing transfer. Reach it by generating a transfer from your own wallet and recording it against the order for your books.