Presentment vs Settlement Currency Costs

Presentment vs Settlement Currency: Where Merchant FX Costs Begin

At month-end, a payments team is reconciling one otherwise ordinary sale.

The checkout record says:

€100

The settlement report says:

$107

The bank statement says:

$106.70

Nothing necessarily went wrong.

But those three numbers describe three different layers of the payment.

The customer transacted in euros.

The payment proceeds were settled in dollars.

And the amount that ultimately reached the merchant's bank was different again.

The question is not simply:

“What currency was the payment in?”

It is:

Which currency existed at each stage between checkout and merchant-accessible funds?

That distinction is where merchant-side foreign-exchange cost becomes traceable.

What is presentment currency?

Presentment currency is the currency in which the transaction amount is presented or submitted to the customer/payment flow in the relevant checkout context.

If checkout submits:

€100

then EUR is the transaction's presentment currency for the purpose of this analysis.

Presentment affects what the customer is asked to pay.

It does not, by itself, tell the merchant:

•what currency the payment method processes;

•what currency the acquirer settles;

•what currency the PSP credits to the merchant;

•what currency ultimately reaches the merchant's bank.

That is the essential distinction.

Presentment currency vs settlement currency

In concise terms:

Presentment currency = the currency of the customer-facing transaction.

Settlement currency = the currency in which the relevant payment proceeds are credited or settled to the merchant/provider balance.

They can match.

For example:

Customer pays EUR

↓

Settlement in EUR

Or they can differ:

Customer pays EUR

↓

Conversion occurs

↓

Settlement in USD

When they differ, the merchant needs to identify the conversion between them.

That is the beginning of the merchant-side FX investigation.

“We accept EUR” does not mean “we receive EUR”

This is the assumption the article should eliminate.

A merchant can support an EUR-denominated customer transaction while operating a settlement arrangement that converts eligible proceeds into USD.

From the customer's perspective:

EUR was accepted.

From the merchant's treasury perspective:

USD was received.

Both statements can be true.

The mistake is treating them as the same currency field.

Display currency is not always presentment currency

There can be another layer before the payment itself.

Display currency

The currency in which the website or app shows a price.

Presentment/transaction currency

The currency actually submitted for payment.

In many ordinary checkouts, the two are the same.

But merchants should not build their financial architecture around that assumption.

A storefront could display localized or estimated pricing while the transaction is ultimately submitted in another supported currency.

For FX attribution, the authoritative question is:

What currency and amount entered the actual payment transaction?

Not merely:

What symbol did the product page display?

Customer account currency is another separate layer

Suppose a customer pays:

€100

but their card or bank account is denominated in another currency.

Their issuer or bank may perform a customer-side conversion.

That is not automatically the merchant's FX event.

The merchant could still receive EUR settlement.

So keep separate:

CUSTOMER ACCOUNT CURRENCY

≠

PRESENTMENT CURRENCY

≠

MERCHANT SETTLEMENT CURRENCY

Customer-side conversion belongs primarily to the customer-currency experience.

This article is concerned with the merchant side.

What is transaction currency?

In many merchant reporting systems, transaction currency and presentment currency will refer to the same monetary amount submitted for payment.

But terminology varies by provider and integration.

For this article, the safest operating rule is:

Record the exact currency attached to the payment transaction independently from every later settlement or payout currency.

This avoids trying to force provider-specific vocabulary into one supposedly universal data model.

What is processing currency?

Processing currency is a useful intermediate layer when the payment method or acquiring path imposes its own currency requirements.

It should not be assumed to exist as a distinct merchant-facing conversion in every payment.

But it can matter.

Its Interac method documentation specifies CAD as the processing currency, while MyBank specifies EUR. Its card documentation says card processing currencies depend on the acquiring banks.

The lesson is not that every payment requires conversion.

It is that:

broad currency support at checkout does not prove that every underlying payment method processes every currency identically.

A merchant may therefore need to map:

Presentment

↓

Processing

↓

Settlement

rather than assuming presentment flows directly into settlement unchanged.

What is settlement currency?

Settlement currency is the currency in which relevant payment proceeds are credited or settled at the merchant/provider settlement layer.

That definition sounds straightforward.

The important questions are operational:

•Can the merchant choose it?

•Is it determined by the payment method?

•Does it vary by acquirer?

•Which transaction currencies can settle unchanged?

•Which are automatically converted?

•At what point is conversion performed?

•Which rate applies?

•Can the merchant retain the original transaction currency?

If the merchant cannot answer those questions, its “FX rate” analysis is premature.

Settlement currency is not necessarily the merchant's final currency

This is another important boundary.

Suppose the payment journey is:

Checkout

EUR 100

↓

Settlement

USD 107

↓

Merchant balance

USD 107

↓

Bank payout

GBP 82.xx

USD is the settlement currency.

GBP is the payout currency.

Neither needs to be the customer's transaction currency.

And a merchant whose reporting currency is EUR could still have yet another economic layer.

The phrase payment currency is therefore inadequate for serious multi-currency reporting.

What is merchant balance currency?

Depending on the provider architecture, settled funds may exist in a merchant balance before payout.

The balance currency describes the unit in which that stored merchant value is held.

Sometimes:

settlement currency = balance currency.

But the distinction is still useful because it makes the next question explicit:

Does another conversion happen when that balance is paid out?

This is particularly important in systems where merchants can maintain more than one currency balance.

What is payout currency?

Payout currency is the currency transferred from the merchant/provider balance into the merchant's bank or other payout destination.

It may match settlement:

Settlement USD

↓

Payout USD

Or it may differ:

Settlement USD

↓

Conversion

↓

Payout GBP

Those scenarios have different FX economics.

That makes the receiving bank account another meaningful part of the currency path.

It does not establish that every merchant can receive every supported transaction currency without conversion.

The complete currency path

A merchant should therefore think in layers:

1. DISPLAY CURRENCY

↓

•PRESENTMENT / TRANSACTION CURRENCY

↓

•PROCESSING CURRENCY, IF RELEVANT

↓

•SETTLEMENT CURRENCY

↓

•MERCHANT BALANCE CURRENCY

↓

•PAYOUT CURRENCY

↓

•MERCHANT REPORTING / ECONOMIC CURRENCY

Every arrow where the ISO currency code changes is a potential FX event.

That is the governing rule of the entire Foreign Exchange cluster.

Where does merchant FX actually occur?

FX occurs when value changes from one currency to another.

For every conversion, identify:

•source currency;

•source amount;

•destination currency;

•destination amount;

•party performing or pricing the conversion;

•rate;

•rate timestamp;

•explicit fee;

•benchmark used for analysis;

•embedded spread or effective rate difference where applicable.

Without those data, a merchant may know that its payout is smaller than expected without knowing why.

Case: presentment and settlement match

Suppose:

Transaction: EUR 100

Settlement: EUR 100 less applicable non-FX payment fees

Balance: EUR

Payout: EUR

From these currency fields alone, there is no merchant-side EUR→other-currency conversion to analyze.

That does not mean:

•the payment has no processing fees;

•the customer incurred no FX;

•the merchant has no economic currency exposure;

•no later bank conversion can occur.

It means only that this mapped merchant payment path shows no currency change through payout.

That precision matters.

Case: presentment and settlement differ

Now suppose:

Transaction: EUR 100

Settlement: USD 107

There is a EUR→USD conversion somewhere in the transaction-to-settlement path.

The merchant needs to determine:

•which participant performs it;

•when the rate is set;

•what rate is applied;

•whether a separately disclosed conversion fee exists;

•whether the commercial cost is embedded in the rate.

The mere fact that the settlement report shows dollars does not answer those questions.

But it tells the merchant exactly where to investigate.

Presentment-to-settlement FX

The narrow economic model for this article is:

Transaction amount

source transaction currency and amount

multiplied by:

Conversion rate

less:

Explicit conversion fee, where applicable

equals:

Settlement amount

The resulting settlement amount can then be compared with an appropriate benchmark conversion if the merchant wants to measure effective FX cost.

That benchmark analysis is covered more deeply in How to Compare PSP Exchange Rates.

This article's role is to identify where the benchmark belongs in the flow.

A benchmark needs a timestamp

If the transaction took place at 10:00 and the provider converted at settlement at 16:00, a 10:00 FX benchmark does not isolate the provider's settlement pricing.

Currency markets can move between those points.

The ECB, for example, says its euro foreign-exchange reference rates aim to reflect market conditions around 14:15 CET and are generally published around 16:00 CET. It also expressly says those rates are provided for information purposes and are not transaction rates.

That makes them potentially useful analytical references in appropriate cases.

It does not make them the rate a PSP was necessarily able or obligated to execute.

Rate timing is part of the currency architecture

A merchant needs to know not only:

which currencies differ

but:

when the exchange rate between them becomes economically relevant.

A conversion may be priced at or around:

•authorization;

•capture;

•clearing;

•settlement;

•balance conversion;

•payout.

The actual provider method must be verified.

The brief specifically warns against assuming the FX rate is locked at checkout.

Settlement conversion vs payout conversion

These are separate events.

Settlement conversion

The transaction proceeds change currency before or when they are credited to the merchant's settlement/balance layer.

Example:

EUR transaction

↓

USD settlement

Payout conversion

The already-settled merchant balance changes currency when it moves to the receiving bank account.

Example:

USD balance

↓

GBP payout

A merchant can incur:

•settlement conversion only;

•payout conversion only;

•both.

Do not report both under one vague field called:

FX fee.

The $107 settlement and $106.70 bank receipt

Return to the opening.

Checkout: EUR 100

Settlement report: USD 107.00

Bank receipt: USD 106.70

The $0.30 difference does not automatically prove another FX conversion, because the settlement and bank currencies are both USD.

Possible causes could include whatever payout, bank, remittance, or other agreed charges apply to the merchant's arrangement.

Those must be identified separately.

This is an important analytical safeguard:

a difference in amount is not necessarily a difference in currency.

Foreign Exchange owns currency-conversion economics.

Other payout or remittance charges belong elsewhere unless they are directly caused by conversion.

Local-currency pricing is not local-currency settlement

A merchant may invest heavily in localization:

•EUR prices for euro-area customers;

•GBP prices in the UK;

•CAD prices in Canada.

That may improve the customer-facing experience.

It does not tell finance what currency the business receives.

The merchant could accept all three customer currencies while settling everything into USD.

Therefore:

checkout localization

and:

merchant settlement architecture

are separate decisions.

The Foreign Exchange cluster owns the cost created by that gap; Currency & Pricing owns the deeper customer-facing pricing decision.

Supporting a currency does not prove settlement support

This distinction is particularly important when merchants read provider documentation.

Its payout documentation separately places conditions on which currencies can be paid out to a merchant.

Those are different capability questions:

Can a payment be denominated in this currency?

versus:

Can the merchant retain or receive this currency in settlement/payout?

Do not infer the second from the first.

Payment methods can further constrain the currency path

The payment method matters too.

•Interac processing in CAD;

•MyBank processing in EUR;

•Bank Transfer Malaysia processing in MYR;

•card processing currencies depending on acquiring banks.

This is why a merchant should model currency paths at the relevant payment-method/acquiring level rather than globally declaring:

“Our PSP supports EUR.”

That statement is too broad for financial analysis.

Presentment-to-Settlement Currency Flow

The article's core practical asset is a per-transaction currency record.

Layer

Amount

Currency

What to record

Customer display

100

EUR

What the interface showed

Transaction/presentment

100

EUR

Actual payment currency

Processing

—

EUR/USD/etc.

If distinct/relevant

Settlement

107

USD

Amount credited

Merchant balance

107

USD

Currency held

Payout

106.70

USD

Amount transferred

Merchant base/reporting

—

Varies

Finance reporting layer

Then mark every currency transition:

EUR

↓

EUR

↓

USD ← FX EVENT

↓

USD

↓

USD

The currency map immediately tells finance that the merchant FX investigation belongs between processing/transaction and settlement, not at payout in this example.

Why finance needs more than “currency”

A robust payment data model should avoid one generic field called:

currency

Instead, where the provider/data architecture supports it, use fields conceptually equivalent to:

display_currency

transaction_currency

processing_currency

settlement_currency

balance_currency

payout_currency

reporting_currency

Not every provider exposes every layer.

But internally preserving the distinction creates better:

•reconciliation;

•FX attribution;

•provider comparison;

•treasury reporting;

•refund analysis.

•end-user payment currency code;

•product currency code;

•revenue in USD;

•revenue in payment currency;

•end-user payment in USD;

•end-user payment in local currency.

Those fields should not be interpreted as a complete settlement data model without internal verification.

But they demonstrate the broader architectural point:

one payment can legitimately have several monetary representations.

A merchant data warehouse should preserve those differences rather than collapse them into a single “payment amount.”

Reporting failure: one currency column

Consider a dashboard with:

Transaction ID

Amount

Currency

48172

100

EUR

That tells payments operations almost nothing about merchant FX.

Finance still cannot answer:

•what was settled;

•in what currency;

•whether conversion occurred;

•what reached the bank.

Now compare:

Field

Value

Transaction

€100

Processing currency

EUR

Settlement

$107

Balance

$107

Payout

$106.70

Payout currency

USD

The second data model makes the conversion boundary visible.

Reporting failure: converting everything into base currency too early

Another common analytical mistake is to normalize every monetary field into USD immediately for reporting.

That is useful for consolidated financial views.

But if the original currency dimensions disappear, the merchant loses the evidence required to investigate FX.

Preserve:

original amount + original currency

alongside:

normalized reporting amount + reporting currency.

Otherwise a merchant may know that EUR transactions generated $5 million of reported revenue without knowing what FX path produced that dollar value.

A practical currency event record

For each payment, maintain a lineage where possible:

Transaction ID

Timestamp

Customer-facing amount

Customer-facing currency

Transaction amount

Transaction currency

Processing currency

Settlement amount

Settlement currency

Settlement timestamp

Merchant balance amount

Merchant balance currency

Payout amount

Payout currency

Payout timestamp

Conversion event ID

Source currency

Destination currency

Applied rate

Rate timestamp

Explicit FX fee

Provider / acquirer

Payment method

Merchant entity / MID

This turns FX from an invoice mystery into a data problem.

How to measure settlement-currency mismatch

The brief calls for several specific metrics.

Volume presented by currency

Example:

EUR presented volume

GBP presented volume

USD presented volume

CAD presented volume

Volume settled by currency

Measure independently.

A merchant could have:

EUR presented: €20m equivalent

EUR settlement: €4m

That discrepancy may reveal that much of its EUR payment volume is converted before settlement.

Percentage converted at settlement

Conceptually:

eligible transaction value where transaction currency ≠ settlement currency

÷ relevant transaction value

Use comparable base values or transaction counts carefully when aggregating different currencies.

FX cost by presentment-to-settlement pair

Examples:

EUR → USD

GBP → USD

CAD → USD

This is more useful than one global “FX rate.”

Subsequent payout conversion

Flag transactions/batches where:

settlement/balance currency ≠ payout currency

That identifies potential second-stage FX.

Keep amount mismatch separate from currency mismatch

This is important enough to become a rule.

Currency mismatch

EUR transaction

USD settlement

Currency conversion exists somewhere.

Amount mismatch

USD settlement 107.00

USD payout 106.70

No currency change is visible.

Investigate fees, adjustments, refunds, chargebacks, reserves, remittance costs, bank charges, or other contractual factors separately.

Therefore a smaller bank deposit should not automatically be labeled FX.

Where double conversion begins

This article should identify the condition but not own the full remediation.

Suppose:

Customer pays EUR

↓

Merchant settles USD

↓

Merchant needs GBP

↓

Merchant receives/converts to GBP

The currency flow is:

EUR → USD → GBP

That is a potential double-conversion structure.

The dedicated Avoiding Double Currency Conversion article should determine:

•why USD exists as the intermediate currency;

•cost of each conversion;

•whether EUR→GBP is technically available;

•whether the alternative is operationally better.

Here, the important contribution is noticing the second arrow at all.

Presentment/settlement mismatch can also create exposure

Suppose customers pay EUR throughout the day.

The merchant is settled in USD the next day.

If the conversion rate is determined later rather than at transaction time, the economic value can move between sale and conversion.

That is an FX-exposure window.

This article should identify it.

The detailed question of how the merchant measures or manages that exposure belongs to Managing Payment FX Exposure.

Do not confuse:

cost of conversion

with:

change in currency value before conversion.

The brief expressly requires those concepts to remain separate.

Refunds depend on knowing the original currency layers

A refund becomes difficult to reconcile if the merchant preserved only one generic currency.

Suppose:

Original transaction: EUR

Settlement: USD

Refund: EUR

Finance needs to know:

•whether original proceeds were converted;

•whether the refund reverses that conversion;

•which balance funds the refund;

•whether a new conversion occurs.

That is why the currency lineage must survive after the original payment.

The full refund-rate analysis belongs in Currency Conversion for Refunds.

How should merchants benchmark conversion?

This article should not become the PSP-rate-comparison page.

The minimum standard is:

For any transaction-to-settlement conversion, preserve:

•source amount;

•source currency;

•destination amount;

•destination currency;

•conversion timestamp;

•applied rate if exposed;

•explicit fee if exposed.

Then a separate rate-analysis process can compare the actual conversion with a defensible benchmark.

If an ECB reference rate is used for a relevant EUR pair, remember that the ECB describes its rates as informational reference rates rather than transaction execution rates.

The dedicated comparison article should own the full benchmark methodology.

How much does presentment-to-settlement FX cost?

There is no universal answer.

The cost depends on:

•currency pair;

•provider;

•merchant contract;

•conversion stage;

•amount;

•rate timing;

•explicit fees;

•embedded rate methodology;

•market conditions.

The article should not publish a fabricated “typical settlement FX fee.”

Instead, calculate merchant-specific effective cost from the actual transaction-to-settlement amounts.

Presentment-to-settlement effective cost model

Suppose the transaction is:

€100,000

and the settlement is in USD.

For a properly aligned reference benchmark, define:

Rᵦ = benchmark USD per EUR rate

Then:

Benchmark settlement value

€100,000 × Rᵦ

Compare with:

Actual USD settlement after attributable FX charges

The difference is the effective presentment-to-settlement FX cost relative to the chosen benchmark.

Do not include a later USD→GBP payout conversion in this calculation.

That second event belongs to the payout layer.

This separation is explicitly required by the brief.

What if presentment and settlement currencies match?

Then settlement FX is not the obvious source of merchant conversion cost.

Investigate later layers.

For example:

Transaction EUR

Settlement EUR

Balance EUR

Payout USD

The merchant's conversion occurs at payout.

The payment was not converted at settlement.

This distinction is critical when negotiating with providers because the relevant commercial term may belong to an entirely different product or stage.

What if payout and settlement currencies also match?

Consider:

Transaction EUR

Settlement EUR

Payout EUR

There may be no provider-side merchant currency conversion through that path.

But the merchant could still later:

•convert EUR through its bank;

•hold EUR while reporting economically in USD;

•have customer-side FX.

Those are different issues.

The currency-flow model tells the merchant where not to look as well as where to look.

I’ve followed the new structural direction explicitly: this article uses a single three-layer transaction trace, not an A/B comparison, and it closes with merchant scenarios rather than another FAQ or “Final Recommendation.” That variation is now part of the controlling brief.

The change in format should also help the cluster avoid the sameness you flagged: this piece begins as a reconciliation mystery, develops into a currency-lineage architecture, and ends in six diagnostic merchant scenarios rather than another provider comparison, FAQ, or generic closing recommendation.

Presentment vs Settlement Currency — Editorial, SEO and Publication Package

•Editorial interpretation

Article: Presentment vs Settlement Currency

Working title: Presentment vs Settlement Currency: Where Merchant FX Costs Begin

Search intent: technical explanation of payment currency layers from the merchant-cost perspective.

Primary merchant problem: the merchant stores or reports “payment currency” as if it were one thing. In reality, the customer-facing transaction currency, processing currency, settlement currency, merchant balance currency, and payout currency can differ.

When those layers are collapsed into one field, the merchant can no longer answer:

•where currency conversion occurred;

•which party converted it;

•which rate was used;

•whether settlement generated FX;

•whether payout generated another conversion;

•which FX cost belongs to which stage.

Article-owned FX problem

This article owns the currency-layer architecture that determines where merchant FX can enter the flow.

It does not own:

•detailed spread mathematics;

•full PSP-rate comparison;

•multi-currency balance strategy;

•double-conversion remediation;

•treasury exposure management.

Those belong to adjacent Foreign Exchange articles.

Source currency

The primary trace begins with EUR.

Destination currency

The merchant is initially settled in USD.

Potential conversion stages

•transaction/processing;

•presentment-to-settlement;

•settlement-to-balance if distinct;

•balance-to-payout.

Unique evidence anchor

The customer can complete a €100 purchase while the merchant receives dollars.

The brief deliberately expresses that as three observable amounts:

Checkout: €100

Settlement report: $107

Merchant bank: $106.70

Three amounts. Three layers.

Unique thesis

Presentment and settlement currency are separate economic decisions. Supporting a customer currency does not determine the currency in which the merchant ultimately retains or receives the proceeds.

Editorial position

Merchants should store and report presentment, processing, settlement, balance, and payout currencies as separate fields wherever those layers exist.

Common assumption challenged

“If we accept EUR, we receive EUR.”

Merchant decision

The merchant needs to determine whether each currency change is:

•required by the payment method/acquiring setup;

•imposed by its settlement configuration;

•created by its bank-account structure;

•or avoidable through a different settlement or payout arrangement.

Selected format

Currency-layer flow explainer.

The brief specifically assigns this article ownership of presentment, settlement, balance, payout, conversion point, rate timing, and reporting.

•Proposed architecture

•One sale, three currency records

•What is presentment currency?

•What is transaction currency?

•Display currency vs presentment currency

•What is processing currency?

•What is settlement currency?

•What is merchant balance currency?

•What is payout currency?

•Where FX enters the flow

•Presentment-to-Settlement Currency Flow

•When settlement currency matches presentment

•When settlement currency differs

•Why local-currency checkout does not guarantee local-currency settlement

•Settlement FX vs payout FX

•Rate timing

•Reporting architecture

•Measurement model

•Merchant scenarios

This preserves the brief's transaction trace while making the search path progressively answer the terminology people actually need.

Second, individual payment methods can have defined processing currencies; current examples include CAD for Interac and EUR for MyBank, while card processing currencies depend on acquiring banks.

Together, those sources support a careful editorial point:

Transaction support, method processing currency, and payout currency are related but distinct capabilities.

They do not establish:

•universal same-currency settlement;

•universal multi-currency balances;

•one FX rate methodology;

•one settlement conversion rule;

•one merchant configuration.

The Presentment-to-Settlement Currency Flow

Use this as the article's primary visual and operating model.

CUSTOMER / STORE

Display amount + currency

│

▼

PAYMENT

Transaction / presentment

amount + currency

│

▼

PAYMENT METHOD / ACQUIRING

Processing currency

where relevant

│

│

├── Does currency change here?

│

▼

SETTLEMENT

Settlement amount + currency

│

│

├── Does currency change here?

│

▼

MERCHANT BALANCE

Balance amount + currency

│

│

├── Does currency change here?

│

▼

PAYOUT

Bank receipt + currency

│

▼

MERCHANT ECONOMIC / REPORTING CURRENCY

At every currency-changing arrow record:

Source currency

Source amount

Destination currency

Destination amount

Converting party

Conversion timestamp

Applied rate

Explicit fee

A settlement-currency control table

Payments, finance, engineering, and treasury should be able to produce this table for every material payment flow.

Question

Required answer

What did the customer see?

Display currency

What was submitted for payment?

Transaction/presentment currency

What did the method/acquirer process?

Processing currency

What did the provider settle?

Settlement currency

What currency did the merchant hold?

Balance currency

What reached the bank?

Payout currency

Which transitions changed currency?

FX events

Who priced each conversion?

PSP/acquirer/bank/etc.

When was the rate fixed?

Timestamp/event

What did the conversion cost?

Separate FX analysis

If a material row is unknown:

do not infer it.

Mark it for provider verification.

•Measurement framework

Presented volume by currency

Track value and transaction count separately.

Settled volume by currency

Do not derive this from presentment.

Use settlement records.

Presentment-to-settlement mismatch rate

A useful operational metric:

transactions with transaction currency ≠ settlement currency

÷ relevant settled transactions

A value-based version can also be built after converting currencies consistently for aggregation.

Settlement FX volume

The economic value subjected to a transaction/processing-to-settlement conversion.

Payout-conversion volume

Value subjected to a later balance-to-payout conversion.

Effective FX cost by pair

Examples:

•EUR→USD

•CAD→USD

•GBP→EUR

FX cost per successfully settled payment

Where direct attribution is possible:

attributable settlement FX cost

÷ successfully settled converted payments

Double-conversion share

Track flows containing two merchant-side currency conversions.

•Original practical asset: Currency Lineage Record

For engineering/data implementation:

payment_id

display_amount

display_currency

transaction_amount

transaction_currency

processing_currency

settlement_amount

settlement_currency

settlement_timestamp

balance_amount

balance_currency

payout_amount

payout_currency

payout_timestamp

fx_event_1_source

fx_event_1_destination

fx_event_1_rate

fx_event_1_timestamp

fx_event_1_fee

fx_event_2_source

fx_event_2_destination

fx_event_2_rate

fx_event_2_timestamp

fx_event_2_fee

payment_method

acquirer

merchant_entity

mid

provider

The model's purpose is not to force every provider into identical terminology.

It is to preserve economic lineage.

•SEO metadata

Presentment vs Settlement Currency: Merchant FX Guide

Alternative:

Presentment vs Settlement Currency: Where FX Costs Begin

H1

Presentment vs Settlement Currency: Where Merchant FX Costs Begin

Meta description

Learn the difference between presentment and settlement currency, where payment FX occurs, how payout currency differs, and what merchants should track to measure conversion costs.

URL slug

/solve/payments-cost-too-much/foreign-exchange/presentment-vs-settlement-currency/

presentment vs settlement currency

Secondary keywords

•presentment currency

•settlement currency

•transaction currency vs settlement currency

•merchant settlement currency

•payment currency conversion

•payment settlement FX

•cross currency settlement

•presentment settlement difference

These match the brief's assigned query territory.

Related entities

•transaction currency

•display currency

•processing currency

•merchant balance

•payout currency

•FX conversion

•settlement

•payment service provider

•acquirer

•exchange rate

•multi-currency settlement

•double conversion

•merchant reconciliation

•treasury

Article excerpt

A customer can pay in EUR while the merchant settles in USD and receives a different final amount at the bank. Presentment, processing, settlement, balance, and payout currencies are separate layers—and the gaps between them show where merchant FX can begin.

Suggested structured data

•Article

•BreadcrumbList

•visible author and reviewer fields;

•published and last-reviewed dates.

•Search-intent coverage

Search intent

Section

presentment vs settlement currency

Opening definitions

what is presentment currency

Presentment section

what is settlement currency

Settlement section

transaction currency vs settlement currency

Currency-path explanation

merchant settlement currency

Settlement/balance sections

local currency vs settlement currency

Localization section

payment settlement FX

FX-event section

does accepting EUR mean settling EUR

Explicit assumption challenge

payout currency vs settlement currency

Payout section

processing currency meaning

Processing-currency section

cross currency settlement

Mismatch scenarios

where does payment FX happen

Flow diagram

how to track settlement currency

Data architecture

how to calculate settlement FX

Effective-cost model

•Internal-link architecture

The brief names four priority links.

Currency & Pricing: Presentment vs Settlement Currency

Because that adjacent cluster owns the deeper customer-facing/local-pricing implications.

Suggested anchor:

customer-facing presentment currency

Multi-Currency Settlement and FX Costs

Link from the section on retaining currencies.

Suggested anchors:

•multi-currency settlement

•settle payments without immediate conversion

Avoiding Double Currency Conversion

Link from:

EUR → USD → GBP

Suggested anchor:

avoid double currency conversion

How PSP Foreign-Exchange Fees Work

Link when introducing:

•spreads;

•embedded markup;

•benchmark measurement.

Suggested anchor:

how PSP FX fees work

Additional useful links:

•How to Compare PSP Exchange Rates

•Managing Payment FX Exposure

•Currency Conversion for Refunds

•Supporting visual

Presentment-to-Settlement Currency Flow

Use a horizontal/vertical flow rather than another fee stack:

STORE

€100 displayed

│

▼

CHECKOUT

€100 submitted

│

▼

PAYMENT METHOD

EUR processing

│

│ FX?

▼

SETTLEMENT

$107 credited

│

▼

BALANCE

$107 held

│

│ FX?

▼

PAYOUT

$106.70 received

Call out visually:

Currency change ≠ amount change.

Alt text

Diagram tracing a €100 customer transaction through presentment, processing, USD settlement, merchant balance, and bank payout to show where payment currency conversion can occur.

•Authoritative source recommendations

Merchant transaction records

Best source for:

•actual transaction currency;

•customer-facing amount;

•payment method;

•transaction timestamp.

PSP settlement reports

Best source for:

•settlement amount;

•settlement currency;

•settlement date;

•provider FX details where exposed.

Payout/bank records

Best source for:

•payout amount;

•payout currency;

•receiving account;

•downstream charges.

Provider contracts and fee schedules

Required for:

•conversion methodology;

•explicit FX fee;

•settlement-currency eligibility;

•rate timing.

Use current first-party documentation to verify:

•transaction currency support;

•method-specific processing currency;

•payout currencies and current conditions;

•available payment/revenue currency fields in merchant integration/reporting interfaces.

European Central Bank

Use only where a defensible public EUR reference rate is analytically appropriate, while making clear that ECB reference rates are informational rather than executable transaction rates.

•Proposed author and reviewers

Proposed author:

Do not invent a name.

Recommended reviewers:

•payments architect;

•settlement expert;

•treasury reviewer.

Those roles are specified by the brief.

Additional useful review:

•merchant finance;

•payments pricing;

•data engineering.

Highest-value first-hand contribution

Add an approved anonymized transaction lineage from:

checkout → payment method → settlement → merchant balance → payout

showing real currencies at each stage, but not confidential rates unless approved.

This article benefits more from an authentic currency-path trace than from a generic PSP fee statistic.

•FX-rate fact-check

For every conversion example verify:

•source currency;

•destination currency;

•rate direction;

•applied rate;

•conversion timestamp;

•benchmark timestamp;

•explicit fee;

•conversion stage.

Do not calculate an apparent spread from transaction time if the provider actually converts at settlement.

•Provider-pricing fact-check

Before stating that a provider “charges FX” at a particular stage, verify:

•merchant agreement;

•fee schedule;

•product;

•payment method;

•settlement arrangement;

•rate methodology;

•merchant tier.

Do not infer provider FX pricing merely because transaction and settlement currencies differ.

The conversion could involve another participant.

•Settlement/payout fact-check

For each major merchant flow identify:

Settlement

•transaction currency;

•processing currency;

•settlement currency;

•conversion stage;

•conversion party;

•settlement timestamp.

Balance

•balance currency;

•whether multiple balances exist.

Payout

•payout currency;

•bank-account currency;

•payout conversion;

•bank conversion, if any.

Keep all three layers separate.

•Double-conversion fact-check

When the currency sequence is:

A → B → C

verify:

•why B exists;

•whether both conversions occur;

•rate and fee at each;

•whether A→C is supported;

•operational implications of changing the route.

This article should identify the pattern.

The dedicated double-conversion article should own remediation.

•Refund fact-check

Preserve:

•original transaction currency;

•settlement currency;

•balance currency;

•refund currency;

•funding currency.

Without those data, later refund FX cannot be reconstructed reliably.

•Market/currency fact-check

Verify market-specific:

•payment method;

•processing currency;

•settlement support;

•payout support;

•banking requirements;

•provider configuration;

•current currency restrictions where applicable.

Never treat a provider's global supported-currency list as proof of same-currency settlement everywhere.

•Treasury/regulatory boundary

Currency architecture can intersect with:

•local banking rules;

•exchange controls;

•entity ownership;

•settlement restrictions;

•treasury policy;

•accounting treatment.

Do not give legal, tax, investment, accounting, or speculative FX advice.

Information notice: This article provides general information and does not constitute legal, tax, accounting, investment, treasury, or financial advice. Merchants should verify provider arrangements, currency restrictions, settlement requirements, and accounting treatment with qualified advisers and relevant financial partners.

•Amber-flag claims

“Presentment currency is the customer's home currency.”

Do not assume.

The customer can be presented a currency different from their account currency.

“Presentment currency always equals transaction currency.”

Avoid as a universal provider definition.

Define terminology in context.

“If we accept EUR, we settle EUR.”

False as a general assumption.

“Supported currency means settlement currency.”

Do not publish.

“Settlement is the amount that reaches the bank.”

Not necessarily.

Settlement/balance and payout are separate layers.

“A smaller payout proves FX was charged.”

Wrong.

If the currencies are unchanged, other commercial adjustments may explain the amount difference.

“Different presentment and settlement currencies mean the PSP took a spread of X%.”

Incomplete.

Identify actual conversion party, rate and timestamp first.

“The checkout exchange rate is the settlement rate.”

Do not assume.

Not established by the reviewed public documentation.

Do not publish without internal evidence.

Requires current internal verification before publication.

Public documentation currently establishes:

•a broad supported transaction-currency list;

•method-specific processing currencies for individual methods;

•card processing currencies depending on acquiring banks;

•multiple named payout currencies under stated conditions;

•distinct payment/revenue currency fields in pingback reporting.

Before publication, internally verify:

•settlement currency by product/payment method;

•whether settlement and balance currencies are distinct in current architecture;

•merchant balance currencies supported;

•automatic-conversion behavior;

•FX conversion party;

•rate-setting event;

•FX rate methodology;

•explicit FX fees;

•same-currency payout rules;

•bank-account denomination requirements by market;

•multi-currency balance availability;

•refund currency flow;

•reporting/export fields merchants can access;

•approved screenshots or product diagrams.

•Cluster sameness audit

Field

Presentment vs Settlement Currency

Opening device

Three records: €100 checkout, $107 settlement, $106.70 bank receipt

Source currency

EUR

Destination currency

USD

Primary conversion stage

Transaction/processing → settlement

Primary format

Currency-layer flow explainer

Unique evidence anchor

Customer pays EUR while merchant receives USD

Editorial position

Track currency layers separately

Common assumption

Accepting EUR means receiving EUR

Original framework

Presentment-to-Settlement Currency Flow

Primary metric

Presentment-to-settlement mismatch / converted share

Merchant decision

Which currency change is causing merchant FX?

Closing device

Merchant scenarios rather than FAQ/recommendation

The page owns currency-layer architecture, not spread mechanics, provider comparison, double-conversion strategy, or treasury exposure.

•Merchant scenarios: what the currency path is telling you

Rather than close with another generic recommendation, use these scenarios as the merchant decision test.

Scenario 1: customer pays EUR, merchant settles EUR, bank receives EUR

EUR → EUR → EUR

There is no visible merchant-side currency change in the mapped payment-to-payout path.

Investigate: ordinary processing and settlement economics, not settlement FX.

Do not assume: the customer had no customer-side FX or that the merchant has no later treasury exposure.

Scenario 2: customer pays EUR, merchant settles USD, bank receives USD

EUR → USD → USD

The key FX event is before or at settlement.

Investigate:

•converting participant;

•EUR→USD rate;

•rate timestamp;

•explicit conversion fee;

•whether EUR settlement is available.

The payout stage does not show another currency conversion.

Scenario 3: customer pays EUR, merchant settles EUR, bank receives GBP

EUR → EUR → GBP

The payment itself remains in EUR through settlement.

Merchant FX enters at payout.

Investigate:

•GBP payout requirement;

•receiving bank denomination;

•payout conversion rate;

•whether an EUR account would be operationally appropriate.

Do not attribute this cost to presentment-to-settlement FX.

Scenario 4: customer pays EUR, merchant settles USD, bank receives GBP

EUR → USD → GBP

Two conversions potentially exist.

This is the highest-priority diagnostic for the Avoiding Double Currency Conversion article.

Investigate:

•why USD is intermediate;

•cost of EUR→USD;

•cost of USD→GBP;

•whether a direct or retained-currency path is available;

•operational cost of changing it.

Scenario 5: customer pays EUR, settlement and payout remain EUR, merchant reports in USD

Payment flow: EUR → EUR → EUR

Reporting layer: EUR → USD equivalent

Do not automatically call the reporting translation a PSP FX fee.

The merchant may still have economic FX exposure, but it has not necessarily converted the payment proceeds.

This belongs primarily to Managing Payment FX Exposure.

Scenario 6: €100 checkout, $107 settlement, $106.70 USD bank receipt

EUR → USD → USD

One visible currency change.

One later amount change without a currency change.

Therefore the audit should split:

FX investigation: EUR→USD settlement.

Payout/reconciliation investigation: $107→$106.70.

That separation is the article's core analytical lesson.

•Publication status

Research refreshed: 15 August 2026.

Editorially ready: Yes.

SEO architecture ready: Yes.

The page is ready to publish at the conceptual level because its central claim does not depend on a provider rate:

Presentment, processing, settlement, balance, and payout currency describe different stages of a payment. A merchant that stores them separately can see exactly where currency changes—and therefore where merchant FX cost can begin.

That is the distinct job of this article inside the Foreign Exchange cluster.