Accepting USDT is a two-day integration and a six-month operational commitment. The integration is the easy part: a checkout call, a webhook endpoint, a settlement report. What takes longer is everything after go-live — underpayments, wrong-network sends, a webhook that fired three times, and a finance team asking why the settlement total does not match the order total. This guide covers the full path: sandbox to production, webhook handling that survives retries, reconciliation, chart-of-accounts mapping, and the failures that show up in week three.
Decide the model first: direct wallet, gateway, or converted settlement
This decision determines everything downstream, and reversing it later means re-doing the reconciliation.
Direct wallet acceptance. You generate an address, the customer sends USDT, you hold USDT. No provider fee — but you now own address generation, network monitoring, confirmation logic, underpayment handling, refunds, key custody, KYT and sanctions screening. For most businesses that is not a saving; it is an unstaffed payments team.
Gateway with crypto settlement. The provider handles checkout, addresses and confirmation, then settles USDT to your wallet. You keep the token, the price exposure and a cryptoasset on your balance sheet.
Gateway with fiat settlement. Same checkout flow, but the provider auto-converts at confirmation and settles EUR or USD to your bank. Your ledger never holds a cryptoasset and your exposure window is minutes rather than days.
For most merchants the third option is correct, and the reason is not technical: the first two push a treasury and compliance function into a company that did not plan to have one. Crypto payment gateway vs processor sets out how the roles differ. The rest of this guide assumes a gateway integration with fiat settlement — the flow INXY Payments runs across 20 supported cryptocurrencies with next-day bank settlement.
Pick the networks before you write code
USDT is one token on several networks, and they are not interchangeable. A customer who sends TRC-20 USDT to an ERC-20 address has lost the funds, and no amount of support can recover them.
| Network | Block time | Practical finality | Typical merchant use |
|---|---|---|---|
| Tron (TRC-20) | 3 seconds | Solidified once at least 19 of 27 active super representatives have produced a block at that height or above — in practice about 1 minute (TRON developer documentation) | Default for low-value, high-volume checkout and for Asia/LatAm payers |
| Ethereum (ERC-20) | 12-second slots, 32 slots per epoch (6.4 minutes) | Finalised across checkpoint epochs — roughly 13 minutes in practice (ethereum.org) | Higher-value payments, counterparties who require it |
| BNB Smart Chain (BEP-20) | Sub-second to seconds | Provider-defined confirmation depth | Cost-sensitive alternative where payers already hold BEP-20 |
| Polygon | Seconds | Provider-defined confirmation depth | Cost-sensitive, increasingly requested |
The practitioner's rule: support the networks your payers actually use, not every network you can. Each extra network is another address type, confirmation rule, support queue and reconciliation column. Start with two. How USDT network fees compare has the cost detail.
Confirmation depth is a commercial decision, not a technical one. Crediting at one confirmation is fast and carries reorg risk; waiting for finality is safe and costs the customer minutes. For instantly delivered digital goods most merchants credit at the provider's standard depth; for anything irreversible and high-value, wait for finality. Decide it explicitly and check that your provider's default matches.
The integration sequence: sandbox to production in nine steps
- Complete KYB before you write anything. Gateway onboarding requires company documents, UBO identification, a description of your business model and often your website in a reviewable state. It is the longest-lead item in the project and teams routinely start it last. How to verify a merchant account sets out what is collected.
- Get sandbox credentials and read the invoice lifecycle. Every gateway models a payment as an object with states — created, pending, underpaid, confirmed, expired, failed. Map those states to your own order states on paper before you write code. Most integration bugs are state-mapping bugs.
- Create a payment on the server side, never the client. The amount, currency, order reference and callback URL are set by your backend. A client-settable amount is an open invitation, and it is the single most common security defect in crypto checkout integrations.
- Handle the rate lock window explicitly. The gateway quotes a USDT amount against your fiat price and holds it for a fixed window. If the customer pays after expiry, the payment arrives short or long in fiat terms. Display the countdown, and decide in advance whether an expired-but-paid invoice is auto-recredited or manually reviewed.
- Build the webhook endpoint before the checkout page. It is the part that carries the risk, and it needs to exist before you can test anything end to end. Details in the next section.
- Test the failure cases, not the happy path. In sandbox, deliberately produce: an underpayment, an overpayment, a payment after invoice expiry, a duplicate webhook delivery, an out-of-order webhook delivery, and a webhook your endpoint rejects with a 500. If you have not seen all six in sandbox, you will see them in production instead.
- Wire up the settlement report and hand it to finance before go-live. Not after. If the export does not carry, per row, the order reference, the gross fiat amount, the fee, the FX rate applied and the settlement date, your month-end will not close cleanly. This is the step teams skip and regret.
- Go live with one network and a payment cap. Cap the maximum invoice value for the first two weeks. It converts a potential six-figure incident into a three-figure one while your confirmation and reconciliation logic proves itself.
- Reconcile manually for one full cycle. Match every settlement line to an order by hand for the first month. It is how you find the edge case in your state mapping while the volume is still small enough to fix.
Webhook handling: five rules that prevent the expensive bugs
The webhook is where a payment integration succeeds or quietly breaks. Treat it as an untrusted network endpoint that will be called more than once, out of order, and occasionally by someone who is not your provider.
1. Verify the signature before parsing anything. Compute the expected signature over the raw request body — not a re-serialised object, because re-serialisation changes byte order and the signature will not match — and compare in constant time. Reject and log failures.
2. Make the handler idempotent. Key on the provider's payment identifier, not your order ID. Record processed identifiers and return success without re-processing. Webhook delivery is at-least-once by design, so retries are normal, and a non-idempotent handler will credit the same order twice.
3. Never treat the payload amount as your source of truth. Verify server-side against the provider's API before fulfilling. A signature proves the message came from your provider; fetching the object proves the current state.
4. Respond fast, process asynchronously. Return 2xx as soon as the event is persisted, then fulfil on a queue. Inline fulfilment times out under load, the provider retries, and you are back to rule two.
5. Do not assume ordering. A confirmed event can arrive before the pending event preceding it. Drive order state from the event's own state field and a timestamp, never from arrival order.
And make sure the endpoint is reachable. IP allowlists, WAF rules and leftover staging basic-auth are a recurring go-live failure. Confirm delivery from the provider's dashboard on day one, not from your own logs.
Reconciliation and chart-of-accounts mapping
This is the part that determines whether your finance team supports the project in month three.
With fiat settlement, a USDT payment produces three distinct economic events that arrive at different moments: the customer's on-chain payment, the conversion to fiat, and the bank settlement. If your ledger treats them as one event, you will carry an unexplained variance every month.
A mapping pattern that works in practice:
| Event | Debit | Credit |
|---|---|---|
| Invoice issued | Trade receivable | Revenue |
| Payment confirmed on-chain, converted | Settlement clearing account (asset) | Trade receivable |
| Provider fee applied | Payment processing fees (expense) | Settlement clearing account |
| Conversion difference vs invoiced rate | FX gain/loss | Settlement clearing account |
| Bank settlement received | Bank | Settlement clearing account |
The clearing account is the control. It should net to zero once every batch has settled, and a persistent non-zero balance tells you exactly where the break is — unsettled, unmatched, or mis-rated. Without it, differences disappear into revenue and nobody finds them until audit.
Four requirements to put in the provider evaluation, not discover afterwards:
- Row-level settlement export with order reference, gross amount, fee, FX rate and settlement timestamp on every line.
- A stable order reference that survives from invoice creation to bank settlement. If the reference is lost at conversion, matching becomes manual.
- Consistent timezone handling. A settlement timestamp in the provider's timezone against orders in yours produces month-end cut-off differences every single period.
- Fees itemised, not netted. A net figure hides the fee and makes cost analysis impossible.
Accounting treatment for digital assets varies by jurisdiction and by reporting framework, and it changes. The mapping above is an operational pattern, not accounting or tax advice — confirm the treatment with your own auditors before you book it.
What breaks after go-live
Underpayments. The customer sends slightly less than invoiced, usually because their wallet deducted the network fee from the amount rather than adding it. Decide the policy before it happens: auto-accept below a tolerance threshold, hold for review above it, and make the threshold a configuration value rather than a code change.
Wrong-network sends. The dominant support burden in USDT acceptance. Mitigate at the interface: show the network prominently, use network-specific QR codes, never present a bare address without its network label, and put the warning next to the address rather than at the bottom of the page.
Duplicate order creation. A customer refreshes checkout and generates a second invoice for the same order, then pays the first one. Your order is now linked to an unpaid invoice. Key invoice creation on the order ID and return the existing invoice instead of creating a new one.
Refunds are outbound payments, not reversals. There are no chargebacks on this rail — a structural property, since there is no card scheme representment process — which removes a large category of loss. It also means a refund is a new payout to an address the customer supplies, with its own screening, its own network fee and its own operational process. Design the refund flow during integration, not on the first request.
Expired-invoice payments. A customer pays an hour after the rate window closed and the fiat value no longer matches the invoice. Without a written policy this lands on a support agent with no authority to decide it.
Staging credentials that outlive staging. Sandbox keys left in a production environment variable, or a production endpoint still pointing at a dev URL. Verify both directions on go-live day.
The decision framework
Do not start with the API documentation. Start with three questions, in this order:
- Where do your payers sit, and what network do they already use? A payer-data question, not an engineering one, and it settles which networks you support.
- Do you want a cryptoasset on your balance sheet? If no — and for most merchants the answer is no — the model is fiat settlement, which removes most of the treasury and accounting complexity before it exists.
- Who owns reconciliation? If the answer is “we'll work it out after launch,” involve finance now. Every integration that goes badly goes badly at month-end, not at go-live.
Get those three right and the integration is a short piece of work. Get them wrong and no amount of clean code fixes it.
Where this is not the right answer: if you sell primarily to domestic consumers in a well-banked market with working card acceptance and a low decline rate, adding USDT acceptance will produce a small share of volume and a real amount of operational overhead. Stablecoin acceptance earns its keep when cards are failing you — regional declines, chargeback ratios threatening your acquirer relationship, or cross-border settlement measured in days. If none of those describe you, the honest answer is that this is not your priority this quarter.
If they do describe you, the fastest path is a sandbox integration against your real checkout flow rather than a proof of concept. Get started for credentials, or book a demo if the reconciliation model is the part you need to settle first. For the developer-side detail, integrating a crypto payment API goes deeper on the API surface, and checkout design that converts covers the payer-facing half.
This article describes regulatory and market conditions for general information. It is not legal, tax, or financial advice — INXY Payments is a payment infrastructure provider, not a law or accountancy firm, and decisions with regulatory consequence should be reviewed by qualified counsel in the relevant jurisdiction.
FAQ
How do I accept USDT payments on my website?
Integrate a crypto payment gateway: create the payment server-side with the fiat amount and order reference, display the gateway's checkout with the correct network, verify the signed webhook when the payment confirms, and settle either in USDT or converted to fiat. Most merchants choose fiat settlement so no cryptoasset touches the balance sheet.
Which USDT network should I accept?
Support the networks your payers already use rather than all of them. TRC-20 is the common default for low-value, high-volume checkout, with ERC-20 added where counterparties require it. Each extra network adds address handling, confirmation rules, support load and a reconciliation column, so start with two.
How long does a USDT payment take to confirm?
It depends on the network and your chosen confirmation depth. On Tron, a block is solidified in about a minute once at least 19 of 27 active super representatives have built on it. On Ethereum, finality is reached across checkpoint epochs — roughly 13 minutes. Many merchants credit earlier and accept the residual risk.
What happens if a customer underpays?
The gateway marks the payment underpaid rather than confirmed. Set a tolerance threshold in advance: auto-accept small shortfalls, hold larger ones for review. Underpayment is usually caused by a wallet deducting the network fee from the sent amount rather than adding it, so it is common rather than exceptional.
Are there chargebacks on USDT payments?
No. On-chain settlement has no card scheme representment process, so the chargeback category of loss does not exist. Refunds still do — but a refund is a new outbound payment to an address the customer supplies, with its own screening and network fee, so the refund flow needs designing during integration.
How do we reconcile USDT payments in our accounting?
Route everything through a settlement clearing account. The on-chain payment, the conversion and the bank settlement are three separate events arriving at different times; the clearing account should net to zero once a batch has settled, and any residual balance points straight at the break. Require a row-level export with fee and FX rate per line.
