Who pays the fees at a cross-border checkout: shopper or merchant?

At a cross-border checkout, the cleanest default is that the shopper pays fees and exchange inside one local total, and the merchant receives the exact list price. On BlindPay, that is a receiver-denominated payin quote with cover_fees: true. Flip it only when the shopper's local amount must stay fixed, and then the merchant absorbs the fees.

This guide belongs to the series on what a global payments checkout is. For the platform margin itself, read partner fees on live quotes.

Key takeaways

• Two BlindPay quote fields decide fee incidence: currency_type (sender or receiver) and cover_fees (true or false).
• currency_type: "receiver" plus cover_fees: true gives the merchant exactly request_amount, with fees and exchange inside the shopper's sender_amount.
• A platform fee rides on top through partner_fee_id, collected per transaction and paid out monthly.
• Baymard found 40% of US shoppers abandoned over extra costs and 12% because they could not see the total up front.
• BlindPay discloses its own fees in the live quote before execute, so the page always shows a real number, never an estimate.

Why does fee placement change conversion?

Shoppers punish late surprises more than high prices. Baymard's checkout research ranks "extra costs too high (shipping, tax, fees)" as the top reason for abandonment, at 40% of US shoppers, and 12% left because they could not see or calculate the total order cost up front.

Cross-border orders add two more costs a shopper worries about: the exchange rate and the bank's own charges. Stripe's localization guide gives the same advice from the merchant side: show prices in the buyer's currency throughout the flow, including the final charge, to avoid surprises.

So the real question is not only who pays. It is whether the shopper sees one final number before they commit.

Which two quote settings decide who pays?

currency_type decides which side of the payment is fixed. cover_fees decides which side the fee comes from. On a checkout, the BlindPay customer is the merchant and the sender is the shopper.

BlindPay's payin docs describe the two cover_fees values plainly: with false, the fee is deducted from the stablecoin amount the customer receives, the most common setup; with true, the sender pays and the fee is added on top of the fiat amount they send.

Three currencies add a rounding rule. MXN, COP, and ARS settle in whole units, so computed sender amounts round down to a whole peso. Your page should display the quote's sender_amount, never a number you computed yourself.

How does the default setup work, step by step?

Price in dollars, let the quote convert, and keep the merchant whole. Receiver-side quotes explain the same mechanism on the payout side.

1. The merchant sets a USD price, for example US$100.00, sent as request_amount: 10000.
2. The shopper picks a rail, such as Pix, SPEI, Transfers 3.0, PSE, ACH, wire, or RTP.
3. Your backend requests a payin quote with currency_type: "receiver", cover_fees: true, and the platform's partner_fee_id if there is one.
4. The quote returns sender_amount, the shopper's total in their currency with fees and exchange included, plus receiver_amount, which equals the price, and expires_at, 5 minutes out.
5. The page shows the total large, "Includes fees and exchange" under it, and a countdown.
6. The shopper pays. The merchant's wallet receives exactly the price in stablecoins.

If the countdown ends, quote again on the next click. Each new quote carries a fresh rate and the same guarantee for the merchant.

Illustrative example: one US$100 order, three fee choices

This example is illustrative. It uses letters for BlindPay's per-transaction fee, because the real number comes only from the live quote, and an example platform fee of 1% plus US$0.30 that a platform might choose for itself.

• Shopper pays (receiver + cover_fees: true). The merchant receives US$100.00. The shopper's local total equals US$100.00 plus the quote's fee F plus the platform's US$1.30, converted at the quoted rate. One number on the screen.
• Merchant pays (sender + cover_fees: false). The shopper pays exactly the local price, say a fixed BRL amount on an invoice. The merchant receives that amount converted, minus F and minus the platform fee.
• Split view (sender + cover_fees: true). The shopper sees a base amount and a fee line. Common on marketplaces, where buyers already expect a service fee.

The same decision shows up on card gateways. Stripe's Pix docs say Brazilian customers paying a business outside Brazil owe IOF of 3.5%, paid by the customer by default, or absorbed by the merchant if it chooses. Different tax, same question: inside the shopper's total, or out of the merchant's margin.

How should a platform fee fit in?

A platform fee is a markup on top of the provider's fee, and it should travel inside the same quote. That way the shopper still sees one total and your revenue is reported per transaction.

On BlindPay, create a partner fee once with payin_percentage_fee in basis points and payin_flat_fee in cents, save the pf_... id, and pass partner_fee_id on every payin quote. Each quote returns partner_fee_amount, the amount collected on that transaction. BlindPay collects the fee during each transaction, accumulates it over the calendar month, releases it on the first day of the following month, and nets your BlindPay invoice out first.

There is no update endpoint, so a pricing change means deleting the fee and creating a new one. Plan fee changes per merchant tier, not per order.

Who pays the platform fee follows the same cover_fees rule. With cover_fees: true on a receiver quote, the shopper's total includes it and the merchant still receives the full price. Showing a quote with fee disclosure covers how to label it.

How does BlindPay handle fees at checkout?

BlindPay puts every fee in the quote, before the shopper commits. Its pricing combines a monthly plan (platform access) with per-transaction fees that vary by rail and network and are disclosed only in the live quote before execute. There is no static rate card to copy onto your page, which is the point: the page shows the real total for that rail, that amount, and that minute.

The quote locks the rate and fees for 5 minutes, so the number the shopper sees is the number they pay. With currency_type: "receiver" and cover_fees: true, the merchant receives exactly the price on every rail, whether the shopper pays by Pix, SPEI, Transfers 3.0, PSE, ACH, wire, or RTP.

For platforms, the partner fee turns each payment into revenue without a second charge. For merchants, withdrawals have their own payout quote with its own fee disclosure, over ACH, wire, RTP, or SWIFT (POBO/COBO). Recipient fees on local payouts covers what the receiving bank may charge on that leg.

Who this is for: checkout platforms setting their take rate, and merchants deciding whether to price in USD or in local currency.

Methodology and sources

Abandonment figures come from Baymard (updated September 22, 2025). Localization advice comes from Stripe's guide. The IOF example comes from Stripe's Pix docs. BlindPay behavior comes from the payins, payin quotes, and partner fees docs, as of October 2026. For the currency decision behind the fee decision, read local currency pricing at checkout.

What to do next

Pick one default for your whole catalog: shopper pays, merchant receives the list price. Then create a test partner fee on a BlindPay development instance, request a receiver quote with cover_fees: true, and check that receiver_amount equals your price.