Funding a stablecoin payout means getting USDC or USDT into the wallet that the payout debits, on a network the payout can use, before you create it. You either deposit local currency that converts to stablecoin or transfer stablecoin you already hold. The payout then converts that balance into the payee's currency and sends it.
Which routes can fund a payout wallet?
A payout debits a balance, so funding is only the work of making that balance exist. Two routes cover almost every case, and the choice follows where the money starts.
Two routes into the wallet a payout debits, by where the money starts
Route | Money starts as | Arrives as | What to check first |
Bank deposit | Local currency at a bank | Stablecoin, converted on arrival | The rail's cut-off, the deposit window, the minimum |
Stablecoin transfer | USDC or USDT you already hold | The same token, on the network you sent it on | The network and the token, before the full amount |
The fiat side has its own guide, how to fund a stablecoin on-ramp, and this one stays on the stablecoin side: which wallet, which network, how you know the balance is there, and how much to put in. The conversion into the payee's currency is what a stablecoin off-ramp does, and cost sits in how stablecoin payout pricing works.
On Lumx, both routes end in the same place: the customer's wallet. The balance in it is what an off-ramp debits, whichever route filled it.
The wallet, the network and the token a payout debits
A payout does not pull stablecoin from an address you control at the moment you press send. It debits a balance that already sits in a wallet the provider holds for you, which is why this guide is about getting the balance there. The wallet model is described in what a custodial wallet is.
Two choices must match the payout: the token and the network. A wallet holds a separate balance per network, so USDC on one network cannot pay a payout that debits another.
Wallet networks and tokens, from the Lumx wallets and coverage docs read on November 1, 2026
Network | Tokens in the wallet | Currencies on the coverage page |
Ethereum | USDC, USDT | BRL, USD, EUR, MXN, GBP |
Polygon | USDC, USDT | BRL, USD, EUR, MXN, GBP |
Base | USDC | BRL, USD, EUR, MXN, GBP |
Tron | USDT | BRL, USD, EUR, MXN, GBP |
Stellar | USDC | BRL on-ramp only, not a payout network |
COP accepts the same networks as the other payout currencies. Only the networks in the table can fund a wallet, so check the network before you send. Which network is cheapest or deepest for a given corridor is a separate decision, and Stellar, Ethereum, Polygon and Tron compared makes it. For the token, what USDC is and USDT on Tron for business payouts cover the two common choices.
On Lumx, creating a customer provisions a wallet on each supported network, and the wallet is enabled for use once the customer reaches APPROVED. A project sets a default network, and an off-ramp that names no blockchain debits the default.
Funding from a bank deposit
A bank deposit suits a business that holds fiat and pays in another currency. The payer sends local currency to an account in the customer's name, the deposit converts to USDC or USDT, and the stablecoin lands in the wallet. How to off-ramp USDC to GBP walks through one such payout in pounds.
Two things set the pace. The rail sets when the deposit arrives: Pix (Brazil's instant payment system, run by the Central Bank) and SPEI (Mexico's interbank transfer system, run by Banxico) run every day at any hour, ACH takes 1 to 2 business days and has a 2:00 PM ET cut-off, and FEDWIRE settles the same business day with a 3:00 PM ET cut-off. And the window sets how long the payment instruction lives: a floating Pix or SPEI on-ramp expires after 1 day, other rails after 7, and a locked quote expires with the quote.
A deposit that lands after the window is not converted. It goes back to the sender on the same rail, so the next step is a new on-ramp, not a wait.
On Lumx, a standing autoconversion rule on a BRL, MXN, COP, USD, EUR or GBP account converts every deposit to the stablecoin and network you chose, with no call per deposit. Each deposit must be worth at least 50 USD in the account's currency to convert, and the rule converts at the market rate, so it takes no locked quote.
Funding from stablecoin you already hold
If the stablecoin is already yours, skip the conversion and send it to the wallet. Read the wallet address for the network you hold the token on, send a small amount first, then send the rest.
Match two things before the full amount goes: the network and the token. An address for one network does not receive on another, and a token the wallet does not list is not a balance you can pay out from. On Lumx, you send supported USDC or USDT to the wallet address for the blockchain you chose, with no on-ramp and no conversion. To see the balance, read the customer: GET returns each wallet's address, blockchain, and balances per token with an updatedAt stamp. Between two onboarded customers, the Transfer endpoint moves USDC or USDT from one wallet to the other, and the transfer.success webhook reports it.
What counts as funded, and how long does it take?
A payout is funded when the balance it debits is in the wallet, not when the money has left your side and not when a block count is reached. The balance is the test. Three clocks run in sequence, and only the last one is yours to read.
From deposit to a balance you can pay from, by route
Step | Bank deposit | Stablecoin transfer |
Money moves | The rail's own time: instant on Pix and SPEI, 1 to 2 business days on ACH | The network's own time to finalize the transfer |
Conversion | The on-ramp passes through TRADING | None |
Balance shows | After TRANSFERRING_STABLECOIN reaches SUCCESS | When the wallet balance updates |
Event to listen for |
| Read the balance, then pay out |
Block confirmations are the network's business: each chain finalizes at its own pace, and a provider credits a deposit after its own threshold. Lumx has no webhook yet for a deposit that arrives from an outside wallet, so the balance is the answer to the confirmations question: read it before you create the payout rather than counting blocks. A new customer also has to be approved first, and a standard KYB (company verification) review targets one business day.
A concrete run on a USD account shows the clocks. On Wednesday you wire the first 50,000 USD before the 3:00 PM ET FEDWIRE cut-off, and it settles the same business day. A standing autoconversion rule converts it at the market rate, and onramp.success fires. On Thursday you read the customer and see the balance. On Friday you create the batch. A wire sent after 3:00 PM ET waits for the next business day, so the cut-off decides whether Wednesday counts.
On Lumx, an on-ramp moves from AWAITING_FUNDS through TRANSFERRING_FIAT, TRADING and TRANSFERRING_STABLECOIN to SUCCESS, and the onramp.success webhook fires when the wallet is credited.
How much to fund, and how often
Fund a wallet once for a run and pay many times from it, rather than depositing for every payout. A wallet keeps its balance between operations, so a Friday payroll can be funded on Wednesday and paid out in one pass.
Four things size the balance. The first is the run itself: the sum of its payouts plus the buffer you want for rate moves. The second is the customer's limits: a standard KYB customer can move 50,000 USD per off-ramp and 100,000 USD per day, while a standard KYC (know your customer, the verification of an individual) individual can move 7,500 USD per transaction and 15,000 USD per day. The third is the funding side: an on-ramp has its own limit, 50,000 USD per transaction and 100,000 USD per day for a standard KYB customer, and that caps how fast you can fill the wallet. The fourth is the type: on-ramps, off-ramps and transfers each count against their own limit, so a funding deposit never uses up payout headroom, but it can hit its own cap.
As an illustration, 40 payees at 2,500 USD is 100,000 USD for the run, which sits exactly on the daily off-ramp limit of a standard KYB customer. Funding it takes two on-ramps of up to 50,000 USD each, which also sits exactly on the daily on-ramp limit, so fund the day before the run. A single 105,000 USD deposit would be rejected at the funding step, before any money moves.
<!-- OPERATOR PARAGRAPH --> I recommend funding once per run and checking the wallet balance before building the batch, never per payout. I would also fund less than the limit allows, because a balance above what the day can move is idle money with no use that day.
On Lumx, includeTransactionLimits=true on the customer read returns max, used and remaining for each daily and monthly window, so the app can compare the run against the headroom before it creates anything.
What goes wrong when you fund a payout?
Most funding failures are a wrong balance, a wrong network or a closed window. Each one has a visible signal, and the cheapest fix comes before the full amount moves.
What breaks when you fund a stablecoin payout, and the fix
What breaks | What you see | The fix |
Payout larger than the balance |
| Read the balance first and cap the batch to it |
No wallet on the network you named |
| Name a network the customer's wallets list |
Deposit after the window closed | Refunded to the sender on the same rail | Create a new on-ramp and show a timer |
Locked rate expired | The | Request a new rate and submit inside the lock |
Over a limit |
| Lower the amount, wait for the window or request higher limits |
Compliance hold | The transaction waits for review | Answer compliance within 24 hours, by email to operations@lumx.io |
Token on a network the wallet does not list | Recovery depends on the holder of the address | Send a small test first and confirm the balance |
Sending on the wrong network is the failure that costs the most, because the provider that owns the receiving address decides what happens next. Treat any wrong-network send as unrecovered until that provider says otherwise, and ask before you send again.
On Lumx, on-ramps and off-ramps flagged by transaction monitoring are held as an RFI (request for information, a hold that asks for context before a transaction clears). Compliance contacts you by email or Slack, and a request left unanswered for 24 hours may end in a refund to the sender.
When funding a payout this way is the wrong tool
A wallet balance is the wrong tool when the money is not the customer's. Pooling funds from several people into one wallet and paying others out of it is nesting, and the provider has to see every payer and payee, so each one must be onboarded as a customer with a wallet of their own.
It is also the wrong tool for a payee in the currency you already hold. If your fiat is in reais and the payee wants reais, a local transfer skips two conversions.
How funding a payout works on 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.
A payout is an off-ramp: it debits the customer's wallet on the network you name, converts the stablecoin, and sends the local currency to a destination registered under the same customer. There is no approval transaction to sign on the blockchain for each payout, because the balance is already in the wallet. The destination carries a holder relationship, which is how a payout to a supplier differs from a payout to the customer's own account.
For the rate, an off-ramp can take a floating rate or an exchangeRateId from a locked rate of 30 seconds at no fee, or 1 or 5 minutes with a fee. A webhook, offramp.success, fires once the local payment has left the banking partner. A run funded on Wednesday can therefore pay at any hour its rails allow.
Rails and currencies are on the coverage page, and the payout side of the product is under global payments and custodial wallets. The Brazil leg is in sending USDC to Brazil, with the rate on the USDC to BRL page. The calls themselves are in how to integrate a stablecoin API.
Methodology and sources
We read the Lumx documentation on November 1, 2026: Wallets, Coverage, Transactions, Accounts, Autoconversion rules, Exchange rates, Transaction limits, Cut-off times, Errors, Webhooks, Nested payments and the Treasury management guide. Network finality is not quoted because each chain sets its own and providers apply their own credit thresholds.
Verified on November 1, 2026. Operational context, not legal, tax, or investment advice.
Cover photo: Lukas Kyzur on Unsplash.
How do you fund a stablecoin payout?
You put USDC or USDT in the wallet the payout debits, on the network the payout will use, and then create the payout. The money can start as local currency at a bank or as stablecoin you already hold. On Lumx, a bank deposit converts to stablecoin in the customer's wallet, a transfer to the wallet address needs no conversion, and an off-ramp then debits the balance.
Which networks and tokens can fund a payout?
USDC and USDT, on the network the wallet holds them on, matched by network and token together. On Lumx, a wallet holds USDC and USDT on Ethereum and Polygon, USDC on Base and USDT on Tron, and each of those funds a payout. Stellar USDC is delivered by the BRL on-ramp only, not as a payout network, and the coverage page lists the currency pairs.
How long until a funded payout can be sent?
As long as the slowest step before it. A Pix or SPEI deposit arrives at any hour, ACH takes 1 to 2 business days, and a stablecoin transfer takes the time its network needs. On Lumx, you can pay out once the balance shows in the wallet, and the onramp.success webhook tells your app when a bank deposit has converted.
What happens if you fund a payout on the wrong network or token?
The balance may not appear where the payout debits it, and recovery depends on the provider that holds the receiving address. Send a small test amount first and confirm the balance before the rest. On Lumx, the customer read lists the wallets per blockchain with their addresses, so you can check the address and network before the small transfer goes out.
Should you prefund a stablecoin payout or fund each one as it comes?
Prefund once per run when you pay many people, because a wallet keeps its balance between payouts and a delay in one deposit then holds up none of them. Fund per payout only when payments are rare and small. On Lumx, the wallet balance persists between operations, and a limit read before the run shows how much the customer can move that day.
