How to pay an exact BRL, MXN, or EUR amount from USDC: receiver-side quotes explained

To pay an exact BRL, MXN, or EUR amount from USDC, request a receiver-side quote: set currency_type to receiver, put the local amount in request_amount, and set cover_fees to true. The quote returns the USDC sender_amount that delivers that exact amount, locked until expires_at. Execute before then and the number lands.

That is the whole trick. The rest of this guide is the detail that makes it work on Pix, SPEI, and SEPA without surprises.

Key takeaways

• Fix the side that matters to the business. A BRL invoice is a BRL number, so quote the BRL side and let the USDC float.
• currency_type: "receiver" plus cover_fees: true is the pairing for "recipient gets exactly X." With cover_fees: false, the fee comes out of the recipient's amount.
• Amounts are integers in minor units: R$27,000.00 is 2700000. No floats.
• On re-quote, the local amount stays fixed and only the USDC cost moves.
• SEPA has a receiver-side minimum of 40 EUR, and SEPA quotes can expire sooner than 5 minutes. Read expires_at.

When should you fix the receiver amount instead of the send amount?

Fix the receiver amount when the obligation is written in local currency. Fix the send amount when the budget is written in dollars. The quote can do either; your job is to pick the side that matches the contract.

The quotes explainer covers what currency_type and cover_fees mean. This is about which combination fits which job.

A rule of thumb: if someone will check the local number against a document, quote the local number.

How does a receiver-side quote work?

You tell BlindPay the fiat amount the bank account must receive. BlindPay prices the conversion at request time and returns how much stablecoin the funding wallet must send, plus every fee line, locked for the quote's window.

The request goes to POST /v1/instances/{instance_id}/quotes:

{
  "bank_account_id": "ba_000000000000",
  "currency_type": "receiver",
  "cover_fees": true,
  "request_amount": 2700000,
  "network": "polygon",
  "token": "USDC"
}

The response carries id, expires_at (epoch milliseconds), commercial_quotation (the market rate), blindpay_quotation (the rate net of BlindPay's fee), sender_amount, receiver_amount, and the fee fields. The payout quotes reference lists every field.

Two details catch teams the first time.

• Minor units. request_amount is an integer. R$27,000.00 is 2700000, and $35,000.00 MXN is 3500000. Convert once, at the edge of your system.
• The direction flips on payins. On a payout quote, receiver means the fiat side. On a payin quote, receiver means the stablecoin side. A shared helper that ignores this quotes the wrong side.

What does an exact-amount payout look like in each currency?

The same request shape works across rails. What changes is the bank account behind bank_account_id and a couple of rail rules.

Pix and SPEI both run around the clock. The Central Bank of Brazil operates Pix as an instant payment system, and Banco de México operates SPEI around the clock. SEPA is the euro area's common framework for euro transfers, described by the European Central Bank.

For which details each rail needs, see Pix keys, CPF, and CLABE explained and the SEPA off-ramp guide.

How much USDC does an exact amount cost?

The quote tells you. You never compute sender_amount yourself. But you should know how to read it, so you can check the cost against the market.

Illustrative example. These rates are made up for the arithmetic. They are not BlindPay pricing.

The math for Brazil: 27,000 ÷ 5,025.13 = 5.3730 BRL per USDC delivered. At the market rate, 27,000 ÷ 5.40 = 5,000.00 USDC. The difference, 25.13 USDC, is everything you paid: spread plus fees. As a share: (5.40 - 5.373) ÷ 5.40 = 0.50%, or 50 basis points.

That one number is the honest comparison between providers. Ask each for a receiver-side quote of the same amount at the same moment, then compare sender_amount. For the spread side of that math, see how to calculate FX spread.

What changes when the quote expires?

Only the USDC side. The local amount is what you asked for, so a new quote keeps it and reprices the stablecoin.

Payout quotes expire 5 minutes after creation by default, and SEPA quotes can be shorter because the rail's own deadline can be tighter. An expired quote is rejected. Nothing executes at a new rate behind your back.

So the re-quote loop for an exact amount is simple:

1. Request a new receiver-side quote with the same request_amount.
2. Compare the new sender_amount with the old one.
3. If your flow needs approval for changes, show the new USDC figure. If not, execute.

The local number never changes in that loop, which is why finance teams like receiver-side quotes for payables. The risk that moves is yours to see before you send. Who carries FX risk at each step walks through who holds the rate between quote, execution, and settlement.

What goes wrong with exact-amount payouts?

Most failures are setup mistakes, not rate problems.

• Wrong side. Quoting sender with a BRL number in request_amount sends 27,000 USDC. Test both sides in development before you ship.
• cover_fees: false on a fixed obligation. The fee comes out of the recipient's amount, and the invoice is short. Use true when the number must land in full.
• Floats. 27000.00 is rejected. Send 2700000.
• Hardcoded 5 minutes. SEPA quotes can be shorter. Count down from expires_at and divide by 1,000 if your library wants seconds.
• Reusing a quote. A quote_id backs one payout. The second payout against it fails.
• Under the minimum. A €30 SEPA payout quoted by EUR amount fails with sepa_minimum_is_40_eur.

The stablecoin payout mistakes guide covers the rest, from wrong networks to bad bank details.

How do you reconcile exact-amount payouts?

Store the quote with the payout. The quote's receiver_amount is the number your obligation should match, and the payout id is what your webhooks report on.

A minimal record per payment:

If receiver_amount doesn't equal the invoice amount, stop before executing. That check catches the wrong side, the wrong cover_fees, and a typo in minor units, all at once.

For contractor runs, the stablecoin payroll guide for Latin America shows where this fits in a monthly cycle, and the on/off-ramp liquidity glossary defines every term used here.

What to do next

Open a free development instance, add a test bank account, and request two quotes for the same local amount: one with cover_fees: true, one with false. Compare receiver_amount on both. Then follow the payout quotes guide to execute against the one that lands the exact number.

Aid programs run on this pattern, because each transfer is set in local currency. Stablecoin payouts for NGOs and aid programs shows it at program scale, with donor-ready records.

Insurance claims are another case where the local amount is fixed first; see cross-border insurance claim payouts with stablecoins.

Going the other way, billing clients in reais or pesos and receiving USDC, see how to invoice in BRL or MXN and settle in USDC, which covers who carries the FX between invoice and payment.