---
title: "Should you pass FX costs to your users or absorb them? Pricing cross-border payouts"
seoTitle: "Pass FX costs to users or absorb them?"
description: "Absorb, pass through, or mark up: who should pay the FX margin and fees on cross-border payouts, with cover_fees, a worked example, and disclosure rules."
date: "2026-10-12"
updated: "2026-10-12"
category: "payments"
author: "BlindPay Team"
faq:
  - q: "What does it mean to absorb FX costs on a payout?"
    a: "It means your company pays the exchange margin and fees so the recipient gets the full amount they expect. On a BlindPay payout quote you do this with cover_fees set to true, which adds the fees on top of the stablecoin you send. Pair it with a receiver-side quote when the recipient must get an exact local amount."
  - q: "What does passing FX costs through mean?"
    a: "The recipient or customer bears the cost. The fees come out of what they receive, so a 2,000 BRL payout lands as slightly less than 2,000 BRL. On BlindPay that is cover_fees set to false, which is the most common setting. If you pass costs through, show the rate, the fees, and the amount received before anyone confirms."
  - q: "Which is better for payroll, absorbing or passing through?"
    a: "Absorbing, in almost every case. A salary is a promise of an exact amount, and an employee or contractor who receives less than the agreed figure opens a support ticket every month. BlindPay's own docs note that sender-paid fees are typical for payroll. Budget the cost as part of the employment expense instead."
  - q: "Can I charge more than my cost and keep the difference?"
    a: "Yes, with a partner fee. You create a percentage or flat fee configuration and pass its id on each quote, and BlindPay collects it from your customer and releases the month's total to you on the first day of the next month. Show it as its own line on the quote screen so users see what they pay."
  - q: "Do I have to disclose FX costs to users?"
    a: "It depends on who the user is and where. Consumer remittances sent from the US fall under the CFPB Remittance Transfer Rule, which requires the rate, fees, and amount received before payment. In the EU, Regulation 2019/518 requires estimated conversion charges before an online credit transfer with currency conversion. Business payments are often outside these rules, but disclosure still builds trust."
---

Whether to pass FX costs to users or absorb them depends on what you promised the recipient. If they were promised an exact amount (a salary, an invoice), absorb the cost and fix the amount they receive. If they were promised a share of a balance (marketplace earnings), passing the cost through is normal, as long as the quote shows it clearly.

This is a pricing decision, not a technical one. The API supports both. What changes is your margin, your support load, and how the payout feels on the other end.

**Key takeaways**

- Three models: absorb (you pay), pass through (recipient pays), or mark up (recipient pays your cost plus a margin).
- On BlindPay, `cover_fees: true` puts the fees on the sender, `cover_fees: false` takes them from what the recipient gets.
- Absorb when the amount is a promise: payroll, supplier invoices, refunds.
- Pass through when the amount is a balance: marketplace earnings, wallet withdrawals.
- If you pass costs through to consumers, disclosure rules apply in the US and the EU.

## What does it mean to pass through or absorb FX costs?

Absorbing means your company pays the FX margin and fees, so the recipient's amount is untouched. Passing through means the cost comes out of the recipient's amount, or is charged to the customer on top. Marking up means passing through more than your cost and keeping the difference.

Every cross-border payout has a cost. The World Bank's Remittance Prices Worldwide puts the global average for sending $200 at 6.36% of the amount ([World Bank, Remittance Prices Worldwide](https://remittanceprices.worldbank.org/sites/default/files/2026-04/RPW_main_report_and_annex_Q325.pdf)). Business payouts on stablecoin rails usually cost far less, but someone still pays. The question is who.

## Which costs are you actually deciding about?

You are deciding about three lines, all visible in a quote before you execute it. A BlindPay payout quote returns them as fields ([payout quotes docs](/docs/payout-quotes)):

| Cost | Where it shows | What it is |
| --- | --- | --- |
| FX margin | `commercial_quotation` vs `blindpay_quotation` | The gap between the market rate and the rate after BlindPay's fee |
| Flat fee | `flat_fee` | A fixed amount per payout |
| Your markup | `partner_fee_amount` | Your own fee, if you pass a `partner_fee_id` |

BlindPay combines a monthly plan with per-transaction fees that vary by rail and network and are disclosed in the live quote before execute. There is no static rate card, so build your pricing on the quote fields, not on a fixed number of basis points. [How to read an FX quote](/resources/more/how-to-read-an-fx-quote) explains which way each rate points, and [how to calculate FX spread](/resources/more/how-to-calculate-fx-spread) turns the two rates into a percentage.

## How does cover_fees decide who pays?

`cover_fees` is the switch. On a payout quote:

| `cover_fees` | Who pays | Effect |
| --- | --- | --- |
| `false` | The recipient | Fees are deducted from the fiat amount the bank account receives |
| `true` | The sender | Fees are added on top of the stablecoin amount sent, so the recipient gets the full amount |

The docs call customer-paid fees the most common case and say sender-paid fees are typical for payroll. Combine `cover_fees: true` with `currency_type: "receiver"` and you fix the exact local amount that lands, with the quote telling you how much USDC that costs. [Paying an exact BRL, MXN, or EUR amount](/resources/more/pay-exact-local-amount-receiver-side-quote) walks through that pairing.

`cover_fees` moves the fee lines. The FX margin is built into `blindpay_quotation` either way. If you absorb, you pay it in extra USDC. If you pass through, the recipient sees it in a lower rate.

## Which model fits which business?

Match the model to the promise you made. A rough guide:

| Business | Promise to the recipient | Model | Quote settings |
| --- | --- | --- | --- |
| Payroll and contractor pay | "You get 8,000 BRL" | Absorb | `currency_type: receiver`, `cover_fees: true` |
| Supplier invoices (AP) | "The invoice is paid in full" | Absorb | Same as payroll |
| Marketplace seller earnings | "Your balance is $412.50" | Pass through or hybrid | `currency_type: sender`, `cover_fees: false` |
| Wallet or app withdrawals | "Cash out what you hold" | Pass through, maybe markup | `cover_fees: false`, plus `partner_fee_id` |
| Consumer remittance app | "Send money home" | Markup with disclosure | `partner_fee_id`, full fee breakdown on screen |

Hybrid is underrated. Absorb the cost on the first payout of the month, or on payouts above a threshold, and pass it through on the rest. Sellers feel looked after on the payout that matters, and your cost stays bounded.

## Illustrative example: what does absorbing cost a marketplace?

A marketplace processes 4,000,000 USD of gross sales a month, keeps a 10% take rate, and pays the other 90% to sellers in Brazil. Assume an all-in payout cost of 0.80% of the amount (illustrative, read your own from the quote).

| Line | Arithmetic | Result |
| --- | --- | --- |
| Platform revenue | 4,000,000 x 10% | 400,000 USD |
| Seller payouts | 4,000,000 x 90% | 3,600,000 USD |
| Payout cost at 0.80% | 3,600,000 x 0.008 | 28,800 USD |
| Cost as share of revenue | 28,800 / 400,000 | 7.2% |
| Cost per 400 USD seller payout | 400 x 0.008 | 3.20 USD |

Absorbing costs the platform 7.2% of its revenue. Passing it through costs each seller 3.20 USD on a 400 USD payout, which most sellers barely notice. That asymmetry is why marketplaces usually pass through and payroll platforms usually absorb: a salary of 8,000 BRL that lands as 7,936 BRL is a support ticket, while a seller payout that's 3.20 USD lighter is a line item.

Run the same table with your own numbers. [Cost per delivered dollar](/resources/more/cost-per-delivered-dollar) shows how to get the all-in percentage from real quotes.

## How do you add a markup on top of your cost?

Use a partner fee. You create a fee configuration with a percentage (in basis points) or a flat amount (in minor units), separately for payins and payouts, and pass its `partner_fee_id` on each quote. BlindPay collects it from your customer during the transaction and releases the month's total on the first day of the next month, net of your BlindPay invoice ([partner fees docs](/docs/learn/partner-fees)).

The amount on each transaction is `partner_fee_amount` on that quote. [How platforms add their own margin to a live quote](/resources/more/partner-fees-markup-on-live-quotes) covers whether the markup should sit in the rate or in a separate fee line.

## What do disclosure rules require if you pass costs through?

If your users are consumers, the law may decide part of this for you.

- **United States.** For consumer remittances, the CFPB Remittance Transfer Rule requires a pre-payment disclosure with the transfer amount, fees, exchange rate, total, and total to the recipient ([12 CFR 1005.31](https://www.law.cornell.edu/cfr/text/12/1005.31)).
- **European Union.** Regulation 2019/518 requires providers offering currency conversion on an online credit transfer to show the estimated conversion charges, the total in the payer's currency, and the estimated amount the payee receives before the transfer starts ([Regulation (EU) 2019/518](https://eur-lex.europa.eu/eli/reg/2019/518/oj)).

Business payouts often fall outside both, but the same screen is good practice for everyone. [How to show a cross-border quote to users](/resources/more/cross-border-quote-screen-fee-disclosure) lists the six things a quote screen should show.

## What to do next

Pick your three most common payout types, label each one "promise" or "balance", and request one quote per type with `cover_fees` on and off. The [payout quotes docs](/docs/payout-quotes) have the request body.
