2026-11-04
USDC vs USDT for Merchants: Which Token and Network to Accept
Both are dollar stablecoins, so for your books they do the same job. A customer who pays 49 USDC and one who pays 49 USDT have both paid you $49, and the fee a customer sees depends on the network they pay on.
The differences that affect a merchant are where your customers actually hold each token, what happens when an address gets frozen, and how regulators treat them where you sell. If you can accept both, you should.
Where the supply actually is
Here's what DefiLlama showed on November 3, 2026, in billions of dollars:
| Network | USDC | USDT |
|---|---|---|
| All chains | 71.1 | 178.5 |
| Ethereum | 43.59 | 68.94 |
| Tron | 0.03 | 92.65 |
| BNB Chain | 1.59 | 9.17 |
| Solana | 7.01 | 2.44 |
| Base | 4.31 | not listed |
| Arbitrum | 2.28 | 0.82 |
| Polygon | 1.66 | 0.73 |
| Arc | 1.15 | none |
| Avalanche | 0.34 | 0.39 |
| Optimism | 0.16 | 0.21 |
USDT is two and a half times the size of USDC, but about 52% of it is on Tron, and 39% more is on Ethereum. On the low-fee EVM networks most merchants would pick, USDT's lead disappears, and on Base and Arbitrum USDC is the bigger of the two by a distance. BNB Chain is the exception, with USDT about six times the size of USDC.
Supply doesn't tell you what your own customers hold, but it's a decent first guess. If your customers are on Tron, a provider without Tron won't reach them. That includes Klap today: TRON is in progress and not live, and we'd rather tell you here than have you find out at checkout.
Freezes work differently
Both issuers can freeze addresses, and the two tokens don't block the same thing. USDC refuses a transfer if either the sender or the recipient is blacklisted. USDT only checks the sender, so a transfer to a blacklisted USDT address succeeds, and the money sits there until Tether lifts the restriction.
With USDC, a frozen recipient makes the transfer revert, which is loud and leaves the funds where they were. With USDT, the payment arrives somewhere its owner can't spend it, and nothing failed. If you pay out to several recipients in one transaction, USDC's rule means one frozen recipient can hold up the whole split. On the other hand, a payout address that's restricted on USDC can usually still be paid in USDT.
You can also ask ahead of time on most routes, but not all. USDT on Base and Optimism, and both tokens on BNB Chain, have no public function that reports the status of an address. The issuer can still freeze there, you just can't see it coming.
Regulation, if you sell in Europe
Regulation is where USDC and USDT differ most. Circle is authorized as an electronic money institution in France, and USDC and EURC are issued under that authorization. Tether hasn't obtained MiCA authorization for USDT. The EU's transition period ended on July 1, 2026, and major exchanges have removed or restricted USDT for EU users.
What that means for a merchant taking USDT directly into its own wallet is a question for your lawyer, and we won't answer it in a blog post. In practice, if you have EU customers, USDC is the token they can more easily buy on a regulated exchange. If you're an EU business, ask before you turn USDT on.
Picking the network
The token rarely changes what a customer pays in fees or how long they wait. The network does. Here's what Klap requires before a charge counts as paid, which gives you a sense of how long each network makes people wait:
| Network | What Klap waits for | Typical wait | USDC | USDT |
|---|---|---|---|---|
| Arc | Finalized block | Seconds | Yes | No |
| BNB Chain | Finalized block | 1 to 4 seconds | Yes | Yes |
| Polygon | Finalized block | 4 to 8 seconds | Yes | Yes |
| Avalanche | 5 blocks | Seconds | Yes | Yes |
| Base | 15 blocks | About 30 seconds | Yes | Yes |
| Optimism | 15 blocks | About 30 seconds | Yes | Yes |
| Arbitrum | 120 blocks | About 30 seconds | Yes | Yes |
| Ethereum | 12 blocks | A couple of minutes | Yes | Yes |
A wallet with enough payment history can get a shorter wait on the block-count networks, down to a floor. The confirmations post explains how, and the Polygon post explains why three of these don't count blocks at all anymore.
Ethereum is where the most money is and the worst place for a small payment, since gas on a simple transfer can take a visible bite out of a small order. We'd only offer it for larger amounts, or to customers who ask for it.
One thing to watch if you're writing your own integration: both tokens use 18 decimals on BNB Chain and 6 everywhere else we support. An amount hardcoded for 6 decimals is off by a factor of a trillion there, and the mistake only shows up on that one network. Klap handles the conversion, but read decimals from the contract if you touch raw amounts yourself.
What we'd do
If you're starting from nothing:
- Accept USDC on Base and Polygon first. Transfers are cheap on both, and Polygon confirms in seconds.
- Add USDT on Polygon and BNB Chain if your customers ask for USDT or you sell outside the EU. BNB Chain is where the most USDT is among the networks we support, after Ethereum.
- Let the customer choose. Someone holding USDT on Polygon shouldn't have to swap or bridge to pay you.
On Klap a single charge can take several pairs, and whichever one the customer picks lands at the same contract address:
const charge = await klap.charges.create({amount: 49.00,expiresIn: 1800,acceptedPayments: [{ token: 'USDC', network: 'base' },{ token: 'USDC', network: 'polygon' },{ token: 'USDT', network: 'polygon' },{ token: 'USDT', network: 'bnb' },],})
You receive the token the customer sent, with no conversion in between. So if you take both, you'll hold both, and turning either into dollars at a bank is a separate step with an exchange or ramp partner. Don't hardcode this table in a checkout: GET /v1/networks returns what your API key can accept.