Cross-border payment quote screen: rate, fees and expiry

A cross-border payment quote screen is the page where a payer sees what a transfer will cost and deliver before confirming. It shows the amount sent, the exchange rate, the fees, the amount received, a countdown to expiry and the arrival time. Every number but the arrival time is read from one firm quote.

The two lines that go wrong most easily are the last two: the countdown runs from the wrong clock, or the arrival line promises a speed the rail cannot give. This guide covers the screen for a payer on a stablecoin corridor, such as a US app paying a recipient in Brazil or a Brazilian app paying a US supplier. How stablecoin payout pricing works covers how the numbers are built; this post is about what the payer sees.

What must a cross-border payment quote screen show?

Eight lines on screen and one the app holds. Six come straight from the quote; the arrival time comes from the rail and the recipient from your own records.

The lines of a quote screen, why each is there, and where it comes from in a Lumx locked quote

On Lumx, a locked quote returns every number above except the arrival time and the recipient's details, in one response, and the quote's ID goes on the payout request so the payment settles at what the screen showed.

Which way should the rate run, and how many decimals?

Pick one direction per corridor, write it out in full, and never flip it between quote, confirm and receipt. "1 USDC = R$ 5.1636" is a rate; a bare "5.1636" is a number two payers read in opposite ways.

For Brazil, write the dollar in reais: a Brazilian payer reads an illustrative "US$ 1 = R$ 5.16" the way the market quotes it.

The rate needs a check before it goes on the screen. In both example responses in Lumx's docs, BRL to USDC and USDC to BRL, the rate is expressed as reais per USDC, not source per target. A screen that assumes source per target would print the inverse on one of the two. Run one sandbox quote per direction and compare the rate to the amounts before writing the label.

Show both rates. The rate before fees is the market price and the rate after fees is what the payer gets, so the gap is the payment's cost in a unit the payer reads. A percentage over the reference reads faster, and how to calculate FX spread shows the arithmetic. The public USDC to BRL rate and USDC to USD page give context, not the quote.

On Lumx, the pre-fee rate is the raw mid and the post-fee rate is that rate after fees, with no FX margin built in, so the gap is fees only and both lines render without a second data feed.

Fees: itemise them, and decide which amount is fixed

A payer settling a supplier invoice knows what the supplier must receive. A payer sending money home knows what they can spend. Offer both modes: fixed receive adds the fees to the amount sent, and fixed send takes them out of the conversion. On Lumx, a locked quote accepts the source amount or the target amount, so a fixed-receive screen asks with the target amount and shows the source amount the payer must send. The partner fee comes on top of what the payer funds, so the source amount grows for the same amount received, and finalTargetAmount is all-in, with the Lumx fee and the partner fee inside it. A floating rate takes the source amount only, so it suits a preview, not a promise.

For an invoice, fixed receive is the safer default: a supplier who gets, say, R$ 9,940 against a R$ 10,000 invoice (illustrative figures) will chase the difference. Who carries the cost is a pricing decision, covered in passing FX costs to users.

Keep two fee lines apart: the provider's fee and the platform's own, which is the app's margin. Show the total, with the split one tap away. On a SWIFT payment, add a line that fees charged by intermediary banks may reduce what arrives, because those never appear in the quote.

On Lumx, the quote splits fees into a Lumx part, a partner part and a total. The platform's fee is a partner fee: it is passed by ID when the quote is requested and becomes part of the locked quote. The quote shows the Lumx and partner fees; on a SWIFT payout, the docs warn that intermediary banks may deduct their own, outside what Lumx controls.

A worked screen: 500 USDC to a Pix recipient

This is the layout for a US payer sending 500 USDC to a recipient in Brazil over Pix (Brazil's instant payment system). The figures are the example response in Lumx's remittances guide, read on November 1, 2026.

A quote screen for a 500 USDC payout to Brazil, built from the docs' example response

The fee line is derived: R$ 2,587.50 before fees minus R$ 2,581.81 after. Fee amounts carry their own currency, so convert them for display.

The mirror case is a Brazilian app whose user pays a US supplier in dollars over SWIFT: the dollars the supplier receives, the same two rates in the same direction, an arrival window of one to five business days and the intermediary-bank line. On Lumx, the USD SWIFT quote uses the same fields.

How should the expiry countdown work?

The quote's clock starts when it is created, and the response gives the expiry in UTC. Start the countdown from that time, disable confirm at zero, and fetch a new quote the payer sees before confirming again. An expired rate must never go through, and a changed rate must never be swapped in silently. The screen needs six states.

The states of a quote screen and what each one shows

Count from the quote's expiry time, not from when the screen rendered. Work out the remaining time once, when the quote arrives, by comparing expiresAt with the response's own HTTP Date header, and run it on a local monotonic timer rather than the device clock: a phone with the wrong time shows a countdown that is too long.

Lock length is a product choice with a price. A Lumx locked quote lasts 30 seconds, one minute or five minutes. The 30-second lock has no fee, and the longer ones add a fee for the volatility the provider carries. A person reading needs more than 30 seconds; an automated flow does not. What the window means for the payer is in how long a payment quote lasts.

I would request the one-minute lock for any screen a person reads and pay its fee, because a countdown that forces a decision in 30 seconds teaches payers to distrust the number. I would keep the 30-second lock for the automatic requote behind the scenes. And I would put the recipient amount, not the rate, in the largest type, because the supplier checks the amount.

On Lumx, a payout sent with an expired quote ID is refused with the error code EXCHANGE_RATE_EXPIRED, so the app never settles at a stale rate by accident, and the screen answers with the Expired state.

Arrival time and the receipt: what to promise, what to repeat

The arrival line follows the rail, the cut-off and the calendar of the country where the money lands, not the speed of the stablecoin leg. The Lumx docs call these processing targets, so the screen says "usually arrives by". SPEI (Mexico's interbank transfer system) and Faster Payments (the UK's real-time bank transfer network) sit in the table beside Pix.

Cut-off and settlement by rail, from the Lumx rail cut-off page

Convert the cut-off to the payer's time zone, because it is in the rail's local time. Move the date forward after the cut-off, on weekends and on bank holidays. And write "instant" only for rails and schemes that are: Pix, SPEI, Faster Payments and SEPA Instant in this table, never SEPA Credit Transfer, ACH, FEDWIRE or SWIFT. A compliance review or a bank holiday can push any of them later.

The receipt repeats the quote's numbers exactly. It adds a plain-sentence status per stage and a reference the recipient's bank understands (for SWIFT, the UETR).

On Lumx, the stages arrive as webhooks, from the stablecoin transfer through the trade and the fiat transfer to success or failure, and every SWIFT payout carries UETR and MT103 confirmations. The stablecoin API exposes both.

Disclosure rules decide more than the layout does

No quote screen is a legal safe harbour. What a payer must be shown, and when, depends on who the payer is, where the money starts and who counts as the provider.

For a US app serving consumers, start with the Remittance Transfer Rule. For a Brazilian app, international transfers are their own rule set, covered in Brazilian app transfers under BCB rules.

On Lumx, the quote supplies the numbers a disclosure is built from. Which disclosures apply stays with the app that serves the end user.

When a quote screen is the wrong tool

When no one is there to read it, a recurring supplier run needs a quote per payment at execution and no countdown. A rule that converts every incoming deposit converts at market and accepts no locked quote, so a screen cannot promise a rate on that deposit.

It is also the wrong tool when the payer needs a rate days ahead: a forward bought from a bank or an FX broker does that job. The wire-side comparison is in stablecoins vs SWIFT.

What this looks like on a Lumx payout

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 is an API and the screen is the customer's to build. The app requests a locked quote with the customer's ID, the rail, the currencies, an amount and a lock length, adds the partner fee ID if the platform charges its own fee, draws the lines from the response and keeps the quote ID.

On confirm, the app sends the payout with the destination, the quote ID and the payment purpose. A wallet balance below the amount fails with an insufficient-balance error, so the Balance too low state checks first. The pricing model behind the quote is a monthly platform fee plus usage-based per-transaction fees, transparent FX on locked quotes, no pre-funding. No pre-funding means no capital parked in settlement accounts before a payment, because conversion and settlement happen when the transaction starts.

Rails and currencies are on the coverage page, and the quote sits behind the global payments product. A Brazil flow starts with USDC to a Brazilian bank account.

Methodology and sources

Product facts come from the Lumx docs, read on November 1, 2026: Exchange rates, the Get an exchange rate reference, Partner fees, Payment rail cut-off times, the Remittances guide and Integrate off-ramps to local bank rails. The worked figures are the remittances guide's example response, and a live quote differs.

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

Cover photo: Josh Redd on Unsplash.