How stablecoin payments work: every step, every party

A stablecoin payment is a transfer that runs in three legs. The sender's money is collected and converted into a dollar stablecoin such as USDC or USDT, the stablecoin moves between wallets on a blockchain, and it is converted again and paid into the recipient's bank account over a local rail. The sender pays in dollars, and the recipient receives reais without ever handling the stablecoin.

This post follows one payment, a US company paying a supplier in Brazil, names every party the money touches and which of them Lumx is, and shows where it can stall. For the route as a concept first, read what a stablecoin corridor is.

Who touches the money in a stablecoin payment

A payment looks like one transfer and is eight roles inside, six of them separate parties and two of them functions. The table lists them in the order the money meets them.

The parties in a USD to BRL stablecoin payment and the role Lumx plays in each (as of November 2026).

Lumx is not an issuer, since Circle issues USDC and Tether issues USDT, and it is not a bank. What it runs is the custodial wallet, the conversion and the screening.

Step 1: the sender is verified before any money moves

Nothing starts until the sender is verified. A company goes through KYB (know your business, the verification of a company and its owners), and an individual goes through KYC (know your customer, the verification of an individual).

The Travel Rule sits on top. It is the reason a stablecoin payment has a named sender and a named recipient: the identifying details travel with the transfer. The FATF published a revised Recommendation 16 on payment transparency on June 18, 2025, as recorded in a notice from Japan's Financial Services Agency. The Travel Rule guidelines cover where the rule comes from and how it is applied across jurisdictions.

Onboarding is one integration, not three vendors. KYB and KYC run inside the Lumx API through Sumsub, Chainalysis monitors blockchain transactions, and Lumx is Travel Rule aligned. Every transaction, inbound and outbound, is screened before it runs. Lumx targets one business day for KYB. A KYB Standard customer can move up to $50,000 per transaction and $100,000 per day, in every country. Each payee is registered as a destination under the customer, with its relationship to the holder.

Step 2: dollars arrive in an account in the sender's name

The sender pays into a named virtual account (a local account number issued in the customer's own name), so the deposit is matched to the customer without a reference code. A USD account takes ACH, FEDWIRE and SWIFT on one account number.

This leg runs on bank hours, and a payment that misses the cut-off waits for the next business day. The rail table below has the times.

Funding needs no call per deposit. A standing autoconversion rule on a Lumx account turns every deposit into stablecoin, and the 50 USD minimum applies to every deposit, not only to autoconversion. A USD or EUR account with no active rule and no on-ramp keeps the deposit as fiat. The USD account activates within one business day of the customer's approval, and the BRL and MXN accounts activate right away. See the product page for named virtual accounts.

Step 3: the quote fixes the price

The quote prices the payout leg, stablecoin to reais. The first leg, dollars to stablecoin, runs at market. Before the stablecoin is sold for reais, the platform asks for a quote: the rate, the fees and the amount the recipient will get. A locked rate holds for a fixed window and is what a customer confirms against.

How stablecoin payout pricing works breaks down the cost, and the live rates are on the USD to USDC and USDC to BRL pages.

You can show the customer a price before anything is sent. Lumx gives a locked rate through the exchange-rates endpoint, with a lock of 30 seconds, one minute or five minutes. The 30-second lock carries no fee, and longer locks include a fee for the volatility risk. You pass the quote's id on the payout, and if the lock has expired the API returns EXCHANGE_RATE_EXPIRED and you ask for a new one. A locked quote belongs to a single off-ramp, because the standing autoconversion rule on the account always converts at market.

Step 4: the stablecoin lands in a custodial wallet

Once the dollars clear, they are converted to USDC or USDT and delivered to a wallet. The wallet holds the balance between legs, so a platform can fund once and pay out many times. The network decides which stablecoin the wallet holds, and Lumx lists these combinations:

Stellar is on-ramp only, so payouts and USD routes run on Ethereum, Polygon, Base or Tron. Nobody on your side signs a transaction, and Lumx subsidizes the network fee on its own legs, so the customer needs no ETH or TRX. Every Lumx customer gets a wallet on each supported blockchain at creation, usable once the customer is approved, and Lumx holds the keys, so a payment is an API call.

Step 5: the stablecoin moves, the bank leg follows, and webhooks report both

The payout debits the wallet, converts the stablecoin to reais and sends them over Pix (Brazil's instant payment system, run by the Central Bank). The recipient's bank credits the account and the payment is done. Lumx publishes no blockchain confirmation time, so plan around the bank legs, which have documented cut-offs.

The first payout to a new supplier is where this usually goes wrong. Check the CPF (the Brazilian individual taxpayer ID) or CNPJ (the Brazilian company taxpayer ID) against the account holder before the invoice is due, because a mismatch comes back as INVALID_TAX_ID.

The supplier sees your company's name as the payer on a Pix payout, and nothing is taken out of the amount that arrives. Lumx charges the fee in the conversion and shows it on the receipt, and only the recipient's own bank can charge the recipient. The payout starts with a destination registered for the recipient, then an off-ramp that names it. For the full sequence on this route, see USDC to a Brazilian bank.

A payment is asynchronous, so Lumx reports each status change instead of making the platform poll. Lumx sends each status as a webhook event, from onramp.transferring_fiat and offramp.transferring_fiat up to onramp.success and offramp.success, plus onramp.failed, offramp.failed and onramp.expired. Requests are signed with HMAC-SHA256, and the success event carries the receipt: amounts, rate, Lumx and partner fees, and the blockchain transaction hash.

When is the recipient actually paid, and what can stop it?

A confirmed transfer on the blockchain does not mean the supplier has been paid. Paid means reais in the supplier's account, and that depends on the rails at both ends.

Settlement time and cut-off by rail, from the Lumx coverage and cut-off pages and Lumx's current position on COP (as of November 2026).

Add the collection rail and the payout rail, and that is most of the wait. USD by FEDWIRE into BRL by Pix is same-day when funded before the cut-off, while SWIFT brings its own window. Lumx counts an off-ramp as complete when the funds leave its banking partner, and the recipient's own bank can still hold a credit for its own review.

I recommend that a platform shows its customers two states and never one: sent, when the stablecoin leg confirms, and paid, when the local payout completes. A single "paid" at the first confirmation will be wrong whenever the bank leg is held for review, and the customer then hears it from the supplier. I would rather the screen say "sent" for a few minutes than say "paid" and be corrected.

A confirmed blockchain transfer is final, which is why the destination is registered and checked before anything moves. The bank legs can still fail, as reversal of stablecoin payments explains. A deposit that lands after its Lumx transaction expired goes back to the sender.

Where a payment can stop, and what surfaces when it does, on the Lumx API (as of November 2026).

A failed payout reaches you as a webhook that carries the transaction id for support. Why stablecoin payouts get rejected covers the payout failures, and what to tell the customer, in more detail.

When a stablecoin payment is the wrong tool

When both sides are in one country and one currency, the domestic rail is faster and cheaper: Pix for a Brazilian company paying a Brazilian supplier, ACH for a US payroll. A stablecoin in the middle only earns its place when the money crosses a border or a currency.

It is also the wrong tool when the funds belong to someone Lumx has not onboarded, because passing money through for third parties needs written approval from compliance first, and for an amount above the $50,000 per-transaction limit of a KYB Standard customer, which needs a limit increase or Enhanced KYB first.

What a USD to BRL payment looks like 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.

For a US company paying a Brazilian supplier, the sequence is this. The company is verified once and gets a USD account in its own name. It pays in by ACH, FEDWIRE or SWIFT, and a standing rule converts the deposit to USDC in the company's wallet on a network that supports payouts. When an invoice is due, the platform registers the supplier as a destination with the SUPPLIER relationship, asks for a locked quote, and sends the off-ramp. The supplier receives reais by Pix, the receipt arrives by webhook, and the supplier sees the company's name as the payer.

For other currencies, a Mexican supplier is paid in MXN by SPEI (Mexico's interbank transfer system, run by Banxico) and a Colombian one is paid in COP by Bre-B (Colombia's instant payment system) or by ACH Colombia, chosen when the destination is registered. Bre-B carries a regulatory cap of 1,000 UVB per transaction, which is COP 12,110,000 for 2026, and a payout above it is refused rather than split, so larger invoices go to ACH Colombia. The coverage page lists the rails, the operator map shows how the legs connect, and supported countries lists jurisdictions.

On safety, see whether stablecoin payments are safe. On wallets, see the crypto wallet question.

Methodology and sources

Product behavior comes from the Lumx documentation pages read on November 1, 2026, including coverage, wallets, transactions, exchange rates and webhooks. The Pix sender of record, the KYB review target and the COP rails are stated as of November 2026. The Bre-B cap follows Banco de la República's Circular Reglamentaria Externa DSP-465, Asunto 18, section 3.2, in the sheet of March 31, 2026.

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

Cover photo: Mark McLaughlin on Unsplash.