How to Accept USDT Payments: A Practical Merchant Guide

Accepting USDT means connecting an invoice to an order, presenting a blockchain payment route, and updating the order only after the payment meets the required confirmation policy. Paymos provides Hosted Checkout, Payment Links, the Widget SDK, CMS plugins, and a host-to-host REST API for that flow. The right starting point depends on how much of the checkout and order logic your business already controls.

USDT is available through Paymos on 11 networks. The payer's wallet covers the network fee for sending the payment, while Paymos covers the network cost of accepting and consolidating it. The merchant balance remains in USDT rather than being forced through a conversion to BTC, ETH, or fiat. The USDT payment page lists the supported routes.

What do you need before accepting the first payment?

Start with a Paymos project and an integration choice. A merchant can begin without submitting KYC or business documents, although additional verification may be requested later under applicable risk, limit, or regulatory policy. Sandbox is available before a production withdrawal address is configured.

Use a Payment Link when a shareable invoice is enough. Hosted Checkout suits stores that can redirect or embed an iframe. The Widget SDK fits an on-site flow, while an official CMS plugin is the shortest route for WooCommerce, WHMCS, OpenCart, PrestaShop, Magento 2, Shopware 6, CS-Cart, or Easy Digital Downloads. Choose the REST API when your server owns order creation and fulfilment.

Which credentials should the integration use?

Server integrations authenticate with HMAC-SHA256. Merchant API authentication is not Bearer-token authentication, and the signing secret belongs on the server rather than in browser code. Payment and Payout credentials are separate, so invoice creation should use Payment credentials only.

Sandbox and Production also use separate credentials. The API surface remains the same across both environments, which lets the integration exercise supported payment outcomes before handling real assets. Treat the environments as separate security boundaries: store their credentials independently, send each request to the intended environment, and make the environment visible in operational logs.

How do you create invoices without duplicates?

Give every order a stable external_order_id and pass it when creating the invoice. That identifier is the invoice-creation idempotency contract: if the same external order identifier is reused, Paymos returns the existing invoice rather than creating a second one. Paymos does not use an Idempotency-Key header for invoice creation.

Generate the identifier in the order system, not in a transient browser session. Persist the Paymos invoice reference beside the merchant order before sending the buyer to checkout. If the request must be retried after a timeout, reuse the original external_order_id. A new identifier would represent a new invoice, even when the business intended only to repeat the request.

Which checkout route should you present?

Hosted Checkout provides a responsive payment page, QR payment, and wallet deep links for Trust Wallet, MetaMask, Coinbase Wallet, and OKX Wallet. It can run as a redirect or an embedded iframe. The payer does not need a Paymos account, email address, or checkout KYC, and payment status updates without a page reload.

Payment Links work when the merchant needs to distribute an invoice URL without a custom backend flow. The Widget SDK supports iframe and redirect modes for a more integrated experience. A fully custom server integration can create and retrieve invoices through the REST API, but it still needs a clear payment interface and an order state that remains pending until confirmation. The REST API guide covers that server-side path.

How should you verify the webhook?

Paymos webhooks carry the X-Webhook-Signature header in the format t={timestamp},v1={hmac_hex}. Verify the signature with HMAC-SHA256 and use a timing-safe comparison. Do not authenticate webhook delivery with a Bearer token or by trusting the source IP alone.

Secret rotation supports a grace period during which the current and previous webhook secrets can be accepted. A receiver should therefore know which configured secrets are valid during the rotation and retire the previous secret after the grace period. Keep signature verification ahead of parsing, order updates, and fulfilment so an unverified request cannot change business state.

What should happen when delivery fails?

A webhook delivery cycle makes 11 total attempts: the initial attempt and ten retries. Delays increase from one minute to eight hours, and the complete window lasts approximately 16 hours. Failed or undeliverable events remain available for manual replay.

The receiving side should make the order transition repeat-safe. Persist a business-level event or invoice reference before applying fulfilment, and make the operation refuse a second credit for the same payment. Return success only after the local order update is durable. The exact storage model belongs to the merchant, but the invariant is simple: repeated notification must not create repeated fulfilment.

When does the order become paid?

Confirmation policy depends on both the network and the payment amount. Smaller payments can require fewer confirmations, while larger payments can require a stronger finality threshold. There is no fixed confirmation time that applies to every Paymos payment.

Underpayment follows the project's percentage tolerance. The default is 0%, which requires strict matching. A payment inside the configured tolerance completes the invoice for the amount actually paid; Paymos does not add the missing amount. Below the threshold, a single-payment invoice becomes underpaid, while a multi-payment invoice can remain open for the payer to send the remainder.

What happens to the merchant balance?

Paymos settles the merchant in the same asset received from the payer. USDT received through different supported networks contributes to the same USDT asset balance, and the merchant selects an available network when creating a withdrawal. Only payout routes enabled for that asset are offered.

The withdrawal address must be merchant-controlled and whitelisted. Paymos takes no processing commission on the withdrawal, although the chosen route can include a disclosed, subsidized network fee and a minimum. The availability, fee, and minimum depend on the asset and network pair, so they should be read from the selected payout route rather than hardcoded into the integration.

What belongs on the production checklist?

Confirm that Payment credentials are isolated from Payout credentials and that Sandbox credentials cannot reach Production. Verify X-Webhook-Signature before processing an event, keep the current and previous webhook secrets only for the supported rotation grace period, and make order fulfilment repeat-safe.

Use a publicly reachable webhook destination. Paymos blocks loopback, private, link-local, CGNAT, and IPv6 ULA destinations, and it does not follow automatic HTTP redirects. Monitor failed deliveries and use manual replay when the receiving system has recovered. Finally, document that confirmation time varies by network, amount, and blockchain conditions rather than promising a fixed settlement time.