---
title: "Stablecoin card program architecture: from bank deposit to card spend to local payout"
seoTitle: "Stablecoin card program architecture, layer by layer"
description: "A reference architecture for a stablecoin card program: KYC, bank deposit, conversion, wallet, JIT funding, network settlement, and local-currency payout."
date: "2026-09-30"
updated: "2026-09-30"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "What are the layers of a stablecoin card program?"
    a: "Seven layers: customer onboarding and KYC, bank-deposit funding, conversion from fiat to USDC or USDT, the wallet that holds the balance, the card issuer's authorization and just-in-time funding, network clearing and settlement, and the off-ramp that turns stablecoins back into local currency in a bank account. Different providers usually own different layers, and your ledger ties them together."
  - q: "Who provides each layer of a stablecoin card stack?"
    a: "The card issuer and its sponsor bank own authorization, the card, and the network relationship. A funding and payout provider owns bank deposits, conversion, and local-currency payouts. A wallet provider or the issuer holds the balance. Your company owns the product, the cardholder relationship, and the ledger that reconciles every event across the providers."
  - q: "Is a stablecoin card authorization an on-chain transaction?"
    a: "No. Authorization runs over card network messaging, as with any debit card. The issuer checks the available balance and approves or declines in real time. In a just-in-time design, the issuer may pull stablecoins on-chain at that moment, but the approval message itself is card network traffic, not a blockchain transaction."
  - q: "How do you reconcile a stablecoin card program?"
    a: "Keep one internal ledger and post every provider event to it once, keyed on the provider's id: deposit and payin events from the funding layer, authorization, capture, and refund events from the card issuer, and payout events from the off-ramp. Reconcile the ledger daily against each provider's statement and against the on-chain wallet balance."
  - q: "What happens when a step fails in a stablecoin card program?"
    a: "Each layer fails differently. A deposit can be held for review or returned before it reaches the wallet. An authorization is declined when the balance or on-chain approval is short. A payout that cannot be delivered is refunded in stablecoins. Design each handler so your ledger only moves on a final, completed event."
  - q: "Do I need webhooks from every provider in a card stack?"
    a: "Yes. Polling is too slow for card authorization and too expensive for deposits and payouts at scale. Subscribe to the funding provider's deposit and payout webhooks, the card issuer's authorization and transaction webhooks, and verify every signature. Store raw events before processing so you can replay them if a handler fails."
---

*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](/resources/more/what-is-stablecoin-card-issuing).

## 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?"

| Layer | What it does | Typically provided by |
|---|---|---|
| 1. Onboarding | KYC on cardholders, KYB on your company, sanctions screening | Card issuer for card eligibility; funding provider for deposits and payouts; both may run checks |
| 2. Funding | Dedicated bank details or local payment instructions | Funding and payout provider (virtual accounts, local payins) |
| 3. Conversion | Fiat to stablecoin at a quoted rate | Funding and payout provider |
| 4. Wallet | Holds the stablecoin balance | Card issuer (custodial), wallet provider, or the cardholder (non-custodial) |
| 5. Card issuing | Card creation, authorization, controls, disputes | Card issuer, its BIN sponsor bank, and processor |
| 6. Network settlement | Moves money between issuer and acquirer | Visa or Mastercard, through the issuer |
| 7. Off-ramp | Stablecoin to local currency in a bank account | Funding and payout provider |
| Across all | Product, ledger, support, statements | You |

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](https://docs.stripe.com/issuing/bridge-stablecoin-cards)). 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](/resources/more/stablecoin-virtual-accounts-explained) 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](https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21951.html)). 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.

| Layer | Example events | What your handler does |
|---|---|---|
| Onboarding | `customer.update` (KYC status) | Allow card issuance and account creation on approval |
| Funding | `virtualAccount.complete` | Show account details in the app |
| Funding and conversion | `payin.new`, `payin.update`, `payin.complete` | Show "pending", then credit the ledger on completion |
| Card issuer | Authorization request, capture, refund, reversal | Approve or decline in real time; adjust holds |
| Off-ramp | `payout.new`, `payout.update`, `payout.complete` | Debit on creation, confirm on completion, handle refunds |

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

Verify every signature ([webhook verification](/docs/learn/webhooks-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](/resources/more/stablecoin-api-webhooks-reconciliation) and the [virtual account reconciliation guide](/resources/more/virtual-account-reconciliation) 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](https://www.visa.com/en-us/thought-leadership/innovation/financing-stablecoin-linked-card-programs)). 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](/resources/more/custodial-vs-non-custodial-off-ramps) 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](/docs/kb/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](/docs/kb/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](/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](/docs/payins) and [payouts docs](/docs/payouts), or [talk to the team](/contact).

## What to read next

- [What is stablecoin card issuing?](/resources/more/what-is-stablecoin-card-issuing)
- [Stablecoin card issuing platforms compared](/resources/more/stablecoin-card-issuing-platforms-compared)
- [Bridge cards and BlindPay payouts in one stack](/resources/more/bridge-cards-and-blindpay-payouts), a worked pairing of two layers
- [How to issue stablecoin-funded cards through an API](/resources/more/how-to-issue-stablecoin-cards-api), for the authorization handler code

## Sources

- Stripe, [Issue stablecoin-backed cards with Bridge](https://docs.stripe.com/issuing/bridge-stablecoin-cards)
- Stripe, [Real-time authorizations](https://docs.stripe.com/issuing/controls/real-time-authorizations)
- Visa, [press release on USDC settlement in the United States](https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.21951.html), December 16, 2025
- Visa, [on financing stablecoin-linked card programs](https://www.visa.com/en-us/thought-leadership/innovation/financing-stablecoin-linked-card-programs), September 8, 2026
- Bridge, [Global card issuance with stablecoins explained](https://bridge.xyz/learn/stablecoin-payments-global-card-issuance)

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