Stablecoin card program architecture: from bank deposit to card spend to local payout

Reading time: about 8 minutes.

Summary: A stablecoin card program has seven layers: onboarding and KYC, a bank-deposit entry point, conversion into USDC or USDT, a wallet that holds the balance, the card issuer's authorization and just-in-time funding, network clearing and settlement, and an off-ramp to local currency. Different providers own different layers. Your ledger is what holds them together.

Key takeaways

• Draw the program as layers before choosing vendors. Most mistakes come from two providers both thinking they own a layer, or neither.
• Authorization is card network messaging. The stablecoin side is funding and settlement.
• The bank-deposit entry point and the local-currency exit are usually one provider, separate from the card issuer.
• Every layer emits events. One internal ledger, keyed on provider ids, is the only reliable source of truth.
• Credit on completion, never on creation. That one rule removes most reconciliation bugs.

Most card program diagrams start at the swipe. That is the easy part, because the card issuer has already built it. The hard parts sit on either side: how money gets into the stablecoin balance, and how it gets back out to a bank account in the cardholder's currency.

This is a reference architecture for the whole loop. It assumes you integrate providers, not build a processor. For the swipe itself, read how a stablecoin-backed card works.

What does the full architecture look like?

The program is a loop: bank money in, stablecoin balance, card spend, and optionally bank money out. Here it is as a layered diagram:

┌─────────────────────────────────────────────────────────────┐
│ 7. Off-ramp        USDC/USDT → BRL, MXN, USD, EUR payout    │
├─────────────────────────────────────────────────────────────┤
│ 6. Network         clearing + settlement (fiat or stablecoin)│
├─────────────────────────────────────────────────────────────┤
│ 5. Card issuer     authorization, JIT pull, controls         │
├─────────────────────────────────────────────────────────────┤
│ 4. Wallet          the balance the card spends from          │
├─────────────────────────────────────────────────────────────┤
│ 3. Conversion      USD, BRL, MXN → USDC or USDT              │
├─────────────────────────────────────────────────────────────┤
│ 2. Funding         virtual account or local payin            │
├─────────────────────────────────────────────────────────────┤
│ 1. Onboarding      KYC on the cardholder, KYB on you         │
└─────────────────────────────────────────────────────────────┘
          Your ledger and product sit across every layer

Read it bottom to top for a top-up, top to bottom for a cash-out. The card swipe lives in layers 4 to 6.

Who typically provides each layer?

Each layer has a natural owner. The table is the conversation to have with every vendor before signing: "which of these rows are yours?"

A BIN sponsor is the licensed bank that owns the card number range and carries regulatory responsibility for the program. JIT funding (just-in-time) means the issuer pulls only the amount needed at the moment of authorization instead of holding a prefunded card balance.

Stripe's Bridge integration is a clean example of the split. Per Stripe's docs, customers are created in Bridge, cards and spend webhooks live in Stripe, and KYC plus the cards endorsement are managed in Bridge (Stripe). Two vendors, one card, and your code in the middle.

How does money flow through the stack, step by step?

Here is one full loop for a cardholder in the US who also cashes out to a bank account.

1. Onboard. You create the cardholder with the funding provider and the card issuer. Both need a passed identity check before they act.
2. Fund. The cardholder sends an ACH transfer to a virtual account in their name. The virtual accounts guide covers this step.
3. Convert. The deposit becomes a payin. The provider converts USD into USDC and sends it on-chain.
4. Hold. USDC lands in the card wallet. In a non-custodial design, that wallet already holds an on-chain approval to the issuer's contract.
5. Authorize. The cardholder taps. The network asks the issuer to approve. Per Stripe's docs, Bridge then pulls funds from the linked wallet just in time, relying on that prior approval, and rejects the pull if the approval or the balance is short.
6. Settle. The issuer settles with the network. Visa settles USDC with some US issuers seven days a week, instead of the traditional five-business day window (Visa). The merchant is still paid in local currency by its acquirer.
7. Cash out. The cardholder wants leftover funds in a bank account. You quote a payout, they authorize the exact amount from their wallet, and the provider pays out in local currency.

Which webhooks does each layer send?

Every layer reports through events, and the stack only works if you consume them all. Treat webhooks as the system's nervous system, not a nice-to-have.

The event names in the funding and off-ramp rows are BlindPay's (webhook events). Card issuer names vary by provider. Stripe gives a real-time authorization webhook 2 seconds to answer before applying your timeout setting (Stripe). That deadline is why the authorization handler must read your ledger, never a block explorer.

Verify every signature (webhook verification). Store the raw event before processing, so a failed handler can replay it.

How do you reconcile across three providers?

Reconciliation is one ledger, many feeds. Each event posts once, keyed on the provider's id, and the ledger is checked daily against three outside views: each provider's statement, the on-chain wallet balance, and the bank-side records.

Three rules make it hold:

• Credit on completion. A deposit is not money until payin.complete. A payout is not gone until payout.complete or a refund event.
• Key on ids. Payin id, authorization id, payout id. Providers retry webhooks. Your ledger should shrug.
• Separate holds from balances. A card authorization is a hold. The capture can come in lower, higher (tips), or never. Bridge may also pull an extra amount at authorization for some merchant categories and refund the difference at capture, per Stripe's docs.

The webhooks and reconciliation guide and the virtual account reconciliation guide go deeper on the funding side.

How should each layer handle failure?

Failure handling is layer by layer, and each layer has its own vocabulary. The goal is the same everywhere: the ledger only moves on a final state.

• Funding. A BlindPay payin can go on_hold for manual review, then end completed, failed, or refunded (returned to the sender). Do not credit the card before completed.
• Authorization. A decline for a short balance or a revoked on-chain approval is normal. Show the cardholder why, and offer a top-up.
• Settlement. Visa notes that every card program has to fund its daily settlement obligation before it collects from cardholders (Visa). Your card issuer handles this, but ask how.
• Off-ramp. BlindPay operates as a non-custodial payment processor for payout flows from customer-controlled wallets: you authorize the exact amount and BlindPay executes that single transaction. If a payout cannot be delivered after the stablecoins are collected, BlindPay refunds them to the quote's refund wallet, or to the sending wallet when none is set; on Pix and other non-USD local rails the refund is automatic, while USD payouts and payouts whose review times out are refunded after an operator review.

The custodial vs non-custodial off-ramps guide covers what each custody model protects you from.

What are the most common architecture mistakes?

Four come up again and again.

1. Reading the chain in the authorization path. Too slow for a 2-second deadline. Keep a ledger fed by events.
2. One wallet for everyone. Pooling cardholders' funds behind one deposit route hides who owns the money. Payment providers treat that as nesting (nested payments). Map one cardholder to one funding account and one wallet.
3. Mismatched token and chain. The funding provider delivers USDT on one network, the issuer pulls USDC on another. Agree on token and network per program before launch (supported chains).
4. No exit. Programs plan the top-up and forget the cash-out. Cardholders who cannot get money back to a bank account stop topping up.

Where does BlindPay fit?

BlindPay owns layers 2, 3, and 7: the entry and the exit around the card. The card issuer runs the card. BlindPay moves money into and out of the stablecoin balance behind it.

On the way in, BlindPay issues US virtual accounts in each cardholder's name for ACH, wire, and SWIFT, and creates Pix, SPEI, Transfers 3.0, and PSE payins for Latin America, converting deposits into USDC or USDT in the card wallet. On the way out, it pays out in local currency over Pix, SPEI, ACH, RTP, SEPA, and SWIFT (POBO/COBO), with UETR tracking and MT103 confirmations on SWIFT. KYC and KYB run in the same API, every quote shows fees before execute, and every step emits a signed webhook.

That keeps your card issuer focused on cards and your ledger fed by one funding and payout integration. Read the payins docs and payouts docs, or talk to the team.

What to read next

• What is stablecoin card issuing?
• Stablecoin card issuing platforms compared
• Bridge cards and BlindPay payouts in one stack, a worked pairing of two layers
• How to issue stablecoin-funded cards through an API, for the authorization handler code

Sources

• Stripe, Issue stablecoin-backed cards with Bridge
• Stripe, Real-time authorizations
• Visa, press release on USDC settlement in the United States, December 16, 2025
• Visa, on financing stablecoin-linked card programs, September 8, 2026
• Bridge, Global card issuance with stablecoins explained

This article is for general information only and is not legal, tax, or financial advice.