What is stablecoin card issuing? How local rails fit in

Stablecoin card issuing is the practice of issuing Visa or Mastercard cards whose spending balance is a dollar stablecoin such as USDC or USDT instead of a bank deposit. When the cardholder pays, the card program converts the stablecoin to local currency, and the merchant is paid over the normal card network without ever touching a stablecoin.

The card itself is ordinary. What changes is the balance behind it, one conversion step, and the way the balance gets in and out. This explainer covers the mechanics, the companies in the stack, and the part most card explainers skip: how a cardholder in Brazil, Mexico or Colombia puts local money onto the balance and takes it back out.

What is a stablecoin-backed card?

A stablecoin-backed card is a debit-style card that draws on a stablecoin balance. Almost every card program uses a dollar stablecoin, a coin redeemable 1 to 1 for US dollars (see what a stablecoin is). Behind the card sits a wallet or a ledger entry that says how many USDC or USDT the person can spend.

Can a merchant accept the stablecoin directly? In practice, no: a coffee shop's terminal speaks Visa or Mastercard, so the card program converts the stablecoin during authorization or settlement, and the merchant is paid in its own currency. The network, the issuing bank and the dispute rules are the same as for any card, and only the funding side is new.

The first crypto cards spent a volatile asset such as bitcoin, so the balance needed for a purchase moved with the market. A dollar stablecoin keeps that arithmetic simple, and the table at the end of this post points to the full comparison. In a Lumx setup, the balance is USDC or USDT held in a custodial wallet, provisioned together with the customer and enabled once the customer is approved.

How does a stablecoin card payment work?

Every card payment has two phases. Authorization happens at checkout and takes seconds. Clearing and settlement follow, usually the next business day. A stablecoin card program hooks into both.

1. Authorization. The merchant's acquirer sends the request through the network to the card processor, which asks the program one question: can this card pay? The program checks the balance, converts the amount at the current rate, places a hold and approves or declines. How the balance check works depends on the funding model: a prefunded program checks the balance it already holds, while a real-time funding program commits the purchase amount to the collateral contract at authorization.

2. Clearing. The merchant submits the final amount, which can differ from the authorized one (a tip, for example), and the program adjusts the hold.

3. Settlement. The network nets the day's purchases and moves money between issuers and acquirers, and the acquirer pays the merchant in local currency on its usual schedule.

Programs fund the card in one of two ways. In real-time funding, the stablecoin stays in the wallet until a purchase happens, and only that purchase's amount is committed at authorization. Rain, a card issuing platform, describes its real-time funding this way on its site: the user approves how much the card may spend, the rest stays in the wallet, and the approval is revocable. In prefunded programs, the balance is converted ahead of spend and held until it is used. The sibling guides on settlement and funding are listed in the table at the end of this post.

Lumx is not in the authorization path. Its part comes before it: a local deposit becomes the stablecoin in the wallet the card spends from, and an on-ramp (the conversion of fiat to stablecoin, covered in what a stablecoin on-ramp is) emits an onramp.success webhook when the balance is credited.

Who runs each layer of a card program?

A card program is a stack of companies, each with a regulated job. A stablecoin program keeps the same stack and adds a funding layer on top, which is where the local rails enter.

The roles in a stablecoin card program and what each one does.

In many arrangements a sponsor bank is the issuer of record and the program runs under its oversight. The funding layer is regulated too: depending on the country, the company converting stablecoin to local currency is a VASP (virtual asset service provider, the FATF term, explained in what a VASP is), a money services business, or both.

Lumx supplies the funding and cash-out layer for customers that run a card program. Each cardholder is a Lumx customer with their own KYC (know your customer, the verification of an individual), and the local account and wallet that fund the card are in that cardholder's name. The KYC can be reused through Sumsub token sharing, so a cardholder already verified elsewhere does not start over.

How the card settles with the networks

Visa announced on December 16, 2025 that US issuer and acquirer partners can settle with Visa in USDC, with Cross River Bank and Lead Bank first, settling over Solana (Visa press release, read November 1, 2026). On June 3, 2026, Mastercard announced plans to let issuers and acquirers settle some transactions in regulated stablecoins, including on weekends and holidays, with ARQ (formerly DolarApp), CBW Bank, Cross River, Lead Bank and Nuvei expected to be among the first. Mastercard's newsroom blocks automated readers, so we cite the date and not a link. Our news post on Mastercard's settlement move covers the week it landed.

This changes how an issuer meets its obligation to the network, and nothing the cardholder or the merchant sees. Network settlement is a leg between issuer and network, and Lumx does not run it. Lumx runs the leg between the cardholder's bank and the cardholder's stablecoin balance, in both directions.

How a card balance gets funded and cashed out on local rails

A cardholder in São Paulo holds reais in a bank account and will want reais back. A card program that ignores this asks them to buy stablecoin on an exchange first. The local-rail version replaces that step with a deposit that looks like any domestic transfer.

The cleanest top-up gives each cardholder a named virtual account (a local account number issued in the customer's own name) in the currency they earn in. The cardholder pays it by Pix (Brazil's instant payment system), by SPEI (Mexico's interbank transfer system) to a CLABE (the 18-digit Mexican bank account number), or in Colombia by PSE (Colombia's online bank-transfer network) or Bre-B (Colombia's instant payment system). Once matched, the deposit converts to USDC or USDT in the cardholder's wallet. Cash-out runs the other way: an off-ramp (see what a stablecoin off-ramp is) from the wallet to a local bank account the cardholder registered.

Funding and cash-out by currency, from the Lumx docs and Lumx facts as of November 2026.

A deposit converts only when it matches either an on-ramp created for the exact amount or an active autoconversion rule. For one expected top-up, the platform creates the on-ramp. For a recurring one, a rule converts every matching deposit with no API call per deposit, and each deposit must be worth at least 50 USD in the account's currency. A deposit that arrives after its on-ramp expired is refunded on the same rail. Lumx supports USDC on Ethereum, Polygon and Base and USDT on Ethereum, Polygon and Tron, per its Coverage page. The conversion pages for BRL to USDC and USDC to BRL show the pair in detail.

I recommend treating the card as the last step of the flow and the local deposit as the first, and designing the cardholder's screens from the deposit backward. If the cardholder cannot see how a Pix payment becomes spendable balance, the card is the smallest part of the product they are judging. I would also onboard each cardholder as their own customer from day one, because a shared deposit account cannot tell you whose money is whose when a card authorization is open and a withdrawal arrives at the same time.

On the Lumx side, a payout starts when the platform calls the API: the off-ramp debits the cardholder's wallet and sends local currency to the registered destination, and a payout larger than the wallet balance fails with an insufficient-balance error. The off-ramp does not see open card authorizations, so the platform caps cash-out at the balance minus what they commit.

What stablecoin cards change, and what they do not

Identity checks stay: every cardholder passes KYC and every business that runs a program passes KYB (know your business, the verification of a company and its owners). Disputes stay on the card leg, while the blockchain transfer that funded the wallet cannot be reversed. For the rules that apply, see the compliance, regulation and tax guides in the table at the end of this post. Costs depend on the program.

What changes is who the card suits. Platforms paying freelancers or sellers abroad use it so the payee needs no account in the platform's country. Companies holding treasury in USDC issue cards against it. In Latin America the funding side decides the product: the useful card takes a Pix or SPEI deposit and returns local money on demand. Where the use is a payout rather than spend, the same stablecoin can go straight to a bank account, which is the subject of our global payments product page.

At the funding point, Lumx applies the same logic: each cardholder is a customer with KYC through Sumsub, and every payment has to come from or go to someone Lumx has onboarded.

When a stablecoin card is the wrong tool

A card is the wrong tool when the person getting paid already has a local bank account and wants the money there. Issuing a card adds a sponsor bank, a processor and a program review to a payment that a Pix or SPEI payout settles in seconds.

It is also the wrong tool when the money does not belong to the cardholder. A platform that holds funds for many users in one account and releases them to cards later is running a pooled account, where every deposit loses its link to a named payer.

What Lumx does in a card program

Lumx is stablecoin payments infrastructure for businesses that move money between Latin America and the rest of the world: one API to collect, hold, convert, and pay out in BRL, MXN, COP, USD, EUR, and GBP or in USDC and USDT, over local rails such as PIX, SPEI, PSE, Bre-B, ACH, FEDWIRE, SEPA, and Faster Payments, with SWIFT and on-behalf-of payments and collections (POBO and COBO) in USD, EUR, and GBP, plus named virtual accounts, custodial wallets, and KYB/KYC built in.

Lumx carries the funding and the cash-out for cardholders. The card itself comes from the program's issuing stack. The top-up is a deposit over a local rail into the cardholder's named account, and the cash-out is an off-ramp the platform starts through the API. The named virtual accounts page covers the account model, and the coverage page lists rails by country.

Where to go deeper

Sub-questions this explainer touches and the guide that answers each in full.

Methodology and sources

We read the Lumx documentation (Coverage, Accounts, Wallets, Transactions, Autoconversion Rules, Destinations and cut-off times), Visa's press release of December 16, 2025 and Rain's real-time funding article on November 1, 2026 (Rain is compared with Lumx in Lumx vs Rain). Mastercard's June 3, 2026 announcement is cited by date only, because the Mastercard newsroom returned an access-denied response to automated readers. Bre-B's per-payment cap of 1,000 UVB comes from the Banco de la República's Circular Reglamentaria Externa DSP-465, Asunto 18, numeral 3.2, in the March 31, 2026 edition.

Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.

Cover photo: Jyotirmoy Gupta on Unsplash.