Accepting USDT is more than displaying a wallet address. A production payment flow must connect each transfer to an order, wait for the right confirmation state and tell your application when fulfillment is safe. This guide explains the moving parts and shows where bestuPay fits.
Start with the payment flow
The customer begins on your website, but the payment should be created by your server. Your backend sends the order number, amount and title to the payment API, then redirects the customer to the returned checkout URL.
The hosted checkout presents the available payment methods and the exact amount due. When the transfer is detected and confirmed, bestuPay updates the payment and sends a signed event to your webhook endpoint.
- Create payments only from a trusted server
- Keep the API secret outside browser code
- Store the bestuPay payment ID with your local order
Choose the networks your customers use
USDT exists on several networks. TRC20 and BEP20 use different addresses, fee models and confirmation behavior, so the network must be explicit at checkout. A transfer sent on the wrong network cannot be corrected by the payment application.
bestuPay lets a merchant attach supported blockchain addresses and Binance wallet payment options to a site. The customer can choose from the methods that the merchant has enabled.
- Label every payment method with its network
- Display the destination and exact amount clearly
- Never assume that all USDT transfers use the same chain
Match transfers to orders
A reusable wallet address alone does not identify which customer paid. A payment gateway needs a deterministic way to connect an incoming transfer with the correct order.
bestuPay uses a unique payment amount for blockchain orders, including a decimal suffix. The platform monitors the configured wallet, matches the observed amount and records the transaction details against the payment order.
- Use a unique merchant order number
- Treat the generated payment amount as the amount due
- Handle underpaid, overpaid and late transfers as exception states
Verify the webhook before fulfillment
The browser return page is useful for customer experience, but it is not proof of payment. Fulfillment should happen only after your server verifies a signed webhook or confirms the payment through a server-side status query.
For bestuPay webhooks, calculate the HMAC-SHA256 digest from the raw request body with the site's Webhook Secret and compare it with the X-BestuPay-Signature header using a timing-safe comparison.
- Verify the signature against the raw request body
- Process each event ID only once
- Return an HTTP 2xx response after the event is accepted
Prepare for production
Test successful payments as well as expiration, delayed confirmation and duplicate webhook delivery. These edge cases determine whether checkout remains reliable when network conditions are less predictable.
Keep operational logs for payment IDs, merchant order numbers, event IDs and transaction hashes. They make support and reconciliation much easier without exposing secrets.
- Use HTTPS for API callbacks and return URLs
- Make fulfillment idempotent
- Rotate credentials after suspected exposure