Blog / Stablecoins

USDT vs USDC for Funding a Card Programme

A practical comparison of the two dominant stablecoins for card programme funding — what differs, what does not, and how to decide which to accept.

15 August 2026 8 min read

If you are funding a card programme, the honest headline is that this choice matters less than it appears. Both are dollar-denominated tokens, both are credited one-to-one, and once a deposit is credited neither exists in the system any more — you have a USD balance either way.

What follows is the set of differences that do have practical consequences.

What is genuinely the same

• Credit ratio. One token becomes one dollar of balance.
• The resulting card. Identical. There is no such thing as a USDC card and a USDT card.
• Confirmation handling. Depth is a property of the chain, not the token.
• Fees. ON5 charges per card operation, not per funding asset.

Decimals: the difference that trips people up

The two use different decimal precision on different chains, and this catches out anyone doing their own arithmetic against on-chain amounts.

A programme that hardcodes six decimals and then accepts BNB Smart Chain deposits will be wrong by a factor of a trillion. This is not hypothetical — it is one of the most common bugs in multi-chain deposit handling, and it is why ON5 stores decimals per token per chain and converts from base units using the token's own configuration rather than a constant.

Counterparty and reserve differences

Both are issued by centralised companies that hold reserves against the tokens in circulation. They differ in disclosure practice, jurisdiction and reserve composition, and both have been the subject of extensive public discussion over the years.

This is a real risk decision and the right way to make it is to read each issuer's current attestations yourself rather than relying on a summary in an article — including this one. What is stable is that they are different counterparties, so accepting both is a diversification rather than a duplication.

Availability and liquidity

Both are widely available across major chains and exchanges. In practice the deciding factor is often simply what your users or your treasury already hold: asking someone to swap before they can fund adds a step, a fee and a chance to abandon.

For a programme funding its own float, use whatever your treasury holds. For a programme where users fund their own balances, accept both — the cost of supporting the second one is a configuration entry, and the cost of not supporting it is the users who hold the other.

Which chain to send on

This choice has more practical impact than which token. Cost and speed vary substantially:

Confirmation counts look uneven but reflect block time rather than caution: 30 confirmations on a fast-block chain can be less wall-clock time than 12 on a slow one. Judge by how long a deposit takes to credit, not by the number.

A working recommendation

• Accept both. The marginal cost is near zero and it removes a swap step for half your users.
• Let the sender choose the chain. They know their own fee tolerance and where their balance already sits.
• Never hardcode decimals. Read them per token, per chain.
• Make the supported set unmissable in the interface. Wrong-network deposits are the most common and most painful user error in crypto funding.

Frequently asked questions

Related reading

• Stablecoin-Funded Card Programmes: How They Work
• How Multi-Chain Deposit Detection Actually Works
• Blockchain Confirmations: Why Your Deposit Waits