How to accept USDT payments
A checkout needs more than a wallet address. Before accepting USDT, decide which network customers can use, how an order becomes paid, and how funds reach your settlement wallet.
1. Choose the network before sharing an address
USDT exists on multiple blockchains. A token name alone does not identify the network or token contract. Your checkout should display the exact asset, network, amount and destination returned for that payment. Ask customers to match the sending network before transferring funds.
For example, a customer holding USDT on TRON needs a payment configured for that network. Do not assume an address for another network can receive or recover the transfer. Check the supported assets, API codes and confirmation requirements before offering an option.
2. Compare fees using your typical order size
Compare the payment service fee, any minimum charge, the customer's sending cost and the merchant's settlement or withdrawal cost. Check whether a quoted charge includes the network cost. Small orders can have a different effective cost from large orders.
Use current OmniWallet pricing and the options shown for your account. Do not treat one network's fee or settlement timing as a promise for every network. Decide whether prices are quoted in USDT or converted from a reference currency, and explain any quote expiry to the customer.
3. Connect each order to a verified payment
- Create the payment on your server and save the returned payment identifier against your own order. Keep API credentials out of browser code.
- Display the payment details or use the returned hosted checkout link. Keep the order identifier so support can locate the payment.
- Receive the signed IPN notification on your server. Verify it using the documented signature procedure before updating an order.
- Process repeated notifications safely: record the payment and status, and ensure a repeated callback cannot trigger duplicate delivery.
- Choose the documented payment state that permits fulfilment for your business. A customer returning to a success page is not proof of an on-chain payment or completed settlement.
The developer quickstart includes payment creation and notification verification examples. Use the API reference for exact fields, status values and retry behaviour.
4. Define what happens when a payment is unusual
Test partial payment, overpayment, expiry, delayed confirmation and repeated callbacks. Tell customers how to contact support using an order identifier. Do not automatically fulfil an underpaid order or infer finality from a transaction screenshot.
Agree internally how refunds are reviewed, how a destination and network are verified, and who bears any transaction cost. Do not promise a refund or recovery for a wrong-network transfer unless it has been confirmed possible.
5. Test settlement and check market availability
Start in the test environment, which uses test networks and assets without real value. Verify order creation, signature checks, status changes and repeated callbacks before considering a controlled live test. Test-network success does not establish live-network fees or availability.
Choose a settlement wallet and verify that it supports the selected asset and network. Review the security model, account requirements and service terms before using the service.
Localise checkout instructions, currency presentation and support information for each audience. A translated website does not establish service availability in every country. Confirm the service's eligibility requirements and applicable local requirements before offering payments in a new market.