How to Accept USDT and USDC Payments on a Website

To accept USDT and USDC payments on a website, create a Paymos project, choose a Payment Link, ecommerce plugin, Hosted Checkout, Embedded Checkout, Low-Code SDK, or REST API, and enable supported asset-network pairs. Keep the order pending until the invoice is confirmed. Paymos settles the same stablecoin received without forcing a conversion.

Which payment method fits the sales process?

Use a Payment Link when a manager creates an invoice and sends it through email, chat, or a CRM. Choose an official ecommerce plugin when the store already runs on a supported platform and should keep order status inside that platform. Hosted Checkout opens a Paymos-hosted payment page. Embedded Checkout places that experience inside the merchant site through an iframe. The Low-Code SDK adds JavaScript controls and supports iframe or redirect modes.

The host-to-host API belongs to businesses with a server-side order system and developers who will own payment-state handling. It is not the default requirement for accepting stablecoins. The API integration guide owns HMAC authentication, repeat-safe invoice creation, and signed webhooks.

What should be prepared before the first invoice?

Create the project, choose who can manage it, and define which team owns sales, fulfilment, refunds, and withdrawals. A business can begin onboarding without submitting KYC documents, although additional verification may be requested later under applicable risk, limit, or regulatory policy. Configure the production withdrawal destination through the approved process before withdrawing funds regularly.

Write down how the customer order maps to the Paymos invoice. For Payment Links, that may be a CRM or accounting reference. For a plugin, it is the ecommerce order. For a connected checkout, it is the order in the merchant's own system. One clear reference keeps customer support and reconciliation aligned.

Which USDT and USDC routes should checkout offer?

Enable asset-network pairs that Paymos supports and that customers actually use. The USDT payment page and USDC payment page own the current network matrices, so they are the references for availability. USDT is not available on every USDC network, and USDC is not available on every USDT network. The checkout must show the exact asset and network together.

The selected network changes how the payer sends funds, pays the live blockchain fee, and waits for confirmation; it does not create a separate merchant balance for every chain. Show the network name beside the address and QR code. Do not tell a customer to send “USDT or USDC” without naming the route, and do not hardcode one dollar gas estimate. If the wallet's live fee is too high for a small invoice, let the customer choose another supported route instead of improvising a bridge during payment.

What does the customer see during payment?

The customer opens the Paymos payment page, selects USDT or USDC and an available network, and sends the exact invoice amount from a compatible wallet. The page provides the payment address, QR code, and current payment state. The customer does not need a Paymos account, email address, or checkout KYC. A merchant can use a redirect or embedded experience depending on the selected integration.

Keep the order pending while the transfer is detected and confirmed. A success-page return is useful for navigation but is not the fulfilment signal. If the customer closes the page, the order still needs a reliable status in the merchant workflow. For custom systems, the API guide explains the server-side event path without turning this merchant setup guide into an engineering manual.

What does accepting USDT or USDC cost?

Separate the payer's network fee from merchant processing and any later conversion. The payer's wallet quotes and pays the variable blockchain fee for sending USDT or USDC. Paymos Standard processing is 1.0% per settled invoice; Enterprise pricing is 0.3% on request. By default, the merchant pays the Paymos fee, while a project can pass some or all of it to the payer.

There is no setup fee, monthly platform fee, monthly minimum, reserve, hidden conversion spread, or forced conversion. Paymos covers the network cost of accepting and consolidating payments and does not add a separate sweep commission to the merchant invoice. If the business later converts a stablecoin through an external service, that provider's quoted rate, markup, gas, and withdrawal terms are separate costs.

When should an order be fulfilled or reviewed?

Fulfil only after the invoice reaches the confirmed payment state required by the selected route and amount. A detected transfer or transaction hash alone is not enough. Late payment, underpayment, duplicate notification, or a mismatched route needs a defined review path so staff do not improvise under customer pressure.

The merchant should also define refunds before launch. A stablecoin refund is a new outbound transaction, not a reversal of the original transfer. Verify the asset, network, amount, customer, and destination through an authenticated process. The stablecoin comparison guide separates issuer, liquidity, and asset-selection risks.

How do USDT and USDC settle to the merchant?

USDT received through supported networks contributes to the merchant's USDT balance; USDC contributes to the separate USDC balance. Paymos does not force conversion into fiat, BTC, ETH, or another stablecoin. When withdrawing, the business selects an available payout route for that asset and an approved destination. Paymos takes no processing commission on the withdrawal, although a disclosed network fee or minimum can apply to the selected route. That fee is subsidised: it is set below what the route costs to send.

Keep acceptance and treasury permissions separate. Staff who issue Payment Links or manage ecommerce orders do not need authority to change withdrawal destinations. Reconcile settled invoices to the matching asset balance, review the withdrawal quote, and record any later external conversion as a separate treasury action.

What should be tested before going live?

Run one small real payment through every enabled checkout method and representative USDT and USDC routes. Confirm that the invoice opens, the asset and network are unambiguous, the wallet can send, the payment moves through the expected states, the order is fulfilled once, and the correct balance updates. Test a late payment, underpayment, customer abandonment, and a refund request as operational scenarios.

Use Sandbox to test supported payment outcomes for connected integrations, but do not confuse simulated outcomes with a real blockchain transfer. Before launch, verify production access, withdrawal controls, support ownership, and customer-facing instructions. The goal is a repeatable sales and fulfilment process, not the largest possible integration.