How PSP Foreign-Exchange Fees Work
V2 - did not use v1 as a reference or to build upon A customer pays: €100. The merchant ultimately receives: $106.82. How much did foreign exchange cost? The first question should not be: “What percentage did the PSP charge?” It should be: Where, exactly, did €100 become dollars?
V2 - did not use v1 as a reference or to build upon
How PSP Foreign-Exchange Fees Work: Spreads, Markups, Conversion Points, and Merchant Cost
A customer pays:
€100.
The merchant ultimately receives:
$106.82.
How much did foreign exchange cost?
The first question should not be:
“What percentage did the PSP charge?”
It should be:
Where, exactly, did €100 become dollars?
That conversion could have occurred when the payment was processed.
Or at settlement.
Or when funds moved from a merchant balance to a bank account.
There could even have been more than one conversion.
And the cost does not necessarily appear as a line item called FX fee.
A payment service provider can price foreign exchange through an explicit conversion charge, the exchange rate itself, settlement or payout pricing, or a combination depending on the merchant agreement and payment flow.
So understanding PSP foreign-exchange fees starts with the currency path, not the fee label.
What are PSP foreign-exchange fees?
A PSP foreign-exchange cost is the economic cost a merchant incurs when value changes from one currency into another within its payment, settlement or payout flow.
The cost can appear in several ways.
Explicit percentage fee
For example, the provider agreement could specify an additional percentage when conversion occurs.
Explicit fixed conversion fee
Less common in some merchant models, but conceptually separate from the rate.
Exchange-rate spread or markup
The conversion rate produces less destination currency than the selected reference-rate comparison would imply.
Settlement conversion pricing
The customer pays in one currency, but proceeds are converted before being credited to the merchant's settlement balance.
Payout conversion pricing
The merchant holds a balance in one currency but receives a bank payout in another.
Combined pricing
A commercial model can contain both an exchange-rate difference and an explicit charge.
That is why:
FX fee ≠ total FX cost.
And:
no separately listed FX fee ≠ free currency conversion.
Start by mapping the currencies
International payment flows can involve more currencies than merchants initially realize.
Potential layers include:
catalog currency;
display currency;
presentment/transaction currency;
processing currency;
settlement currency;
merchant balance currency;
payout currency;
merchant reporting or economic base currency.
The brief's central discipline is simple:
every arrow that changes currency is a potential FX event.
For example:
Customer sees EUR
↓
Customer pays EUR
↓
Payment processed in EUR
↓
PSP settles USD
↓
Merchant holds USD
↓
Merchant bank receives GBP
There are potentially two conversions:
EUR → USD
and:
USD → GBP
Knowing that the checkout displayed euros tells you almost nothing about the total merchant FX cost by itself.
Presentment currency is not settlement currency
These concepts are frequently conflated.
Presentment or transaction currency
The currency in which the customer's payment is submitted in the relevant transaction flow.
Settlement currency
The currency in which proceeds are credited or settled to the merchant/provider balance.
They can be identical.
They can also differ.
For example:
Customer pays EUR
but:
merchant settlement balance is USD.
That creates a potential EUR→USD conversion somewhere between transaction and settlement.
The key diagnostic questions are:
Was conversion mandatory?
Who performed it?
When?
Which rate was used?
Was there another fee?
Processing currency can be another layer
Payment-method infrastructure does not necessarily process every currency a merchant can display or accept in exactly the same way.
That does not imply automatic merchant FX in every such case.
It demonstrates why merchants should separately record:
supported/presented currency;
processing currency;
settlement currency.
Explicit FX fee vs embedded exchange-rate cost
This distinction is mandatory.
Explicit FX fee
A separately identifiable amount.
For example, the agreement might describe:
conversion amount × explicit FX fee percentage
The merchant can usually see this component directly if reporting exposes it.
Embedded spread or markup
The cost is reflected in the conversion rate.
Suppose a merchant converts:
€100
At the aligned reference rate used for analysis, assume hypothetically:
1 EUR = 1.0800 USD
Benchmark converted amount:
€100 × 1.0800 = $108.00
But the merchant actually receives:
$106.82
Difference:
$1.18
Effective difference relative to the benchmark result:
$1.18 ÷ $108.00 ≈ 1.09%
That 1.09% is a useful effective conversion-cost measurement under the stated assumptions.
It is not automatically proof that the PSP earned a 1.09% margin.
Other factors could exist, including:
the provider's actual base rate;
timing;
execution conditions;
contractual fees;
intermediary costs.
The correct conclusion is:
Under the selected benchmark methodology, the merchant received approximately 1.09% less destination currency than the benchmark conversion would have produced.
That is precise without pretending to know the provider's economics.
What is an FX spread?
For this pillar, the concept only needs a high-level definition.
An FX spread can refer to the difference between:
buy and sell rates; or
a provider's conversion rate and a defined reference rate;
depending on context.
The important editorial rule is:
define what two rates are being compared.
Do not write:
“The PSP spread is 80 bps.”
until you can answer:
80 bps relative to what benchmark, at what timestamp, for which pair and in which direction?
The dedicated What Is an FX Spread? article should own the detailed mechanics.
There is no universal “true exchange rate”
Merchants often compare their PSP with “the real rate” or “the mid-market rate.”
That language is too loose.
Potential comparison points include:
a central-bank reference rate;
market-data midpoint;
bank reference;
provider base rate;
network rate;
another defined benchmark.
Each answers a different question.
The ECB's own framework is instructive. It says its euro foreign-exchange reference rates are intended for information purposes and are not intended for use in market transactions.
So an ECB reference rate can be useful for:
consistent analytical comparison
but should not automatically be presented as:
the rate the PSP should have executed.
Benchmark discipline
For every merchant FX analysis, record:
Field
Example
Source currency
EUR
Source amount
€100,000
Destination currency
USD
Quote direction
USD per EUR
Provider conversion time
14:03 UTC
Benchmark source
Defined reference
Benchmark time
Closely aligned
Provider destination amount
$X
Explicit fee
$Y
Other known charge
$Z
Without this information, apparently precise spread calculations can be misleading.
Why timestamp matters
FX markets move.
If a provider converted the transaction at:
3:00 p.m.
and the merchant compares it with a public rate from:
9:00 a.m.
the difference contains both:
possible provider pricing;
market movement during the six-hour interval.
Those cannot be separated without better data.
For a defensible comparison, align:
pair;
direction;
amount;
timestamp;
conversion stage.
If an exact provider timestamp is unavailable, state the limitation rather than manufacture precision.
Rate direction can create surprisingly large analytical mistakes
Suppose a report gives:
EUR/USD
while another provider quotes:
USD/EUR.
Those are inverse rates.
Do not compare them as if they were directly equivalent.
Where possible, reconstruct the analysis from:
source amount → destination amount
because actual amounts make quote-direction mistakes easier to detect.
All-in effective conversion rate
A useful merchant metric is:
final destination amount after explicit FX charges
÷ source amount
This produces the conversion result the merchant actually experienced.
It can then be compared with the properly normalized benchmark.
Settlement conversion can be the main FX event
The customer might never experience currency conversion at checkout.
Example:
Customer pays €100.
The payment is processed in euros.
The PSP then credits the merchant's balance in USD.
The merchant FX event occurs at settlement.
That matters because the merchant needs to know:
when settlement conversion occurs;
whether the rate is locked earlier;
whether the PSP chooses the rate at settlement;
whether settlement currency can be changed;
whether EUR could instead be retained.
Settlement conversion and payout conversion are different
Consider:
Customer pays EUR
→ merchant balance becomes USD
→ merchant bank receives GBP
Two distinct conversion events may exist.
Settlement conversion
EUR → USD
Occurs before or as proceeds are credited to the merchant's settlement/balance layer.
Payout conversion
USD → GBP
Occurs when funds move into a differently denominated bank account or payout path.
The merchant needs to calculate them separately.
Otherwise, a PSP may appear to have one “FX cost” when the merchant is actually paying for two currency changes.
Double conversion: when one payment crosses two exchange rates
A classic double-conversion path is:
Customer pays EUR
↓
PSP converts EUR → USD
↓
Merchant receives/holds USD
↓
Bank or provider converts USD → GBP
↓
Merchant ultimately needs GBP
There can be:
Spread/fee 1
plus:
Spread/fee 2
The economically relevant question is:
Why was USD necessary as the intermediate currency?
Sometimes there is a legitimate answer:
provider capability;
settlement limitation;
banking structure;
entity requirement;
regulatory constraint;
treasury policy.
Sometimes there may be a more direct path.
Do not call a conversion “unnecessary” until the technical, contractual and operational alternatives have been verified.
How to audit suspected double conversion
Record:
Conversion 1
EUR source amount;
USD destination;
converting party;
rate;
timestamp;
benchmark;
explicit fee;
effective difference.
Conversion 2
USD source amount;
GBP destination;
converting party;
rate;
timestamp;
benchmark;
explicit fee;
effective difference.
Then test an alternative:
EUR → GBP directly
The savings case is valid only if the direct path is commercially and operationally possible.
Holding multiple currencies can prevent conversion—but it is not free
A merchant receiving EUR revenue may also have:
EUR suppliers;
EUR salaries;
EUR tax obligations;
EUR marketing spend.
If the merchant converts all EUR revenue to USD and later purchases EUR again to pay expenses, it may incur additional currency conversion.
Holding a EUR balance could potentially reduce that cycling.
But multi-currency settlement can also introduce:
more bank/provider balances;
more reconciliation;
treasury administration;
account costs;
liquidity fragmentation.
So the decision is not:
“Always hold local currency.”
It is:
“Is the avoided conversion cost worth the additional operational structure?”
The brief deliberately positions operational simplicity as a legitimate merchant benefit, especially for smaller merchants.
Customer FX and merchant FX are different
Suppose a merchant charges a customer in USD.
The customer's card/account is denominated in EUR.
The customer's issuer might perform its own conversion or charge a foreign-transaction fee.
That is primarily a customer-side currency cost.
It should not automatically be counted as merchant PSP FX expense.
Merchant-side FX might instead occur when:
USD transaction proceeds → merchant's GBP settlement account
The two can coexist.
Keeping them separate prevents merchants from blaming one participant for another participant's conversion.
Cross-border fees and FX fees are also different
Cross-border processing economics depend on transaction geography and network/provider classification.
FX economics depend on currency conversion.
A transaction can therefore be:
Cross-border without merchant FX
A foreign-issued card is processed under an international classification, but the merchant receives the same transaction currency without merchant-side conversion.
FX-converted without the same cross-border card structure
Currency is converted within another payment or settlement arrangement.
Both
International card cost and currency conversion occur.
This Foreign Exchange cluster owns the currency-conversion economics; the Cross-Border Costs cluster owns geography-driven processing premiums.
How to calculate merchant FX cost
The cleanest model starts with actual converted amounts.
Step 1: Benchmark converted amount
source amount × selected benchmark rate
Assume:
Source amount:
€100,000
Illustrative aligned benchmark:
1 EUR = 1.0800 USD
Benchmark destination amount:
$108,000
Step 2: Actual merchant amount
Assume hypothetical PSP result after the relevant conversion charges:
$106,920
Step 3: Absolute conversion cost relative to benchmark
$108,000 − $106,920 = $1,080
Step 4: Effective FX cost
$1,080 ÷ $108,000 = 1.00%
This does not need to be described as “1% PSP profit.”
It is:
1% less destination currency than the selected benchmark conversion under this analytical methodology.
The brief specifically defines effective FX cost in terms of benchmark converted value versus the merchant's actual converted result.
Add explicit fees correctly
Suppose instead the PSP delivers:
$107,460
and separately deducts:
$540
Final merchant economic amount:
$106,920
Do not compare the benchmark with $107,460 and stop.
The all-in merchant result remains:
$106,920
This illustrates why provider rate comparison should use the final destination amount after explicit charges, not just the quoted exchange rate.
FX cost per successful payment
For payments teams, another useful metric is:
total attributable merchant FX cost
÷ successful payments involving merchant-side conversion
This helps compare:
currencies;
providers;
markets;
payment methods.
But do not allocate merchant-wide treasury conversions to individual payments unless the methodology supports it.
Measure by currency pair
A global blended FX percentage can hide expensive routes.
Break out:
EUR→USD;
GBP→USD;
CAD→USD;
AUD→USD;
USD→GBP;
and other economically significant pairs.
For each pair track:
converted volume;
benchmark value;
actual value;
explicit fees;
all-in effective cost;
settlement stage;
payout stage.
Then weight results by economic volume.
Weighted effective FX cost
total modeled FX cost across all pairs
÷ total benchmark-converted value
Do not average unweighted percentage spreads across currency pairs.
A merchant can pay FX cost without converting at checkout
This deserves an explicit answer because it matches common search intent.
Consider:
Customer:
pays EUR
Checkout:
shows EUR
Authorization:
EUR
Yet merchant payout:
USD
The customer's experience is fully euro-denominated.
The merchant still incurs EUR→USD conversion somewhere before payout.
So:
localized checkout does not prove there is no merchant FX.
A merchant can also have FX exposure without paying a conversion fee yet
Suppose a merchant has:
€2 million receivable/balance
but reports economically in USD.
Until conversion occurs, the dollar value of that euro balance can change.
That is FX exposure.
It is different from:
transaction FX cost
which occurs when currency is actually converted.
Do not call every adverse currency movement an FX “fee” or “loss.”
Currency-value changes can move in either direction, and accounting treatment involves additional considerations outside this article.
Rate timing can shift exposure
A provider might determine its conversion rate at:
authorization;
capture;
clearing;
settlement;
periodic balance conversion;
payout.
Those moments can be hours or days apart.
Therefore merchants should ask:
When is the rate fixed?
not merely:
What rate do you use?
Different rate timing shifts who carries currency exposure during the payment lifecycle.
Do not assume a checkout exchange indication fixes the merchant's settlement rate unless the provider documentation or contract establishes that.
Refunds create a second FX question
Refund FX deserves its own article, but merchants need the high-level risk here.
Suppose:
Customer paid:
€100
Merchant originally converted proceeds:
EUR → USD
Two weeks later the customer receives a full €100 refund.
The merchant may now need to fund that refund from USD or another balance.
Potential questions include:
Is the refund denominated in EUR?
Does the PSP reverse the original conversion?
Is the original rate reused?
Is a new rate applied?
Is another conversion charge incurred?
Who bears exchange-rate movement?
A full refund of the transaction currency does not guarantee an identical home-currency result for every party.
The dedicated Currency Conversion for Refunds article should own the detailed mechanics.
FX charges can exist
That means the article can accurately say:
It should not invent:
one percentage FX fee;
a universal markup.
Multiple payout currencies are supported under conditions
That is useful because it demonstrates a potential merchant lever:
matching payout currency with processed currency may sometimes avoid an additional conversion.
Whether that is possible and economically optimal for an individual merchant must be verified.
Its current documentation lists a broad range of supported transaction currencies.
Again, supported currency does not automatically mean identical processing, settlement or payout capability.
The Merchant FX Cost Stack
The article's core framework is a path, not a price table.
1. TRANSACTION / PRESENTMENT CURRENCY
↓
PROCESSING CURRENCY, IF DIFFERENT
↓
SETTLEMENT CURRENCY
↓
MERCHANT BALANCE CURRENCY
↓
PAYOUT CURRENCY
↓
MERCHANT ECONOMIC / BASE CURRENCY
Every time currency changes, record:
Field
Question
Source currency
What currency exists before conversion?
Source amount
How much?
Destination currency
What does it become?
Destination amount
How much does merchant receive?
Converting party
PSP, acquirer, method, bank?
Conversion stage
Processing, settlement, payout?
Applied rate
What rate?
Timestamp
When was it determined?
Benchmark
What comparison rate is appropriate?
Explicit fee
Is there a separately stated charge?
Effective spread/cost
How far does final result differ from benchmark?
If any field is unavailable, mark it:
requires provider verification.
Do not silently fill it in.
Currency Conversion Path Audit
A useful merchant worksheet looks like this:
Stage
Source
Destination
Converter
Rate
Fee
Benchmark
Effective cost
Payment
EUR
EUR
None
—
—
—
—
Settlement
EUR
USD
PSP/acquirer
—
—
—
—
Balance
USD
USD
None
—
—
—
—
Payout
USD
GBP
PSP/bank
—
—
—
—
This immediately exposes questions hidden by a single line called:
“FX fees.”
How to compare two PSP exchange-rate propositions
A fair comparison must hold the commercial scenario constant.
Use the same:
currency pair;
quote direction;
amount;
timestamp;
transaction type;
settlement currency;
payout currency;
contract tier.
Then collect:
Measure
Provider A
Provider B
Source amount
Provider rate
Explicit FX fee
Settlement currency
Payout currency
Final destination amount
Benchmark amount
Effective all-in FX cost
The provider with the better-looking quoted rate does not necessarily produce the highest final merchant amount after fees and additional conversion conditions.
This is why the brief calls for all-in effective conversion rate rather than headline-rate comparison.
What merchants should ask a PSP
Conversion trigger
Which events trigger currency conversion?
Is conversion transaction-level or settlement-level?
Which currencies can remain unconverted?
Rate
Which rate methodology is used?
At what stage is the rate determined?
Is the rate locked?
What timestamp can be reported?
Is pricing different by currency pair?
Fees
Is there a separate FX fee?
Is there also a rate spread?
Are there settlement or payout conversion charges?
Settlement
Which currencies can we settle?
Can we maintain multiple balances?
Which currencies are automatically converted?
Payout
Which currencies can be paid to our bank account?
Must the receiving account match the payout currency?
Does payout trigger another conversion?
Reporting
Can we see source amount?
destination amount?
rate?
timestamp?
explicit fee?
conversion stage?
Refunds
Which rate is used for refunds?
Is the original conversion reversed?
Is current-rate conversion used?
Are refund FX costs separately reported?
A PSP that quotes an FX percentage without explaining the conversion path has not provided enough information for a merchant cost model.
How merchants should reduce unnecessary FX cost
Do this in order.
Map every conversion
Do not begin by renegotiating the spread.
First identify where currency changes.
Rank currency pairs by volume
Focus on economically meaningful pairs.
Measure the actual conversion result
Use:
destination amount;
explicit fees;
appropriate benchmark;
aligned time.
Find repeated conversions
Look for:
A → B → C
where a feasible:
A → C
path might exist.
Review settlement currencies
Could the merchant retain a currency it already needs?
Review payout currencies
Is another conversion occurring simply because the receiving bank account is denominated differently?
Compare PSP economics fairly
Normalize pair, amount, time and settlement/payout conditions.
Negotiate pricing
Once the merchant knows its:
converted volume;
pairs;
existing effective cost;
it is in a better position to negotiate.
Match revenue and expense currencies where operationally sensible
A natural currency offset may reduce unnecessary back-and-forth conversion.
But entity, regulatory, cash-timing and accounting constraints must be respected.
Review refunds
A good sale-side FX setup can still create expensive reversal economics.
Measure again
Do not claim savings from a smaller headline spread.
Measure:
total merchant FX cost before
versus:
total merchant FX cost after.
Do not optimize FX in isolation from payment operations
Suppose:
Provider A
FX cost:
lower
but:
limited settlement currencies;
inflexible payout structure;
fragmented reporting.
Provider B
FX cost:
slightly higher
but:
merchant can hold the currencies it actually uses;
settlement is easier;
reporting is clearer;
additional conversion is avoided.
Provider B may produce the better total merchant economic outcome.
The cheapest spot conversion is not necessarily the cheapest payment architecture.
That is why the cluster's objective is to minimize unnecessary FX while preserving payment acceptance, settlement, liquidity, reporting and operational simplicity.
When automatic conversion can be rational
A small merchant might prefer:
one USD balance;
one bank account;
one reconciliation currency;
automatic conversion.
That can be perfectly rational even if the provider's conversion spread is not the theoretical minimum.
The alternative could require:
more accounts;
more reconciliation;
additional treasury work;
more cash balances.
The correct comparison is:
FX cost saved
minus:
incremental operating cost and complexity.
When multi-currency capability becomes more valuable
The case strengthens when:
converted volume is large;
the same currencies recur;
the merchant has expenses in those currencies;
the merchant can maintain suitable accounts;
avoidable conversion is material;
treasury/finance can manage additional balances efficiently.
Do not recommend enterprise treasury architecture merely to save a small amount of FX cost.
Foundational FX questions
How do PSP foreign-exchange fees work?
They can be charged as explicit conversion fees, embedded in the exchange rate, or arise during settlement or payout conversion. The merchant should measure the final converted amount at every conversion stage.
Is an FX fee the same as an FX spread?
No. An explicit fee is a separately stated charge. A spread or markup is reflected in the conversion rate relative to a defined comparison benchmark.
Can a PSP have no listed FX fee but still generate FX cost?
What exchange rate should merchants compare against?
Use a clearly identified reference source for the same currency pair, direction and closely aligned timestamp. A reference rate is an analytical comparator, not necessarily an executable merchant rate. The ECB explicitly describes its reference rates as informational rather than transaction rates.
Can a payment be converted more than once?
Yes. For example, transaction proceeds could be converted into one settlement currency and later converted again for payout. Each conversion should be measured independently.
Are cross-border payment fees the same as FX fees?
No. Cross-border processing fees are driven by geographic/payment classification. FX costs arise when currency conversion occurs. A payment can involve either or both.
Final recommendation
When a merchant sees:
€100 charged
and:
$106.82 received
it should not begin by asking whether its PSP charges:
0.5%, 1%, or 2% for FX.
It should reconstruct the path:
What currency did the customer pay?
What currency was processed?
What currency was settled?
What currency did the merchant balance hold?
What currency reached the bank?
Then, for every point where the currency changed:
Who converted it?
At what rate?
At what time?
Was there an explicit fee?
What would a properly aligned reference-rate conversion have produced?
Did another conversion happen later?
Only then can the merchant know what FX actually cost.
The goal is not to achieve the closest possible conversion to one public “mid-market” number at any operational cost.
It is to identify which currency changes are necessary, which are avoidable, what every conversion costs on an all-in basis, and whether changing settlement, payout, provider pricing or currency balances creates enough real savings to justify the additional complexity.
The brief is strongest when treated as the conceptual pillar for the entire Foreign Exchange cluster: every merchant FX problem begins with one forensic question—where did the currency actually change? From there, the article can expose fees, spreads, settlement conversion, payout conversion, double conversion, and currency exposure without conflating them. The brief explicitly assigns this page ownership of that complete PSP FX-cost system.
The most important SEO/content distinction is that this should not become another “what is an FX spread?” page. Its unique value is the end-to-end conversion path: transaction → processing → settlement → balance → payout. That makes it the natural pillar from which the nine narrower Foreign Exchange articles can inherit authority without duplicating it.
How PSP Foreign-Exchange Fees Work — Editorial, SEO and Publication Package
Editorial interpretation
Working title: How PSP Foreign-Exchange Fees Work: Spreads, Markups, Conversion Points, and Merchant Cost
Search intent: foundational merchant explanation of PSP foreign-exchange fees and the full path by which currency conversion affects payment economics.
Primary merchant problem: the merchant can see:
the amount the customer paid;
the currency charged;
the amount eventually settled or paid out;
but cannot explain:
where conversion occurred;
who performed it;
which exchange rate was applied;
whether a separate fee existed;
whether the rate contained a spread or markup;
whether settlement or payout created another conversion.
The brief's evidence anchor is particularly strong: FX cost can exist without a line item called “FX fee.”
Article-owned cost
The economic cost caused by PSP/payment-flow currency conversion, including explicit fees and embedded rate effects.
Source currency
Varies by transaction. The opening uses EUR.
Destination currency
Varies by settlement/payout structure. The opening uses USD.
Conversion stage
Potentially:
transaction/processing;
settlement;
merchant balance;
payout.
Converting/pricing party
Depending on the flow:
PSP;
acquirer;
payment method;
bank;
other financial intermediary.
This must be identified rather than assumed.
Benchmark methodology
Compare the merchant's actual conversion result with a clearly identified reference rate for:
the same currency pair;
same quote direction;
closely aligned timestamp;
comparable amount where size matters.
A reference rate is a measurement tool, not proof that the provider could have executed at that rate.
The ECB explicitly describes its euro reference rates as information-only reference rates, not rates intended for executing market transactions.
Unique thesis
PSP FX should be treated as a currency-conversion path with potentially multiple pricing points, not one percentage fee.
Editorial position
Merchants should judge PSP FX by the final economic result of each conversion stage, not provider labels such as:
“FX fee”;
“conversion fee”;
“competitive exchange rate”;
“no FX fee.”
Common assumption challenged
“If the PSP does not list an FX fee, the conversion is free.”
Merchant decision
Determine:
which conversions are necessary;
which are avoidable;
what each one costs;
whether retaining/settling another currency would help;
whether a cheaper FX setup creates disproportionate operational complexity.
Selected format
Merchant FX cost anatomy.
Recommended architecture
Where did the currency actually change?
What are PSP foreign-exchange fees?
Why “no FX fee” does not mean “no FX cost”
The currencies in a payment flow
Explicit FX fee vs embedded spread
How to calculate the effective exchange rate
What benchmark should merchants use?
Why timestamps matter
Settlement conversion
Payout conversion
How double conversion happens
Cross-border fees vs FX fees
Refund FX at a high level
FX conversion cost vs currency exposure
Merchant FX Cost Stack
How to compare PSP FX economics
Questions to ask a PSP
How merchants should reduce unnecessary FX
Final recommendation
Original practical asset: Merchant FX Cost Stack
Currency-path model
CUSTOMER / TRANSACTION CURRENCY
│
▼
PROCESSING CURRENCY
│
│ Conversion #1?
▼
SETTLEMENT CURRENCY
│
│ Conversion #2?
▼
MERCHANT BALANCE CURRENCY
│
│ Conversion #3?
▼
PAYOUT CURRENCY
│
▼
MERCHANT ECONOMIC / BASE CURRENCY
For each conversion populate:
Source amount
→ Source currency
→ Converting party
→ Rate
→ Timestamp
→ Explicit fee
→ Destination currency
→ Destination amount
→ Benchmark
→ Effective FX cost
Effective FX cost model
Let:
S = source amount
Rᵦ = benchmark conversion rate
Dᵦ = benchmark destination amount
Dₐ = actual final destination amount after attributable explicit conversion fees
Then:
Benchmark destination amount
Dᵦ = S × Rᵦ
Absolute effective conversion cost
Dᵦ − Dₐ
Effective FX cost percentage
(Dᵦ − Dₐ) ÷ Dᵦ × 100
Always state:
benchmark;
timestamp;
pair;
direction;
scope of included fees.
SEO metadata
PSP FX Fees: How Foreign-Exchange Costs Work
Alternative exact-intent version:
How PSP Foreign-Exchange Fees Work
H1
How PSP Foreign-Exchange Fees Work: Spreads, Markups, Conversion Points, and Merchant Cost
Meta description
Learn how PSP FX fees, exchange-rate spreads, settlement conversion and payout currency affect merchant costs—and how to calculate your effective foreign-exchange cost.
URL slug
/solve/payments-cost-too-much/foreign-exchange/how-psp-foreign-exchange-fees-work/
how PSP foreign-exchange fees work
Secondary keyword targets
PSP FX fees
payment provider FX fees
payment processing exchange fees
merchant FX fees
PSP currency conversion
FX markup payments
settlement FX fees
payment provider exchange rates
These match the editorial brief's assigned discovery targets.
Related entities
foreign exchange
FX fee
FX spread
exchange rate
currency conversion
PSP
settlement currency
payout currency
presentment currency
processing currency
merchant balance
benchmark rate
currency pair
double conversion
multi-currency settlement
treasury
Article excerpt
PSP foreign-exchange cost is not always a standalone fee. Follow the complete currency path to identify explicit charges, embedded rate differences, settlement conversion, payout conversion and the merchant's all-in effective FX cost.
Search-intent coverage map
Query/intention
Primary answer
how PSP foreign-exchange fees work
Opening + full cost anatomy
PSP FX fees
Explicit/embedded pricing
payment provider FX fees
Cost types
merchant FX fees
Effective cost model
FX markup payments
Embedded spread section
PSP currency conversion
Currency path
payment provider exchange rates
Benchmark/rate comparison
settlement FX fees
Settlement conversion
payout conversion fees
Payout section
no FX fee but bad exchange rate
Explicit vs embedded
calculate FX fee
Effective FX model
FX spread vs fee
Dedicated distinction
presentment vs settlement currency
Currency-path section
double currency conversion
Double-conversion section
cross-border fee vs FX fee
Boundary section
Do not create separate repetitive sections merely to repeat these terms.
Google's current Search guidance recommends people-first content that provides original, substantial analysis, and separately recommends using the words people search for in prominent places such as the title and main heading where natural.
Extractable search-answer blocks
What are PSP FX fees?
PSP FX fees are merchant costs created when a payment provider or related participant converts money between currencies. The cost may appear as a separate fee, an exchange-rate difference, settlement conversion, payout conversion, or a combination of these.
Can a PSP charge FX without listing an FX fee?
A merchant can incur FX cost even without a standalone fee because the conversion rate itself can produce a different economic result from a defined benchmark. Merchants should compare the final converted amount, not only visible fee labels.
How do you calculate PSP FX cost?
Compare the actual destination-currency amount after conversion fees with the amount a consistently selected benchmark rate would have produced for the same source amount, pair, direction and timestamp.
What is the difference between an FX fee and FX spread?
An FX fee is a separately stated charge. An FX spread or markup is measured through the exchange rate. A PSP arrangement can contain either or both.
Internal-link architecture
This article is the cluster pillar and should link to all nine supporting Foreign Exchange articles.
What Is an FX Spread?
Anchor:
what an FX spread is
FX spread mechanics
Owns detailed rate/spread methodology.
How to Identify Hidden FX Markups
Anchor:
identify embedded FX markup
audit a PSP exchange rate
Owns statement reconstruction and markup detection.
Multi-Currency Settlement and FX Costs
Anchor:
multi-currency settlement
holding multiple settlement currencies
Owns settlement architecture.
Avoiding Double Currency Conversion
Anchor:
avoid double currency conversion
identify unnecessary currency conversions
Owns the two-stage conversion diagnostic.
Presentment vs Settlement Currency
Anchor:
presentment vs settlement currency
Owns the full distinction.
How to Compare PSP Exchange Rates
Anchor:
compare PSP exchange rates
compare provider FX pricing
Owns proposal comparison.
Managing Payment FX Exposure
Anchor:
manage payment-related FX exposure
Owns timing/exposure risk.
Currency Conversion for Refunds
Anchor:
FX on refunds
refund currency conversion
Owns refund mechanics.
FX Costs by Market
Anchor:
FX costs by market
currency-pair FX costs
Owns regional/currency-pair differences.
Google recommends descriptive internal link text that helps users and Google understand destination pages.
Supporting visual
Merchant FX Cost Stack
Visual structure
€ CUSTOMER PAYMENT
│
▼
TRANSACTION / PRESENTMENT
│
FX EVENT?
▼
PROCESSING
│
FX EVENT?
▼
SETTLEMENT BALANCE
│
FX EVENT?
▼
MERCHANT BALANCE
│
FX EVENT?
▼
BANK PAYOUT
│
▼
MERCHANT BASE CURRENCY
At every FX event show:
currency pair → converting party → rate → timestamp → fee → benchmark → effective cost
Image alt text
Merchant FX cost diagram showing transaction, processing, settlement, balance and payout currencies, with each currency change identified as a potential foreign-exchange fee or spread event.
Authoritative source recommendations
Merchant-specific PSP agreement and fee schedule
Highest-priority evidence for:
actual FX fee;
rate methodology;
currency-pair pricing;
settlement conversion;
payout conversion;
negotiated tiers.
Merchant settlement reports
Use to reconstruct:
source amount;
settlement amount;
rate;
conversion date;
fees.
Merchant payout reports
Use to identify any second conversion between balance and bank account.
European Central Bank reference-rate framework
Use to explain benchmark discipline and why a public reference rate is a comparison tool rather than an executable transaction rate.
Use for current public payout-currency capabilities and conditions.
Use only to establish supported transaction currencies, not universal settlement availability.
Proposed author and reviewers
Proposed author:
Do not invent a person.
Recommended reviewers:
payments pricing specialist;
treasury specialist;
merchant finance reviewer.
These are the specific review roles requested by the brief.
Additional useful review:
settlement specialist;
payments operations lead;
data analyst.
Highest-value original contribution
Add an approved, anonymized merchant FX path containing:
source currency;
settlement currency;
payout currency;
converted volume;
actual provider amounts;
benchmark methodology;
observed all-in FX cost;
change implemented;
measured post-change cost.
Google's current people-first guidance specifically encourages original information, analysis and demonstrated first-hand expertise.
FX-rate fact-check items
For every numerical rate claim verify:
source currency;
destination currency;
quote direction;
amount;
timestamp;
conversion stage;
provider;
benchmark;
explicit fee;
effective date.
Do not compare rates captured at materially different times without disclosure.
Provider-pricing fact-check
Verify:
fee schedule;
explicit FX percentage;
fixed conversion fee;
provider base/reference methodology;
spread methodology if disclosed;
settlement pricing;
payout pricing;
volume tiers;
negotiated pricing;
automatic-conversion rules.
Do not assume public retail pricing applies to enterprise merchants.
Settlement/payout fact-check
Verify separately:
Settlement
settlement currencies supported;
default settlement currency;
automatic conversions;
conversion timing;
rate timing;
merchant choice.
Payout
payout currencies;
receiving-bank requirements;
bank-account denomination;
payout conversion;
third-party bank fees.
Double-conversion fact-check
For suspected:
A → B → C
document:
First conversion
why it occurs;
converter;
rate;
fee.
Second conversion
why it occurs;
converter;
rate;
fee.
Alternative
Verify whether:
A → C
is actually available.
Do not call the existing route unnecessary until the alternative is operationally feasible.
Refund FX fact-check
Verify:
original transaction currency;
original settlement currency;
refund currency;
original rate;
refund rate;
refund-date conversion;
provider treatment;
partial-refund behavior;
merchant funding currency.
Do not assume the original exchange rate is reused.
Market/currency fact-check
For market-specific claims verify:
currency pair;
settlement availability;
convertibility;
local banking conditions;
capital/exchange restrictions;
provider coverage;
transaction size;
effective date.
Do not infer a merchant spread purely from wholesale-market liquidity.
Treasury and regulatory flags
Foreign-exchange architecture can intersect with:
exchange controls;
capital controls;
banking restrictions;
currency convertibility;
entity ownership;
tax/accounting rules.
This article should not prescribe:
speculative currency trades;
financial hedges;
tax treatment;
accounting treatment.
Information notice: This article provides general information and does not constitute legal, tax, accounting, investment, treasury or financial advice. Merchants should verify applicable currency rules, provider terms and settlement restrictions with qualified advisers, banks, payment providers and relevant authorities.
Amber-flag claims
“No FX fee means free conversion.”
Wrong.
A conversion cost may be reflected in the rate or another conversion stage.
“Mid-market is the rate the merchant should receive.”
Too broad.
A benchmark may be useful analytically without being an executable merchant rate. The ECB itself labels its reference rates information-only.
“Any difference from the benchmark is provider profit.”
Do not publish.
The difference is an analytical effective cost unless provider economics are independently established.
“The PSP FX fee is the total FX cost.”
Not necessarily.
Settlement and payout can create additional conversion.
“Presentment currency equals settlement currency.”
Do not assume.
“Supported currency means the merchant can settle that currency.”
Do not assume.
“Cross-border fee and FX fee are the same.”
Wrong.
One concerns transaction geography; the other currency conversion.
“Multi-currency settlement always saves money.”
Wrong.
Operational and account complexity can exceed avoided FX.
“Double conversion is always avoidable.”
Wrong.
Technical, banking or regulatory constraints may require the route.
Do not publish without current verified evidence.
Do not publish.
Do not publish unless verified from the applicable current fee schedule.
Current public evidence supports:
Foreign-exchange charges can apply
Multiple payout currencies can be available
Broad transaction-currency support exists
Before publication, internally verify:
FX pricing methodology;
applicable merchant fee schedules;
whether rates contain an explicit markup;
any provider reference/base rate;
rate timestamp;
rate-lock mechanics;
supported settlement currencies;
supported payout currencies by merchant/market;
balance-holding capabilities;
automatic-conversion rules;
processing-currency versus settlement-currency behavior;
refund conversion treatment;
direct-versus-intermediary currency routes;
reporting fields merchants can access;
approved merchant FX case studies.
Do not fill these gaps from assumptions.
Measurement plan
Track monthly and by currency pair.
Converted volume
How much economic value underwent merchant-side conversion?
All-in effective FX cost
Benchmark converted amount
minus actual converted amount
divided by benchmark converted amount.
Explicit FX fees
Track separately where visible.
Settlement-conversion cost
Conversion occurring before/when proceeds reach merchant balance.
Payout-conversion cost
Conversion occurring when balance moves to bank account.
FX cost per successful payment
Useful for payments operations.
Double-conversion volume
Value that undergoes two or more merchant-side currency changes.
Weighted merchant FX cost
Volume-weighted across currency pairs.
Avoidable-conversion share
Percentage of converted volume identified as potentially redesignable after feasibility analysis.
Merchant FX audit checklist
Map every currency from checkout to bank.
Identify every currency-change arrow.
Record source and destination amount.
Identify converting party.
Capture provider rate.
Capture timestamp.
Select defensible benchmark.
Normalize quote direction.
Record explicit fees.
Calculate final all-in conversion result.
Separate settlement FX from payout FX.
Identify possible double conversion.
Check whether currency can be retained.
Compare settlement currency with expense currency.
Review refund FX.
Segment costs by pair.
Weight results by volume.
Negotiate only after actual cost is known.
Re-measure after changing provider or settlement structure.
Cluster sameness-audit fields
Field
How PSP Foreign-Exchange Fees Work
Opening
€100 customer payment → $106.82 merchant receipt
Primary problem
Merchant cannot identify where/how conversion cost arose
Source currency
EUR illustrative
Destination currency
USD illustrative
Conversion stage
Potentially transaction, settlement and payout
Converting party
PSP/acquirer/payment method/bank
Primary format
Merchant FX cost anatomy
Unique thesis
FX is a conversion path, not one fee
Common assumption
No listed fee means no FX cost
Original framework
Merchant FX Cost Stack
Primary metric
All-in effective FX cost
Merchant decision
Which conversions should be redesigned?
Conclusion
Optimize the path, not merely the quoted spread
Cannibalization check
This article does not own:
spread mechanics in depth;
hidden markup detection methodology;
multi-currency settlement architecture in depth;
double-conversion remediation in depth;
full presentment-vs-settlement explanation;
PSP rate-comparison methodology in depth;
FX exposure management;
refund FX;
market-by-market FX intelligence.
It introduces those concepts and links outward.
That matches the cluster ownership map.
Google publication checklist
Primary question answered immediately.
H1 matches search intent naturally.
Article provides original merchant framework rather than summarizing generic FX definitions.
“FX fee,” “FX spread,” “settlement FX,” and “payout FX” remain distinct.
Every quantitative rate example has pair, direction and timestamp methodology.
Explicit fee and embedded rate effect are separated.
Currency path appears visually.
Named expert author.
Named treasury/pricing reviewer.
Last-reviewed date visible.
Supporting image has descriptive alt text.
Contextual links point to each supporting cluster page.
Article structured data matches visible author/date/headline data.
No unsupported “best FX,” “mid-market,” or “zero markup” claims.
Merchant-specific examples are anonymized and approved.
Google says its systems prioritize helpful, reliable, people-first information and explicitly asks whether a page provides original analysis, comprehensive treatment and demonstrated expertise.
Google's Search Essentials recommend naturally using words people search for in prominent locations such as titles and headings, while its Article structured-data documentation says Article markup can help Google understand article properties such as headline, author, image and dates.
Publication status
Research refreshed: 15 August 2026.
Editorially ready: Yes.
SEO architecture ready: Yes.
Before publication:
verify settlement currencies and payout conditions;
verify any public/current fee schedule relied upon;
have treasury validate the benchmark methodology;
have finance validate the all-in effective-cost formula;
have payments operations validate each currency-flow stage;
verify refund treatment before mentioning it specifically;
avoid presenting public reference rates as executable merchant rates;
label hypothetical conversion examples clearly;
require source currency, destination currency, converting party and timestamp for every consequential FX-cost claim.
Publication principle
The page should leave the merchant able to reconstruct this:
Customer paid Currency A → proceeds were processed in Currency B → settlement occurred in Currency C → merchant balance was Currency C → payout arrived in Currency D.
And then, for every arrow:
Who converted it, which rate was used, when was it determined, what explicit fee applied, how did the final result compare with a defensible benchmark, and was that conversion actually necessary?
That is the level at which PSP foreign-exchange cost becomes measurable—and therefore manageable.
v1
How PSP Foreign-Exchange Fees Work
A PSP's foreign-exchange fee is almost never a fee in the sense most merchants picture — a clearly labeled charge on a statement. It's usually a spread: the difference between the real market price of a currency and the worse price a merchant or customer actually receives, quietly built into the exchange rate itself rather than itemized. Understanding that mechanic — not just knowing it exists — is what makes it possible to evaluate whether a PSP's FX pricing is actually fair.
The mid-market rate: the reference point everything else is measured against
The mid-market rate (also called the interbank rate) is the real, wholesale exchange rate between two currencies at a given moment — the midpoint between the price at which currency is bought and sold in the wholesale market, freely available on sources like Google Finance, XE.com, or Bloomberg. This is the rate banks themselves use when trading currency with each other, and it's the only honest baseline for evaluating whether a quoted conversion rate is fair.
No retail or merchant-facing provider passes through the exact mid-market rate for free — the mechanism by which they don't is what this entire topic is actually about.
The spread: how the markup actually gets applied
A PSP (or bank, or card network) buys currency at close to the mid-market rate and sells it to the merchant or customer at a worse rate — the difference is the spread, and it functions as pure margin for the provider. The calculation is simple and worth knowing directly:
FX markup (%) = ((mid-market rate − provider rate) ÷ mid-market rate) × 100
A concrete illustration: if the mid-market rate for USD/EUR is 0.9200 and a provider quotes 0.9400, the spread is roughly 200 basis points, or about 2.17%. On a $100,000 payment, that spread alone amounts to $2,170 — money that never appears as a discrete line item anywhere, because it's embedded directly in the exchange rate offered rather than disclosed as a separate charge.
This is precisely why a "zero fee" or "no transaction fee" conversion claim can still be expensive. A provider can genuinely charge no separate transaction fee while still extracting a substantial margin purely through a worse exchange rate — the visible fee (often zero, or a small flat amount) and the invisible spread are two entirely different cost components, and a provider highlighting the first while staying silent on the second is a common and specifically documented pattern.
Why this is structurally different from other payment fees
Regulatory disclosure requirements generally cover payment fees but historically have not covered the exchange rate margin itself. Payment fees, in jurisdictions with consumer protection rules around this (UK Payment Services Regulations are one specific example), must be disclosed clearly and separately — but the FX spread has historically been bundled directly into the rate rather than treated as a disclosable fee, meaning a provider can be fully compliant while still offering a rate that's 2–4% worse than the mid-market reference with no separate disclosure requirement forcing that gap into the open.
Real comparative data illustrates how large this gap can be even among large, reputable institutions. One published comparison (sending £1,000 GBP to EUR) found major UK banks applying markups ranging from 2.5% to 3.7% — HSBC at the high end (3.7%), Lloyds at 3.6%, and Barclays, NatWest, TSB, and Santander each around 2.5% — with none of them displaying the markup as a separate line item. By contrast, the same comparison found some newer providers passing through the mid-market rate with no hidden markup at all, and at least one major consumer app applying only a 0.15% spread on a standard transfer. The spread between the most and least expensive options in that single comparison — over 3.5 percentage points on the same currency pair, on the same day — illustrates that "FX fee" is not a fixed cost of doing business; it's a specific, shoppable number that varies enormously by provider.
Consumer awareness of this gap is notably low relative to how large it is. One survey found only around 22% of consumers believed their bank gave them a fair deal on currency conversion, and roughly 90% suspected banks marked up exchange rates in some form — widespread suspicion, but comparatively little concrete knowledge of the actual figures, which is part of why the spread persists as a durable, underexamined cost.
Where this shows up specifically for merchants, not just consumers
Card network scheme rates. When a card transaction crosses currencies, the card network itself applies a conversion at a rate close to (but not identical to) the mid-market rate, and issuers frequently add their own foreign transaction fee on top of that. This layering — network-level rate, then issuer markup, then potentially a merchant-side or PSP-side markup as well — means a single cross-currency transaction can accumulate FX cost at more than one point in the chain, not just once.
PSP-managed settlement conversion. For merchants selling in multiple currencies, the PSP typically manages the entire conversion process — detecting the transaction currency, converting it, and settling the proceeds into the merchant's chosen settlement currency — without requiring the merchant to manage separate banking relationships in every currency. This convenience has a cost baked in: the PSP's own FX margin on that conversion, layered on top of whatever the card network already charged. A commonly cited range for this specific merchant-facing spread is 0.5–1.5% on non-base-currency transaction volume — smaller than the more consumer-facing bank markups cited above, but still a material, compounding cost at real transaction volume.
Volume tiering is common and often undisclosed by default. Enterprise-tier customers processing high volume may be offered spreads as low as 0.3–0.5%, while smaller merchants on the same platform pay 2–3% for functionally the same conversion — and the specific volume thresholds that unlock better pricing are frequently left unspecified in standard contracts unless a merchant explicitly negotiates for them.
The merchant-side lever most guides skip: multi-currency settlement and natural hedging
A meaningful way to reduce FX cost isn't to negotiate a better spread — it's to avoid triggering the conversion at all, where genuinely possible. Multi-currency settlement lets a merchant hold and settle proceeds directly in the currency they were collected in, rather than having the PSP or acquirer automatically convert every transaction into a single base settlement currency.
This matters most where a merchant has a natural hedge — recurring expenses denominated in the same currency as incoming revenue. A UK-based merchant processing EUR-denominated sales from European customers, who also pays EUR-denominated costs for European operations (suppliers, staff, ad spend), can settle directly in EUR and skip the conversion entirely for that currency pair — eliminating the FX cost on that portion of volume rather than merely negotiating it down. This requires both acquirer support for multi-currency settlement and a multi-currency merchant account capable of holding the relevant currency, and not every acquirer offers this, or offers it across every currency a merchant might want.
Where a natural hedge doesn't exist, the merchant still gets to choose the timing of conversion, rather than being forced into a conversion at the moment of each individual transaction. Holding a currency balance and converting in bulk on a schedule the merchant controls — rather than at whatever rate applies transaction by transaction — gives a treasury team more control, though it introduces its own tradeoff: holding an unconverted balance carries currency risk if that balance moves against the merchant before conversion, which is where hedging tools (forward contracts locking in a future conversion rate) become relevant for merchants with predictable, large-volume currency exposure.
What to actually ask a PSP about its FX pricing
Is the mid-market rate at the time of each transaction disclosed alongside the rate actually applied? A provider offering this comparison transparently is a meaningfully different proposition than one that only shows the final converted amount.
Is the FX spread stated as an explicit basis-point or percentage figure, separate from any transaction fee? A "zero fee" claim with no separate spread disclosure should be treated as incomplete information, not as evidence of a genuinely free conversion.
What are the volume thresholds for improved pricing, and are they specified in the contract? If better rates exist only informally and aren't written down, they're not a reliable basis for cost planning.
Does the platform support multi-currency settlement in the currencies that matter most to your business, and is there a genuine natural-hedge opportunity worth structuring around?
Is pricing consistent across the currency pairs you actually use, or does it vary significantly by corridor? A provider competitive on major currency pairs (USD/EUR, USD/GBP) can be markedly less competitive on less liquid or less common pairs, where spreads are commonly wider across the industry.
Quick reference
Concept
What it means
Typical range
Mid-market rate
The true wholesale exchange rate, the only fair baseline
N/A — reference point, not a price paid
FX spread / markup
Gap between mid-market rate and the rate actually offered
0.15% (best-in-class) to 3.7%+ (major retail banks)
PSP merchant settlement conversion
Spread applied when a PSP converts multi-currency sales into settlement currency
~0.5–1.5%
Enterprise/high-volume PSP pricing
Negotiated spread for large merchants
~0.3–0.5%
Standard/unnegotiated merchant pricing
Default spread for smaller merchants on the same platform
~2–3%
Card network + issuer layered FX cost
Network scheme rate plus issuer foreign transaction fee, stacked
Varies; can compound beyond either component alone
This guide synthesizes publicly available FX-industry commentary, PSP and payment-platform documentation, and consumer-finance comparisons of currency conversion pricing. Specific spreads, thresholds, and comparative rates vary by provider, currency pair, and volume — treat the figures here as directional benchmarks for evaluating your own PSP's pricing rather than fixed rates for any specific provider.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗