What a cross-border quote screen must show: amount sent, rate, fees, amount received, expiry, and delivery date, plus the CFPB and EU disclosure rules.
A cross-border quote screen should show six things before the user confirms: amount sent, every fee, the exchange rate, the amount the recipient gets, when the quote expires, and when the money arrives. US consumer remittances must show most of these by law. BlindPay quotes return each figure as a field, with a 5-minute expiry, so the screen can render straight from the response.
Most quote screens fail in the same three places. They hide the margin in the rate, they let an expired rate through, and they promise "instant" for a rail that takes days.
Key takeaways
It should show every number the user needs to judge the payment, taken from one firm quote, so the user never has to calculate anything. Here is the full list and where each line comes from in a BlindPay payout quote (payout quotes).
| Line on screen | Why it matters | BlindPay quote field |
|---|---|---|
| You send | The amount debited or funded | sender_amount (minor units) |
| Fees, itemized | Separates your fees from provider fees | flat_fee, partner_fee_amount, billing_fee_amount |
| Total charged | What actually leaves the user's balance | Derived from the amounts above and cover_fees |
| Exchange rate, with direction | Shows the price of the currency | blindpay_quotation |
| Market rate (optional) | Makes the margin visible | commercial_quotation |
| Recipient gets | The number the recipient checks | receiver_amount (minor units) |
| Quote expires in | Tells the user the numbers are firm, but not forever | expires_at (epoch milliseconds) |
| Estimated arrival | Sets expectations per rail | From the rail; see cut-off times |
| Recipient | Name and masked account, so the user can spot a mistake | From the saved bank account |
Two formatting rules. Amounts come back as integers in minor units, so divide by 100 for USD, BRL, and MXN before display. And write the rate with its direction, such as "1 USD = 5.3730 BRL", because a bare "5.373" means nothing to someone comparing two apps.
Stablecoin API quotes explained covers the API side of these fields: what a quote locks, fee direction, and minor units. This page is about what the user sees.
For consumer remittances sent from the US, the CFPB's Remittance Transfer Rule (Regulation E, subpart B, 12 CFR 1005.30 to 1005.36) requires a disclosure before payment, a receipt after it, a 30-minute cancellation right, and an error resolution process.
Who it covers. A remittance transfer is an electronic transfer requested by a consumer to a recipient abroad, excluding transfers of $15 or less. The sender must be a consumer acting mainly for personal, family, or household purposes, so business-purpose payments generally fall outside it. A provider that made 500 or fewer remittance transfers in the previous calendar year and makes 500 or fewer in the current one is not treated as providing them in the normal course of business (12 CFR 1005.30).
Pre-payment disclosure. Before the sender pays, 12 CFR 1005.31 requires:
Receipt. Everything above, plus the date funds will be available, the recipient's name, a statement of error and cancellation rights, and contact details for the provider, the state regulator, and the CFPB.
Cancellation. The sender can cancel if the request arrives no later than 30 minutes after payment and the funds haven't been picked up or deposited. The provider refunds the full amount, fees included, within three business days (12 CFR 1005.34).
Errors. The sender has 180 days after the disclosed availability date to report an error, such as a wrong amount or funds that arrive late. The provider has 90 days to investigate (12 CFR 1005.33).
What this means for the screen: if you serve US consumers, the 30-minute window and the "date available" line belong in your product spec from day one. Adding them later means redesigning confirmation and receipt flows.
This is for information only and is not legal advice. Whether your product is a remittance transfer provider depends on your facts.
For online credit transfers that include a currency conversion, EU rules require the payer's provider to show the estimated conversion charges and the estimated total amount before the payment starts.
The requirement is Article 3b of Regulation (EC) No 924/2009, inserted by Regulation (EU) 2019/518 and applied from 19 April 2020. The information has to be "clear, neutral and comprehensible". For card-based payments, the same regulation goes further and expresses conversion charges as a percentage markup over the latest ECB euro reference rates.
Even outside the EU, that percentage-over-reference format is a good pattern. Users understand "0.5% above the market rate" faster than two rates with four decimals each. How to calculate FX spread shows how to compute that number from a quote.
Decide which side of the payment is fixed, then show fees in a way that matches it. Two choices drive this: which amount the user types, and who absorbs the fees.
Which amount is fixed. A business paying a supplier invoice usually knows the amount the supplier must receive. A user sending money home usually knows how much they want to spend. Offer both modes. In BlindPay quotes, currency_type: "sender" fixes the stablecoin amount sent, and currency_type: "receiver" fixes the fiat amount the bank account receives.
Who pays fees. With cover_fees: false, fees are deducted from the fiat the recipient receives. With cover_fees: true, they are added on top of the amount sent, so the recipient gets the full figure. On screen:
| Mode | User types | Fees appear as | Recipient sees |
|---|---|---|---|
| Fixed receive, sender covers fees | R$10,000 to receive | Added to the amount sent | Exactly R$10,000 |
| Fixed send, recipient absorbs fees | $2,000 to send | Deducted before conversion | Less than $2,000 x rate |
For invoices, fixed receive with the sender covering fees is almost always right. A supplier who gets R$9,940 against a R$10,000 invoice will chase the gap, and your user pays for the follow-up. Hidden fees in international wires explains why the same problem shows up with SWIFT SHA and BEN charges.
Run a visible countdown from the quote's expiry time, block confirmation when it reaches zero, and fetch a new quote that the user must confirm again. Never let an expired price through.
BlindPay payout and payin quotes expire after 5 minutes by default, and some rails can return less, such as SEPA payout quotes. expires_at is in epoch milliseconds, so compare it to Date.now() directly. Read it from every response instead of hardcoding 5 minutes.
A pattern that works:
expires_at, not from when the screen rendered. Network latency eats seconds.Short expiries are a feature. A provider that locks a rate for an hour has priced an hour of market risk into that rate. Stablecoin FX slippage explains the trade-off.
Show an estimate per rail, adjusted for cut-offs and weekends, and never "instant" for a rail that runs on business days. The rail is the biggest driver of arrival time.
| Rail | Typical BlindPay payout timing |
|---|---|
| Pix (Brazil), SPEI (Mexico), Transfers 3.0 (Argentina) | Minutes; Pix and SPEI run 24/7 |
| RTP (US) | Instant |
| ACH, wire (US) | ACH about 2 business days; wire about 1 business day |
| TED (Brazil), ACH Colombia, SEPA | About 1 business day |
| SWIFT (POBO/COBO) | About 5 business days, after compliance documents are approved |
Source: bank accounts, payment methods, and cut-off times. High volume can stretch any estimate, and payouts can be held for compliance review, so phrase it as "usually arrives by" rather than a promise. Do stablecoin payouts work on weekends? covers the calendar side.
The receipt should repeat the exact quote figures, add a payment reference and status, and tell the user how to get help. It is the screen users come back to when something looks wrong.
processing, on_hold, completed, failed, or refunded. Map each to a sentence. Stablecoin payout statuses explained has suggested wording.Every line on the screen maps to a field in one BlindPay quote, so the UI renders from a single response and executes against the same quote ID.
sender_amount, receiver_amount, commercial_quotation, blindpay_quotation, flat_fee, partner_fee_amount, and expires_at in one response.cover_fees and currency_type support fixed-send and fixed-receive screens without extra math on your side.The disclosure duties themselves sit with whoever is the provider to the end user. BlindPay gives you the numbers; your product decides how to present them and which rules apply.
Sketch your quote screen against the table at the top of this page and mark any line you can't fill from a single quote. Then create a test quote from the payout quickstart and render it: amount sent, fees, rate with direction, amount received, and a countdown from expires_at. For the bigger picture, read what real-time cross-border settlement is.
Seven places blockchain payments beat bank rails: contractor payroll, remittances, B2B suppliers, marketplaces, 24/7 treasury, bill pay, and PSP payouts.
AP2, ACP, and x402 each verify that an AI agent had permission to spend. Here is what every protocol covers, who backs it, and the reconciliation gap none of them close.
A 10-point checklist and a side-by-side of BlindPay, Wise Platform, Airwallex, Thunes, Bridge, and Circle for real-time, low-fee cross-border settlement.