Funding a stablecoin card means putting stablecoin where the card issuer can authorize purchases against it. Cardholders usually start with local currency: they pay a bank account in their own name, the deposit converts to USDC or USDT in a wallet, and the card spends from it either at purchase time or from a balance loaded in advance.
How does a stablecoin card get funded?
A stablecoin card spends from a stablecoin balance, so funding it means getting USDC or USDT to the wallet the issuer authorizes against, on a network the issuer accepts. Where the money starts picks the route.
Three main routes to fund a stablecoin card, by where the money starts
Route | Money starts as | What breaks |
Local bank deposit | Local currency in a bank account | USD cut-offs, a minimum deposit, an expired top-up |
Stablecoin transfer | USDC or USDT already held | Wrong network or wrong token |
Exchange buy and withdraw | Fiat at an exchange | Spread, withdrawal fee, wrong network |
Most cardholders in Brazil, Mexico and Colombia are paid in local currency, so the rest of this guide follows the bank deposit, which is a stablecoin on-ramp. The card belongs to the issuer, and what stablecoin card issuing is covers that side.
On Lumx, the bank deposit is the built-in route. Each cardholder gets a named virtual account (a local account number issued in the customer's own name, explained in what a named virtual account is), and the deposit converts to stablecoin in the cardholder's wallet. A transfer from elsewhere works too, because every wallet has an address that accepts supported stablecoins.
Local rails that top up the card: Pix, SPEI and PSE
Pix (Brazil's instant payment system, run by the Central Bank), SPEI (Mexico's interbank transfer system, run by Banxico) and PSE (Colombia's online bank-transfer network) are the rails where a top-up feels like a card load: the cardholder pays from a banking app and does not wait for banking hours.
Top-up rails by currency, from the Lumx docs and Lumx facts as of November 2026
Currency | Rail | What the payer uses | Settlement | Cut-off |
BRL | Pix | A static QR code (brCode) carrying the reference | Instant, 24/7/365 | None |
MXN | SPEI | A CLABE plus a memo reference | Instant, 24/7/365 | None |
COP | PSE and Bre-B | A PSE payment from the payer's bank, or a transfer to the account's Bre-B key | Bre-B is instant. PSE timing is not published | None for Bre-B |
USD | ACH, FEDWIRE, SWIFT | Account and routing number, or BIC | ACH 1 to 2 business days, FEDWIRE same business day, SWIFT 1 to 5 | 2:00 PM ET for ACH, 3:00 PM ET for FEDWIRE and SWIFT |
EUR | SEPA | IBAN and BIC | SEPA Instant, or SEPA Credit Transfer for €100k or more between 4:30 PM and 2:30 AM UK time | None |
GBP | Faster Payments | Sort code and account number | Instant, up to £1M per payment | None |
For BRL and MXN the cardholder pays a code or a CLABE (the 18-digit Mexican bank account number) and the stablecoin follows, as on the BRL to USDC and MXN to USDC pages. In Colombia the two rails differ: Bre-B (Colombia's instant payment system) is a push to a key, while PSE is a pull, where the payer authorizes a debit from their own bank. PSE only brings money in.
Two numbers set the edges. A deposit converted through a standing rule must be worth at least 50 USD in the account's currency, or it is not converted. And an individual on standard KYC (know your customer, the verification of an individual) can move 7,500 USD per transaction and 15,000 USD per day, with higher tiers lifting both, as set out in limits and cut-offs by rail.
One named account per cardholder, or a quote per top-up?
A standing rule suits a cardholder who tops up often. A transaction per top-up suits one who wants the price before paying.
Two ways to run a top-up on Lumx, from the Lumx docs read on November 1, 2026
Standing rule on the account | One transaction per top-up | |
What the cardholder pays | The same Pix code or CLABE every time | A new payment instruction each time |
Amount | Any amount of at least 50 USD in the account's currency | The exact amount you set |
Rate | Market rate at conversion, no locked quote | Floating, or locked for 30 seconds at no fee, or for 1 or 5 minutes with a fee |
Expiry | None | Floating Pix and SPEI quotes expire after 1 day, other rails after 7, a locked quote with the quote |
A deposit that lands after a per-top-up payment has expired is refunded to the sender on the same rail, and the cardholder starts again. For USD, EUR and GBP a customer can hold one active rule per account.
The alternative is one shared account that feeds every card. It is one integration, but a deposit into it cannot be tied to a person, and pooling funds for people Lumx has not onboarded is nesting, which the nested payments rules prohibit. So each cardholder is a customer with their own account, a model that also serves business collections, as in named virtual accounts for B2B collections.
On Lumx, creating the rule returns the deposit details in sourceDepositInfo, and the cardholder keeps paying the same details afterward.
Just-in-time vs prefunded, and where collateral fits
The two models differ in when stablecoin is committed. Rain, a stablecoin card issuer, describes both in its real-time funding announcement. Before it, a user had to allocate stablecoin to a collateral contract ahead of any purchase and refill it as it ran low. With real-time funding, the user connects a wallet and approves how much the card may spend, each purchase is authorized against the wallet balance, and only the amount needed is committed to the collateral contract at authorization. The approval is revocable.
Prefunded and just-in-time funding, as Rain describes them on its public pages
Prefunded | Just-in-time | |
Stablecoin is committed | Ahead of spending, into a separate balance | At each authorization, only the purchase amount |
Idle money sits | In the card's balance | In the cardholder's wallet |
What the cardholder does | Allocates, then refills | Approves a limit once and can revoke it |
Rain's example: a user holds 1,000 USDC and approves all of it, and a 200 USD purchase commits 200 USDC at authorization while 800 USDC stays in the wallet. The feature is in beta at Rain, with USDC on Base, USDC on Arbitrum and USDT0 on Plasma listed at launch.
Collateral is the cardholder-side backstop: in Rain's model each user has a collateral contract, and the committed amount stays there until it is liquidated to repay Rain's extension of credit. Prefunding sits on the issuer side. Settlement runs on bank time, so Rain's anatomy of a card swipe article shows an issuer with 1 million USD of daily spend needing 4 million USD in an account by Friday night when Monday is a holiday. That idle money is the issuer's cost, and Rain notes that Visa and then Mastercard let issuers settle in USDC. The network side is in Mastercard settling in stablecoins.
On Lumx, the top-up side is prefunded in the plain sense: the deposit becomes stablecoin before any purchase and stays in the cardholder's wallet. A Rain card spends from that wallet once the cardholder connects it and approves a limit, and what is committed at authorization belongs to the issuer's flow. USDC on Base appears on both the Lumx wallet list and Rain's launch list.
Time and cost of a top-up
Over Pix, SPEI and Faster Payments the money arrives the same minute on any day. ACH takes 1 to 2 business days, and a request after the 2:00 PM ET cut-off, on a weekend or on a bank holiday waits for the next business day. A new cardholder adds onboarding: a standard KYC review targets one business day, and a USD account then takes up to one more.
Cost has three parts: the conversion rate on the quote, the partner fee, and the lock fee when a quote is held for more than 30 seconds. The platform sets the partner fee as a rate in basis points, a flat dollar amount or both. As an illustration, our example and not a Lumx price, 10 basis points plus 0.10 USD on a 500 USD top-up comes to 0.60 USD. The issuer's card fees are separate and sit in the program terms. Lumx itself charges a monthly platform fee plus usage-based per-transaction fees, with transparent FX on locked quotes and no pre-funding; there are no published plans.
On Lumx, the receipt on success carries the amounts, the exchange rate and the fees.
What goes wrong when you fund a card?
Most failed top-ups come from a wrong network, a deposit below the minimum, or a window that closed.
What breaks in a stablecoin card top-up, and the fix
What breaks | What happens | The fix |
Network the issuer does not read | The stablecoin lands where the card cannot see it | Pick the network once on the rule and match the issuer's list |
Deposit under 50 USD | It is not converted | Show the minimum on the top-up screen |
Expired top-up | A late deposit is refunded on the same rail | Show a timer and offer a new top-up |
Dropped SPEI memo | The deposit cannot be matched to the rule | Show the CLABE and memo together |
Limit exceeded | Rejected with 422 and TRANSACTION_LIMIT_EXCEEDED | Read the remaining limit before creating the transaction |
Compliance hold | Held pending review | Keep documents ready and answer within 24 hours |
I recommend crediting the cardholder in your app only when the funding webhook reports success, never when the top-up is created. A created top-up is a promise to pay, and on a card it becomes a spend limit the cardholder can use before the money exists. I would also show the approved card limit next to the wallet balance, because the two numbers answer different questions: what is there, and what the card may take.
On Lumx, a compliance hold is an RFI (request for information, a compliance hold that asks for a document before a transaction clears), and it reaches your app as the account.rfi or customer.rfi webhook. A top-up that runs out of time fires onramp.expired, and one that fails fires onramp.failed.
Cashing out what is left
Cash-out starts with the platform, not the card. Your app calls the API to withdraw from the cardholder's wallet, the stablecoin converts to local currency, and it goes over a local rail to a destination the cardholder registered as their own, with the holder relationship set to SELF. The rails mirror the top-up ones, with Bre-B or ACH Colombia for COP.
A withdrawal larger than the wallet balance fails with an insufficient-balance error. Cap it lower: the withdrawable amount is the wallet balance minus what open card authorizations have already committed. A cash-out quote can be locked for 30 seconds at no fee.
On Lumx, the withdrawal is an off-ramp transaction, and offramp.success fires once the local payment leaves the banking partner.
When funding a card this way is the wrong tool
A cardholder who already holds USDC on a network the issuer accepts should send it straight to the wallet, because a bank deposit adds a conversion and a delay. The route is also wrong when the money is not the cardholder's: a platform that collects funds for many users in one account and releases them to cards later is running a pooled account, so onboard each cardholder instead. And a dollar stablecoin funded in BRL and spent in reais converts currency twice, so a cardholder who earns and spends in one currency may be better served by a plain local transfer.
What funding a card looks like on Lumx
In a card program the issuer provides the card, and Lumx handles the local-currency deposit that becomes stablecoin and the cash-out to a local bank account.
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.
For a card program, each cardholder is a customer. You create them with the currencies they need, they complete KYC through Sumsub (reusable through Sumsub token sharing), and account.active tells you when each account can receive funds. The top-up is an autoconversion rule or one on-ramp per top-up, delivering USDC on Ethereum, Polygon or Base, or USDT on Ethereum, Polygon or Tron. The onramp.success webhook lets the card app mirror the wallet balance without polling, and it should credit the cardholder on that event only.
The partner fee applies only when the request carries a partnerFeeId, and it comes on top of what the payer funds, with no cap and no variation by corridor. Rails by country are on the coverage page and onboarding jurisdictions on the supported countries page. See also named virtual accounts, global payments and Lumx vs Rain.
Methodology and sources
We read the Lumx documentation and the Rain public pages on November 1, 2026.
Lumx docs: Coverage, Accounts, Wallets, Autoconversion rules, Transactions, Exchange rates, Partner fees, Transaction limits, Cut-off times, RFI, Webhooks
Rain public pages, named in the text and read on November 1, 2026: "Introducing real-time funding" and "The Anatomy of a Stablecoin Card Swipe"
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
How do you fund a stablecoin card?
You put USDC or USDT in the wallet the card issuer authorizes against, on a network the issuer accepts. From a bank account, the cardholder pays a local account in their own name over Pix, SPEI, PSE, ACH, SEPA or Faster Payments, and the deposit converts to stablecoin. On Lumx, each cardholder is a customer with a named account per currency, and an autoconversion rule converts every deposit to USDC or USDT in their wallet, so there is no separate step to load the card.
Can you fund a stablecoin card with Pix or SPEI?
Yes. The cardholder pays a Pix code in Brazil or a CLABE with a memo in Mexico, and the deposit converts to stablecoin in their wallet. A deposit must be worth at least 50 USD to convert through a rule. On Lumx, the Pix code or the CLABE and memo carry the reference that matches the deposit to the rule.
What is the difference between just-in-time and prefunded stablecoin cards?
A prefunded card needs stablecoin committed ahead of spending, into a balance separate from the wallet. A just-in-time card commits only the purchase amount at authorization and leaves the rest in the wallet, under a limit the cardholder approves and can revoke. On Lumx, the deposit becomes stablecoin in the cardholder's wallet before any purchase, and the issuer's authorization flow decides what is committed at each one.
What are prefunding and collateral in card issuing?
Prefunding is money an issuer holds ahead of time to pay the card network, because settlement runs on bank time. Collateral is the stablecoin held in a contract that backs the credit the issuer extends at each authorization. On Lumx, the work sits on the wallet side: the deposit becomes stablecoin in the cardholder's wallet, and settlement and collateral stay in the issuer's program.
How long does a stablecoin card top-up take?
Over Pix, SPEI and Faster Payments the money arrives the same minute, on any day. A new cardholder adds a KYC review that targets one business day. On Lumx, BRL, MXN, EUR and GBP accounts go active right after approval, a USD account takes up to one business day, and the onramp.success webhook tells your app when the stablecoin has landed.
