Stripe's Crypto Card Settlement Path

A customer in Mexico City taps a Visa card at a coffee shop. The terminal sends an auth request to Visa. Visa routes it to Lead Bank, the issuer. Lead Bank asks Bridge whether the cardholder has enough stablecoins to cover a 95-peso coffee. Bridge checks a wallet on Solana, converts USDC to pesos at the current rate, and returns an approval. The barista sees "approved" on the terminal.

That took about a second. Behind it are two ledgers that now need to agree: the blockchain where USDC was debited and the Visa network where Lead Bank owes the merchant's acquiring bank 95 pesos. If those ledgers disagree about what happened, someone is either out money or holding a balance that doesn't exist.

This is the engineering problem at the center of Stripe's stablecoin card program, built on Bridge, the stablecoin infrastructure company Stripe acquired for $1.1 billion. The constraint is making two settlement systems that run on different clocks, different finality models, and different failure modes produce the same answer for every transaction.

The settlement path

When you trace the money through a stablecoin card transaction, it crosses four boundaries.

Authorization. When the cardholder taps, the Visa network sends an authorization request to the issuing bank (Lead Bank for Bridge's program), which passes it to Bridge. Bridge checks the cardholder's stablecoin wallet balance, confirms sufficient funds, and locks the conversion rate. If the balance covers the transaction, Bridge returns an approval.

The rate lock matters. Card programs typically set the exchange rate at authorization time, not at settlement, which can be one to two business days later. If USDC's value relative to the local currency moves between authorization and settlement, Bridge absorbs the difference. That's an FX risk that traditional card issuers also carry, but stablecoin volatility adds a layer that fiat-to-fiat programs don't have.

Stablecoin debit. Bridge debits the cardholder's stablecoin wallet. Depending on the chain, this is either a direct token transfer from the custodial wallet or an orchestration API call that moves funds through Bridge's infrastructure. The debit needs to be atomic with the authorization, or at least fast enough that no second transaction can spend the same balance.

Fiat credit. Bridge converts the stablecoins to local fiat. This conversion runs through Bridge's orchestration layer, which handles on-ramps, off-ramps, and cross-currency transfers through a single API. The fiat proceeds go to Lead Bank's settlement account with Visa.

Visa settlement. Lead Bank settles with the merchant's acquiring bank through Visa's normal settlement process. The merchant gets paid in local currency, usually one to two business days after the transaction. The merchant never knows stablecoins were involved. Their terminal, their acquirer, and their bank statement all show a normal Visa transaction.

Two of those four boundaries are on-chain (wallet debit, stablecoin conversion) and two are off-chain (authorization response, Visa settlement), but all four have to produce one consistent outcome, and each has its own failure modes.

Two ledgers, two clocks

On-chain finality and card network settlement run on different schedules.

A USDC transfer on Solana reaches optimistic confirmation in about 400 milliseconds, with full finality in roughly 13 seconds. On Ethereum, probabilistic finality arrives in about 15 seconds, with absolute finality (Casper FFG) taking roughly 13 minutes. Visa's authorization response needs to come back in under 2 seconds, or the terminal times out. And Visa settlement, when the money actually moves between banks, happens in daily batches, usually T+1 or T+2.

So Bridge has to debit a stablecoin wallet (seconds), respond to Visa's auth request (under 2 seconds), and then wait one to two business days for the fiat settlement to close. During that gap, the on-chain ledger says the cardholder has been debited, but the card network ledger says the transaction is still pending settlement.

This is a version of the problem I covered in the five clocks piece: the same transaction has multiple timestamps, and they don't agree. The stablecoin debit, the Visa auth, and the Visa settlement each run on their own finality clock. A reconciliation system has to track all three and flag when they diverge.

Think of it like a restaurant where the kitchen and the front-of-house run on separate order systems. The kitchen marks the order as "served" when the plate leaves the pass. The server marks it "delivered" when it reaches the table. Most of the time those two events happen seconds apart and nobody notices the gap. But when a plate gets dropped between the pass and the table, the kitchen's system says the order was completed and the customer's tab says it wasn't. Someone has to reconcile.

The difference with stablecoin card settlement is that the two systems don't share a database. The blockchain and Visa's network are separate sources of truth that don't share a database. Bridge is the only entity that sees both, and its reconciliation layer is the system that catches when they disagree.

Where it breaks

The failure modes depend on which step fails and which ledger gets updated first.

Auth succeeds, chain debit fails. The cardholder taps, Bridge approves the authorization, but the on-chain transfer doesn't confirm. Maybe the chain is congested, maybe the wallet had a concurrent spend that drained the balance between the check and the debit. Now Visa thinks the transaction is approved, the merchant expects payment, but Bridge hasn't collected from the cardholder's wallet. Bridge is on the hook.

Chain debit succeeds, Visa settlement fails. The stablecoin wallet is debited, but something fails on the card network side. A dispute, a chargeback, a processing error. The cardholder's on-chain balance has been reduced for a transaction the card network reversed. Bridge needs to refund on-chain, which requires a separate transaction.

Chain reorg. On proof-of-work chains (less relevant for Solana and newer L2s, but still a consideration for Ethereum), a confirmed transaction can be reversed by a chain reorganization. If Bridge debits a wallet based on a block that later gets orphaned, the debit effectively never happened, but the Visa authorization might already be settled. Bridge would need to detect the reorg and either re-submit the on-chain transaction or reverse the card transaction.

FX rate movement. Bridge locks the conversion rate at authorization. Settlement happens one to two days later. If the rate moves against Bridge in that window, the fiat proceeds from selling the stablecoins are less than what Bridge committed to pay the card network. On any single transaction, the exposure is small. Across millions of transactions, it's a treasury management problem.

Each failure mode requires its own recovery path. And each recovery path has to coordinate between two independent systems that have no native awareness of each other.

The on-chain settlement pilot

Visa is testing a path that eliminates one conversion step. Through Bridge's partnership with Lead Bank, card transactions can settle on-chain in stablecoins instead of fiat.

In the standard path, Bridge converts stablecoins to fiat, and Lead Bank settles with Visa in fiat. With on-chain settlement, the issuer sends USDC or EURC directly to Visa over a blockchain. Supported chains include Solana, Ethereum, Stellar, and Avalanche.

On-chain settlement removes the fiat conversion at the issuer-to-network leg, which eliminates one source of FX risk and one reconciliation boundary. The stablecoin that was debited from the cardholder's wallet is the same asset that settles with Visa. One currency, two ledger entries instead of a currency pair and a conversion spread.

But it introduces its own complications. Visa's settlement system was built for fiat. Accepting stablecoins on-chain means Visa needs to manage blockchain wallet infrastructure, monitor for on-chain settlement finality, and handle the case where an on-chain settlement transaction fails after the authorization was approved. The pilot is running with a limited set of issuers and stablecoins for a reason.

Scale and what comes next

Market-wide stablecoin card spending hit roughly $1.2 billion per month by September 2026, about triple the year before. Bridge's own card volume is a fraction of that, with Paymentscan reporting about $2.5 million in September 2026. The gap reflects how early Bridge's card program is relative to incumbents.

Stripe plans to expand the Bridge card program from 18 countries to over 100 by end of 2026. The Stripe Issuing integration, launched in April 2026, lets developers create stablecoin-funded cards through Stripe's API by specifying a crypto_wallet parameter that ties the card to a Bridge wallet. Two integration paths exist: consumer programs where Bridge manages the card experience, and commercial programs where the developer uses Stripe Connect with USDC financial accounts.

As volume grows, the dual-ledger reconciliation becomes the load-bearing piece. A few thousand transactions a day can be reconciled manually when something goes wrong, but a few million can't. The system that catches when the blockchain and the card network disagree about the same transaction has to work at the scale of a card issuer's daily volume.

The stablecoin transfer is a solved problem and card authorization is something Visa and Stripe have run for years. The reconciliation layer between the two, where two independent settlement systems have to agree transaction by transaction that the same money moved the same way, is where the real engineering sits.