Rain card top-up with Pix, SPEI and PSE, and cash-out to local banks

A Rain card top-up is a local-currency deposit, not a card-loading step. The cardholder pays a named account in their own name over Pix (Brazil's instant payment system), SPEI (Mexico's interbank transfer system), PSE (Colombia's online bank-transfer system), ACH, SEPA or another local rail, the deposit converts to USDC or USDT in their Lumx wallet, and the Rain card spends from that wallet balance within a limit the cardholder approves. Cash-out is an off-ramp from the same wallet to a bank account the cardholder registered.

How does a Rain card top-up work?

Rain issues the card, and its real-time funding lets the card spend straight from a wallet the user connects. The user approves how much the card may spend. At each purchase only that purchase's amount moves to the collateral contract, and the rest stays in the wallet. The approval can be revoked. There is no "load the card" step, so the top-up is the deposit that puts stablecoin in the wallet, and the cash-out is an off-ramp from it that the platform starts through the Lumx API.

What the cardholder sees is short: they pay a local account, a balance shows up in the wallet, they approve a spend limit once, and they pay with the card. To cash out, the app shows a quote, the cardholder confirms, and the local payment arrives in their bank.

A fintech assembles this stack for itself, and Rain's terms govern the card. For the Rain and Lumx comparison itself, see Lumx vs Rain. On the network side, see Mastercard settling in stablecoins.

Which currencies and rails can fund the card?

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 like any domestic transfer, and the platform converts the deposit to a stablecoin. Named accounts exist in BRL, MXN, COP, USD, EUR and GBP, and each currency has its own rail and payment details.

Top-up rails by currency, from the Lumx docs read on October 29, 2026.

Pix and SPEI are the two corridors where the top-up feels like a card load: the cardholder scans a code or types a CLABE (18-digit Mexican bank account number) and the money arrives without a banking-hours queue. See the BRL to USDC conversion and the USDC to MXN page.

For a single expected top-up, you create an on-ramp for the exact amount. For a recurring one, an autoconversion rule converts every matching deposit to USDC or USDT on the network you pick, with no call per deposit. BRL and MXN rules carry the reference inside the payment details, so a Pix code or a SPEI memo does the matching. For USD, EUR and GBP the account itself identifies the cardholder, which is why those currencies allow one active rule per account. Each deposit must be worth at least 50 USD in the account's currency, and a smaller one is not converted (see autoconversion rules).

An on-ramp has a payment window. A floating-rate Pix or SPEI top-up expires after one day, other rails after seven, and a locked quote expires with the quote. A deposit after expiry goes back to the sender on the same rail, and the cardholder starts a new top-up.

I recommend one named account per cardholder over a shared account that feeds every card. The shared account is one integration instead of thousands of onboardings, but a deposit into it cannot be tied to a person, so the card balance, the compliance record and the reconciliation each need a guess. I would onboard each cardholder once and let the account carry the name.

Wallet, chains and the spend approval

After conversion the stablecoin sits in the cardholder's Lumx custodial wallet, and the Rain card spends from there. Lumx wallets run on Ethereum, Polygon, Base and Tron. Rain's public wallets page lists Ethereum, Polygon, Base, Celo, Optimism, BNB Smart Chain, Avalanche, Arbitrum, ZKsync, Monad, Solana and Plasma. Ethereum, Polygon and Base appear on both lists.

On the Lumx side, USDC and how it works runs on Ethereum, Polygon and Base. USDT runs on Ethereum, Polygon and Tron. Stellar carries USDC for on-ramps only. Pick the network once on the autoconversion rule and keep it the same for that cardholder's wallet balance, so the stablecoin that lands is the one the card approval points at.

The spend approval is the cardholder's control. They set how much the card may spend, only the amount of each purchase is committed at authorization, and they can revoke the approval at any time. Your app should show the approved limit next to the wallet balance, because the two are different numbers.

Cash-out to a local bank, rail by rail

Cash-out starts with the platform, not the card. Your app calls the Lumx API to run an off-ramp from the cardholder's wallet. The off-ramp converts the stablecoin to local currency and sends it over a local rail to a destination the cardholder registered as their own account (holder relationship: self).

Cash-out rails by currency, from the Lumx docs read on October 29, 2026.

In Asia-Pacific (Singapore, Hong Kong, Japan), cash-out is USD over SWIFT, 1 to 5 business days, or the stablecoin sent to a wallet the cardholder controls. Put the expected arrival time on the cash-out screen next to the quote so the cardholder knows it before confirming.

A locked quote fixes the rate for 30 seconds at no fee, or for one or five minutes with a fee that covers volatility.

Where Rain's own USD and MXN accounts fit

Rain's virtual accounts are issued in the end user's legal name with static routing and account numbers, with ACH and FedWire named for USD and SPEI named for MXN. Lumx names accounts in BRL, MXN, COP, USD, EUR and GBP. Both sides issue accounts in the user's name, so the choice follows the currency the cardholder earns in. Whether a given Rain account can fund a given card is set in your Rain program.

What breaks between top-up and cash-out?

Most failures here are timing and mismatched assumptions. Plan for the RFI (request for information, a compliance hold that asks for a document before a transaction clears).

Every payment must belong to a customer the provider has onboarded, acting on their own funds, which is why a shared top-up account hides counterparties from sanctions screening and defeats transaction monitoring (see nested payments). Onboarding each cardholder with KYC (know your customer, the verification of an individual) keeps the structure inside the rules.

One cardholder's month, and how to reconcile it

The numbers are illustrative, not a real customer. The rate is a round figure, and the fee comes from the quote at each step.

1. The cardholder tops up R$ 3,000 by Pix to the named BRL account. At an illustrative R$ 5.00 per dollar, the rule converts it to 600 USDC before the fee, and onramp.success fires. The wallet holds 600 USDC.

2. The cardholder approves a spend limit on the card. Nothing moves yet.

3. The cardholder spends 420 USD on the card. Each purchase commits its amount at authorization and settles later, so the wallet falls to 180 USDC. Holds and settlement are Rain's side, and your app learns of them from Rain's card events.

4. A 30 USD authorization is open. The withdrawable amount is the wallet balance minus what open authorizations commit: 180 minus 30 is 150.

5. The cardholder cashes out R$ 500, which is 100 USD at the illustrative rate. The app shows a quote locked for 30 seconds, the cardholder confirms, and offramp.success fires once the Pix payment is sent, with the net amount received. 50 USD stays withdrawable.

Keep one ledger per cardholder, owned by your app: available = credits minus debits minus open authorizations. Top-ups are credits, cash-outs are debits, and Rain's card events supply the authorizations. Use the customer and the transaction id on each event as the join key, and flag any cardholder whose events do not net to the balance. In the example, 600 credited, 420 spent, a 100 USD cash-out and an open 30 USD authorization leave 50. A failed payout or refunded deposit should reverse its own entry. Event names for authorizations and settlement are in Rain's gated API documentation.

Where this stack does not fit

Not every card program needs a fiat leg. If your cardholders already hold USDC in a wallet, a bank rail in front of the card adds steps they do not need, because the card can spend from that wallet.

The stack is also the wrong shape 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, and every deposit in it loses its link to a named payer.

Lumx in a card program

Lumx supplies two legs of a stablecoin card program: local-currency top-up in and cash-out to a bank account on the way back. In the stack this guide describes, the card issuer is Rain, and the fintech contracts and integrates it separately from Lumx.

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. Fees and spreads are quoted per transaction, and the quote shows them before the cardholder confirms.

For a card program, each cardholder is a customer: you create them with the currencies they need, they complete KYC through Sumsub, and the accounts go active on approval. The top-up is an on-ramp or an autoconversion rule on that account, the card spends from the wallet, and the cash-out is an off-ramp to a registered destination that your platform starts through the API. The Lumx legs emit webhooks (onramp.success, offramp.success), so the card app can mirror the wallet balance without polling a chain.

Account and customer RFIs reach your app by webhook (account.rfi, customer.rfi). A transaction hold is resolved with Lumx compliance, and a response is needed within 24 hours or the transaction may be refunded (RFI). The named virtual accounts product page covers the account model, and the global payments page covers the rails and conversion around it. The stablecoin legs have explainers on what a stablecoin on-ramp is and what an off-ramp is, and rails by country are on the coverage page.

Methodology and sources

We read the Lumx documentation and the Rain public pages on October 29, 2026. Rain's API documentation is access-gated, so every Rain statement here comes from its public site, and nothing about its API or its event names is assumed.

• Lumx docs: Coverage, Accounts, Wallets, Autoconversion rules, Payment rail cut-off times, Nested payments, RFI

• Rain public pages: Card issuing, Wallets, Virtual accounts, Real-time funding (cited for the spend-from-wallet model and the revocable approval)

Verified on October 29, 2026. Operational context, not legal, tax, or investment advice.

Cover photo: Frantisek Duris on Unsplash.