Presentment Currency vs Settlement Currency

Presentment Currency vs Settlement Currency: How Payment Currency Layers Fit Together

A customer pays:

€120.

The merchant's reporting system shows:

$128.43.

The bank account eventually receives:

$126.90.

Those numbers are illustrative, not live exchange-rate examples.

But the operational question is real:

Where did each number come from?

If the merchant stores only one field called payment_currency, the answer may be impossible to reconstruct.

The €120 might be the transaction or presentment amount the customer authorized.

The $128.43 might be a reporting equivalent, a settlement amount or an internally converted accounting value.

The $126.90 might be a net payout after conversion, fees or other adjustments.

Without preserving the intervening currency layers, none of those interpretations can be proven from the amounts alone.

That is the central distinction in presentment currency vs settlement currency:

the currency used to create the customer's payment obligation is not necessarily the currency in which the merchant ultimately receives economic value.

Stop treating “payment currency” as one field

A mature multi-currency payment architecture can contain at least eight relevant layers:

•Catalog/pricing currency

•Display currency

•Transaction or presentment currency

•Customer account/billing currency

•Processing currency, where relevant

•Settlement currency

•Merchant balance currency

•Payout currency

Sometimes all eight resolve to the same ISO currency.

Sometimes they do not.

The mistake is not having multiple currencies.

The mistake is having multiple currencies without knowing which amount belongs to which layer.

The cluster brief requires these distinctions explicitly and makes currency-layer architecture the territory of this article.

Layer 1: catalog currency

The catalog currency is the merchant's pricing source of truth.

Suppose a software merchant maintains its core catalog in USD:

Professional plan: USD 120

That does not necessarily determine what a German shopper sees or what the payment transaction eventually uses.

The merchant could:

•continue displaying USD 120;

•convert it to a live or periodically updated EUR amount;

•maintain a deliberately fixed EUR price;

•or use a separate market-specific price book.

Those are pricing decisions.

They belong upstream of payment processing.

The key architectural rule is to preserve the original commercial source:

catalog amount = 120

catalog currency = USD

even when another price is ultimately presented.

This lets finance later distinguish price localization from payment FX.

Layer 2: display currency

The display currency is what the customer sees.

It could be:

€109

even when the underlying catalog is maintained in USD.

But display currency alone tells us almost nothing about the actual payment.

There are two very different designs.

Local-currency display only

The merchant shows:

Approximately €109

but creates the payment for:

USD 120

The EUR amount is informational.

Local-currency transaction

The merchant shows:

€109

and submits:

EUR 109

to the payment provider.

Now EUR is not merely display currency. It is also the transaction/presentment currency.

The distinction is mandatory because an approximate local display does not create the same customer, processor or FX outcome as an actual local-currency charge.

A merchant should therefore avoid storing:

currency = EUR

simply because the product page displayed euros.

Store:

display_amount

display_currency

and separately:

transaction_amount

transaction_currency

Layer 3: transaction or presentment currency

For this article, presentment currency means the currency in which the payment amount is actually presented/submitted into the relevant payment transaction.

A shopper could therefore authorize:

€120

even when the merchant's accounting base currency is USD.

That transaction currency should be preserved as an original financial fact.

Do not overwrite it later with:

•reporting currency;

•settlement currency;

•merchant base currency;

•or payout currency.

If the customer paid EUR 120, finance should still be able to answer months later:

Original transaction amount: EUR 120

even if every internal management report is displayed in USD.

Layer 4: customer account or billing currency

The transaction currency still may not be the currency of the customer's underlying account.

Consider:

Merchant transaction: EUR 120

Customer card account: GBP

The payment may therefore trigger another conversion somewhere in the card/payment chain.

Visa's current foreign-exchange documentation explicitly distinguishes a transaction currency and amount from a cardholder billing currency and amount. Its Enhanced FX API accepts those as different currency concepts and returns relevant conversion information.

That is a useful network-level example of why:

presentment currency ≠ customer home/account currency.

The merchant may know the currency it charged.

It may not always know the final amount the customer's issuer places on the statement after all issuer-controlled conversion or fees.

Therefore, avoid promising:

“You will pay exactly £X.”

when the merchant is actually submitting a EUR transaction and the final GBP billing economics are controlled elsewhere.

A customer can pay “in EUR” and still experience FX

This is one of the most counterintuitive consequences.

A checkout saying:

Pay €120

does not prove that no customer-side currency conversion occurs.

If the customer's account is denominated in another currency, another participant can still convert the EUR transaction.

Likewise, charging a customer in their apparent “local currency” does not guarantee the issuer will impose no foreign-transaction-related charge. The brief explicitly warns merchants not to promise zero issuer fees from local-currency charging alone.

The merchant controls its own transaction currency.

It does not universally control the economics of the customer's financial account.

Layer 5: processing currency

“Processing currency” can be provider- or payment-method-specific terminology.

The safest approach is not to invent a universal network definition but to record the currency actually required or used by the applicable processing route when that layer exists.

That means a currency appearing on a platform-level supported-currency list does not establish that:

every payment method supports transactions in that currency.

For merchants, the rule is:

currency capability must be evaluated at the payment-method and acquiring-route level, not merely at the platform level.

Currency choice can therefore change method availability

Imagine the checkout offers:

USD

EUR

PLN

The customer chooses PLN.

A local Polish method may become available.

Another payment method may disappear because it cannot process PLN through the merchant's configured route.

That is not necessarily a checkout defect.

It can be a consequence of method-currency compatibility.

Therefore the merchant's routing logic should ask:

Does this payment method support this transaction currency for this merchant, market and provider configuration?

before displaying it.

The brief specifically requires merchants to verify payment method, provider, merchant account, acquirer, country and transaction type before assuming currency compatibility.

Layer 6: settlement currency

Now move to the merchant side.

Settlement currency concerns the currency in which transaction value is settled into the merchant's relevant PSP/acquirer settlement position or balance.

This can be the same as the presentment currency.

It does not have to be.

Suppose:

Customer transaction: EUR 120

but the merchant agreement settles that payment economically into a:

USD balance

An FX conversion must occur somewhere between those states.

The key questions are:

•Who performs the conversion?

•At what stage?

•Which rate applies?

•At what timestamp?

•Is there an FX spread or explicit fee?

•Does the merchant have a choice?

•Can the merchant instead maintain EUR settlement?

Without those answers, “we accept EUR” does not describe the merchant's FX economics.

Presentment and settlement solve different problems

Presentment currency primarily answers:

What monetary obligation did the customer authorize?

Settlement currency answers:

In which currency is the transaction value recognized or delivered into the merchant-side settlement arrangement?

Therefore:

EUR presentment + EUR settlement

is one configuration.

EUR presentment + USD settlement

is another.

Both can result in the same customer experience.

They create different treasury and FX economics for the merchant.

This is why local-currency checkout should not be advertised internally as “local settlement” unless the settlement layer is actually configured that way.

Layer 7: merchant balance currency

For PSPs and platforms that maintain merchant balances, settlement into a merchant balance and transfer to the merchant's bank may be separate events.

That creates another useful layer:

merchant balance currency.

The merchant can have economic value recognized in a platform account before a later bank payout occurs.

This is why the shorthand:

“settled = in our bank”

can be operationally dangerous.

provider/merchant balance

and:

external bank payout.

Layer 8: payout currency

Payout is the final movement into the merchant's nominated receiving account.

The payout currency can therefore be another field.

The editorially important point is not that historical list.

It is the layer:

settlement currency does not automatically equal bank payout currency.

If a provider balance is maintained in EUR and the merchant ultimately requests USD into its bank, a further conversion may occur at or before payout.

That is economically different from converting each underlying EUR customer payment into USD at transaction settlement.

Settlement and payout are also different in time

Currency is only half the problem.

Timing matters because FX rates move.

A transaction might be:

authorized Tuesday

settled Wednesday

included in payout Friday

If conversion occurs Tuesday, the economic result may differ from a design in which the currency remains unchanged through settlement and is converted only on Friday.

The exact contractual timing depends on the account and payment method.

But the merchant system should preserve both:

currency event

and:

currency-event timestamp.

One payment can contain several different FX events

There is no single universal point called:

“the FX conversion.”

Consider four architectures.

Architecture A: merchant converts the price before payment

Base catalog:

USD 100

Merchant pricing engine derives:

EUR 92

Customer is charged:

EUR 92

Merchant eventually settles:

EUR 92

The first conversion is a pricing decision.

It may not be a transaction-level funds conversion at all.

The merchant simply decided to create a EUR-denominated price.

Architecture B: issuer converts customer transaction

Customer is charged:

EUR 92

Customer account:

GBP

Merchant receives/settles:

EUR

The merchant may experience no transaction-side EUR→GBP conversion.

The customer or issuer side does.

Architecture C: provider converts settlement

Customer is charged:

EUR 92

Merchant settlement:

USD

Now the merchant-side payment flow contains a EUR→USD conversion.

Architecture D: merchant holds EUR, converts at payout/treasury stage

Customer is charged:

EUR 92

Merchant balance:

EUR

Later merchant payout:

USD

The conversion moved downstream.

These architectures can look identical to the shopper.

They are financially different to the merchant.

Transaction FX and treasury FX should not be conflated

This distinction is especially important for finance teams.

Transaction FX

Conversion attached to an individual payment-processing or settlement event.

Example:

EUR customer transaction

→ USD merchant settlement

Treasury FX

Conversion of merchant-held balances or funds after transaction settlement.

Example:

EUR merchant balance

→ merchant deliberately converts accumulated EUR

→ USD bank or treasury position

The same EUR→USD currency pair can appear in both examples.

But the party, timing, rate, fee and risk decision are different.

A merchant that collapses both into “FX cost” will struggle to determine whether the cost comes from payment configuration or treasury strategy.

Customer FX exposure and merchant FX exposure are separate

Consider:

Transaction currency: EUR

Customer account currency: GBP

Merchant settlement currency: USD

One transaction can create FX exposure on both sides.

The customer's financial institution may convert:

EUR → GBP

while the merchant's settlement provider converts:

EUR → USD

The customer and merchant are not sharing one FX event.

They are exposed to separate conversion relationships.

The merchant should therefore document:

Customer side

•transaction currency;

•known account/billing currency where lawfully available;

•likely converting party;

•disclosed conversion;

•issuer-controlled uncertainty.

Merchant side

•transaction currency;

•settlement currency;

•conversion provider;

•settlement rate;

•settlement fee/spread;

•payout currency;

•further treasury conversion.

Without that separation, customer-support and finance teams can end up investigating two unrelated currency differences as if they were one.

Never use “the exchange rate” without naming the rate

Visa's current FX documentation provides a useful illustration. Visa exposes Visa conversion rates and also allows comparison with benchmark rates such as ECB reference rates. Its API documentation specifically notes that an indicative rate may differ from the actual transaction settlement outcome.

So a merchant discussing FX should identify:

Which rate?

Possibilities include:

•merchant pricing rate;

•provider conversion rate;

•card-network rate;

•issuer rate;

•DCC rate;

•treasury rate;

•public benchmark/reference rate.

And then:

At what time?

A number without those qualifiers is not an auditable FX policy.

The Payment Currency Layer Map

The practical solution is to model the entire transaction as a sequence.

Layer

Example field

Core question

•Catalog price

catalog_amount, catalog_currency

In which currency did the merchant define economic price?

•Display

display_amount, display_currency

What price did the customer see?

•Transaction/presentment

transaction_amount, transaction_currency

What amount and currency did the customer actually authorize?

•Customer account

billing_currency, where available

In what currency does the customer's financial account record the payment?

•Processing

processing_currency

What currency does the selected processing route require/use?

•Settlement

settlement_amount, settlement_currency

In what currency does the provider/acquirer settle transaction value merchant-side?

•Merchant balance

balance_amount, balance_currency

In what currency is value held/recorded before external payout?

•Payout

payout_amount, payout_currency

What does the merchant's receiving bank actually get?

For every conversion, add:

•source amount;

•source currency;

•destination amount;

•destination currency;

•conversion rate;

•rate type/source;

•converting party;

•conversion timestamp;

•explicit FX fee if applicable;

•spread/markup if known and separately reportable;

•related transaction or payout ID.

That is the article's core framework. The brief specifically requires the map to preserve amount, rate, converting party, timestamp and fee at each relevant layer.

Do not manufacture a customer billing currency

Not every merchant will have reliable access to the customer's true account currency.

Do not infer it mechanically from:

•IP address;

•browser language;

•shipping country;

•nationality;

•or the currency the customer selected.

A French resident can use a USD account.

A British customer can hold EUR.

A traveler can intentionally choose another currency.

If the billing/account currency is unavailable, record it as unavailable.

Do not turn a localization guess into financial truth.

Reporting should preserve originals and derived equivalents

Suppose a merchant's management reporting is in USD.

A EUR transaction might therefore be displayed internally as:

Original transaction: EUR 120

Management reporting equivalent: USD 128.43

That USD value should not replace the original EUR amount.

A useful reporting model preserves both:

Original transaction facts

•transaction ID;

•EUR 120;

•transaction date;

•payment method.

Derived reporting facts

•USD reporting equivalent;

•chosen accounting/reporting rate;

•rate date;

•conversion methodology.

Actual settlement facts

•settlement amount;

•settlement currency;

•fees;

•actual provider conversion if any.

This prevents a management-reporting conversion from being mistaken for actual payment FX.

The brief explicitly requires merchants to preserve original transaction amounts alongside base/reporting-currency equivalents.

Why $128.43 and $126.90 cannot be explained from the totals alone

Return to the opening.

Customer paid: EUR 120

Reporting: USD 128.43

Bank received: USD 126.90

A weak accounting system might label the difference:

“FX loss: $1.53.”

That conclusion is not justified.

The difference could include:

•payment processing fees;

•an FX conversion;

•provider commission;

•refund or chargeback adjustment;

•reserve movement;

•payout/remittance cost;

•different conversion timestamps;

•or unrelated transactions included in a batch payout.

Therefore:

bank payout difference ≠ automatically FX cost.

The ledger needs to identify each component.

Reconciliation should work from transaction to payout

A multi-currency reconciliation chain should look like:

Order price

→ transaction amount/currency

→ payment ID

→ processing route/currency

→ provider fees

→ FX conversion event, if any

→ settlement amount/currency

→ merchant balance

→ payout batch

→ payout amount/currency

→ bank receipt

→ refund/adjustment where relevant

Each step should have a stable identifier.

Finance should be able to ask:

Which EUR transactions produced this USD payout?

and receive a deterministic answer.

Not:

“Approximately these orders after exchange rates.”

Batch payouts make transaction lineage even more important

A bank payout can contain many transactions.

They may have occurred on different days.

They may include:

•several transaction currencies;

•different payment methods;

•different settlement dates;

•refunds;

•fees;

•chargebacks;

•reserves;

•corrections.

That makes it especially dangerous to derive transaction FX by comparing one gross sales figure directly with one bank-transfer amount.

Reconcile bottom-up.

Multi-currency settlement can reduce one conversion and create another treasury decision

Suppose a merchant has meaningful EUR revenue and EUR operating costs.

If its provider can settle and pay it in EUR, the merchant may avoid converting every incoming EUR transaction into USD.

That can reduce one category of transaction-level FX.

But it creates a treasury question:

Do we hold EUR?

Spend EUR?

Convert EUR later?

When?

Through whom?

Those broader balance-management decisions belong in the settlement/treasury cluster.

This article only needs to establish the boundary:

keeping transaction currency through settlement transfers the conversion decision downstream; it does not make currency risk disappear.

Choosing settlement currencies should follow economic flows

A merchant should not select settlement currencies merely because it can.

Useful questions include:

•What share of transaction value is presented in this currency?

•Do we have costs or liabilities in the same currency?

•Do we have an eligible bank account?

•What does the provider charge to settle or convert it?

•What does an external bank charge?

•How volatile is the exposure relative to our margin?

•How much operational complexity does another balance introduce?

•Do refunds need access to the original transaction currency?

•Is the volume large enough to justify another settlement position?

The detailed treasury decision belongs elsewhere.

But the currency-layer map supplies the data treasury needs to make it.

Local-currency presentment is not local acquiring

Another frequent architecture error is:

“We charge BRL, therefore this transaction is locally acquired in Brazil.”

That does not follow.

A merchant can present locally and process cross-border.

Or present locally and acquire locally.

Those are separate dimensions.

The brief explicitly reserves domestic acquiring economics for the Local Acquiring cluster and prohibits equating local-currency pricing with local acquiring.

Keep separate fields for:

transaction currency

acquirer/route

merchant entity

settlement currency

DCC introduces another decision, not another synonym

Dynamic Currency Conversion should also stay separate.

Merchant local-currency pricing determines the transaction price upstream.

DCC, where available and applicable, is a currency-choice/conversion mechanism with its own participant roles, rate disclosure and customer-choice requirements.

So never use:

local-currency pricing

multi-currency pricing

and:

DCC

as interchangeable labels.

The DCC article owns the mechanism in detail; this article only needs to show where it may affect the currency layer chosen for the transaction.

Refunds prove why original currency data must survive

Suppose the original transaction was:

EUR 120

and the merchant reports internally in USD.

Three months later, the customer receives a full refund.

The refund logic should begin from:

original transaction: EUR 120

not:

whatever USD management-reporting equivalent happens to be stored today.

The customer may ultimately see a different home-account amount if another participant performs FX at a different rate at refund time.

That issue belongs in depth in Refunds and Currency Conversion, but it produces an architectural requirement here:

never discard original transaction currency after settlement conversion.

The brief explicitly requires refund systems to distinguish original transaction currency, refund currency, merchant settlement currency, customer account currency and purchase/refund FX timing.

Subscriptions make currency lineage persistent

A one-time purchase creates one transaction-currency decision.

A subscription creates a policy.

A subscriber might sign up at:

€19.99/month

while the merchant maintains its master catalog in USD and settles into another currency.

The system now needs to know whether €19.99 is:

•a fixed contractual/local price;

•periodically recalculated from USD;

•or a migrated price subject to another rule.

That belongs primarily in Subscription Billing in Multiple Currencies.

But again the architecture requirement is clear:

signup currency, renewal transaction currency, settlement currency and reporting currency must not collapse into one field.

The brief makes this distinction explicit.

Transaction currency

Brick's charge API takes an explicit amount and currency.

Platform-supported currency reference

Processing currency

Merchant balances and payout

Payout currency

Net payout

Together, these sources support the article's main principle:

Obtain current Product, Finance/Treasury and Payment Operations confirmation for:

•supported transaction/presentment currencies;

•card acquiring currency support by route;

•local-method processing currencies;

•merchant balance currencies;

•settlement currencies;

•payout currencies;

•bank-account requirements;

•automatic conversion rules;

•rate source;

•FX spread/fees;

•conversion timestamp;

•multi-currency balances;

•whether merchants choose settlement currency;

•currency-specific payout schedules;

•refund conversion;

•reporting currency behavior;

•reconciliation exports;

•Merchant versus MoR differences;

•entity-specific differences.

Do not turn the current general currency-code reference into a settlement-currency claim.

Merchant architecture decision 1: where should conversion happen?

Every international merchant should be able to draw one line through the Payment Currency Layer Map and mark:

Conversion here.

Potential choices include:

Pricing layer

Merchant converts base catalog into local prices.

Customer/card layer

Merchant keeps transaction in one currency; customer-side provider/issuer handles conversion.

Payment settlement layer

Provider converts transaction currency into merchant settlement currency.

Balance/treasury layer

Merchant retains currency and converts later.

There can also be more than one conversion.

The important thing is to make each one deliberate.

Merchant architecture decision 2: who bears the exposure?

If the merchant sets a fixed EUR price while its costs are USD, the merchant may bear EUR/USD pricing exposure between price updates.

If it immediately converts each EUR settlement to USD, it experiences provider conversion economics.

If it keeps EUR, it carries a EUR balance until it spends or converts it.

If it charges USD instead, some of the conversion experience may move to the customer side.

There is no universally correct allocation.

There is only an allocation that is:

•visible;

•measured;

•operationally supportable;

•and acceptable to the customer and merchant.

Merchant architecture decision 3: what must reporting preserve?

At minimum:

Commercial price

•catalog amount/currency;

•display amount/currency;

•pricing-rule version.

Payment

•final transaction amount/currency;

•payment method;

•processing route;

•processing currency where applicable.

Customer FX, where legitimately available

•billing/account currency;

•relevant known conversion data.

Merchant FX

•settlement amount/currency;

•rate;

•converting party;

•conversion timestamp;

•conversion fee/spread where available.

Balance and payout

•merchant balance currency;

•payout batch;

•payout amount/currency;

•bank account currency.

Adjustments

•refund amount/currency;

•chargeback amount/currency;

•fee currency;

•reserve currency;

•reporting/base-currency equivalent.

A system that stores only:

amount=120

currency=USD

after a EUR transaction has been converted has destroyed useful financial history.

Measurement requirements

The brief calls for transaction volume by currency, FX conversions, settlement mix, payout conversion, reconciliation differences and FX cost.

A useful merchant dashboard should therefore include:

Transaction volume by presentment currency

Value and count of completed transactions grouped by original transaction currency.

Presentment-to-settlement conversion rate

Transactions requiring currency change before merchant settlement

÷ completed transactions

Settlement currency mix

Value settled in each currency

÷ total settled value, converted under a clearly defined reporting methodology.

Payout conversion rate

Payout value requiring conversion from balance/settlement currency into bank payout currency

÷ total payout value

FX cost

Do not calculate this as “difference from Google/spot/mid-market.”

Define:

•reference rate;

•actual applied rate;

•source;

•fee;

•timing;

•currency pair.

Reconciliation exception rate

Multi-currency transactions or payouts requiring manual finance intervention

÷ total relevant transactions/payouts

Currency-related support contacts

Customer or merchant-support cases involving:

•unexpected currency;

•amount mismatch;

•issuer conversion;

•refund difference;

•currency switch;

•payment-method disappearance.

Test architecture changes before measuring conversion

This article does not own the full local-currency conversion experiment, but currency-layer changes can affect far more than shopper behavior.

If a merchant changes from:

USD presentment / USD settlement

to:

EUR presentment / USD settlement

measure:

•checkout completion;

•payment success;

•method availability;

•approval/authorization;

•FX cost;

•gross margin;

•refunds;

•reconciliation;

•customer complaints.

If checkout completion improves but settlement FX cost erodes the commercial benefit, the change should not be reported simply as:

“EUR conversion improved performance.”

Likewise, if a new presentment currency causes important local methods to disappear, the experiment has changed two variables at once.

The Payment Currency Layer Map: implementation checklist

Before production, take five sample transactions from each important market and complete this table with actual data:

Question

Merchant must answer

What was the catalog currency?

What did the customer see?

What amount/currency did they authorize?

What was their account currency, if known?

Which payment route processed it?

What processing currency applied?

Did FX happen before settlement?

Yes / No

Who converted it?

What rate and timestamp applied?

What fee/spread applied?

What currency entered merchant balance?

What amount entered merchant balance?

What currency was paid to the bank?

Did another conversion occur?

Can the bank payout be reconciled to this payment?

Yes / No

If the team cannot fill in the table, it does not yet have reliable multi-currency observability.

Final recommendation

Presentment currency and settlement currency are not competing choices.

They answer different questions.

Presentment currency:

What currency did the customer actually agree to pay?

Customer account currency:

What currency does the customer's financial account ultimately use?

Processing currency:

What currency does the selected payment route require or process?

Settlement currency:

What currency represents the transaction value on the merchant side?

Merchant balance currency:

What currency is the merchant holding before transfer?

Payout currency:

What currency reaches the merchant's bank?

Once those layers are explicit, FX stops looking like an unexplained difference between checkout revenue and bank cash.

The merchant can see:

where conversion happened,

who controlled it,

which rate applied,

who bore the exposure,

and:

which amount should reconcile to which ledger.

That is the real purpose of a multi-currency payment architecture.

Do not optimize it merely so the checkout can display more currency symbols.

Design it so that every customer-facing amount can be traced through processing, settlement and payout without losing its economic meaning.

Original practical asset: Payment Currency Layer Map

Supporting visual

Build the visual horizontally:

Catalog price

USD 130

→

Display currency

EUR 120

→

Transaction / presentment

EUR 120

→

Customer account

GBP — if applicable

→

Processing

EUR

→

Settlement

USD

→

Merchant balance

USD

→

Payout

USD

The amounts are explicitly illustrative.

Between every box, provide an optional FX marker:

Conversion? YES / NO

If yes, display:

•converting party;

•rate source;

•rate timestamp;

•fee/spread.

Under the diagram, add two brackets:

Customer-side FX

Transaction/presentment → customer billing/account

Merchant-side FX

Transaction/processing → settlement → balance → payout

Final callout:

“Currency is a sequence of layers, not one transaction attribute.”

Image alt text

“Payment currency layer diagram tracing a purchase from catalog and display currency through transaction, customer billing, processing, settlement, merchant balance and payout currencies, with FX conversion points identified.”

Technical FAQ

Is presentment currency the currency shown on the product page?

Not necessarily. Display currency can be indicative. Presentment/transaction currency is the currency actually submitted for the payment. The two should be stored separately.

If a merchant charges EUR, will the customer's card statement also be in EUR?

Not necessarily. The customer's account can be denominated in another currency. Visa's current FX documentation, for example, distinguishes transaction currency from cardholder billing currency.

Is settlement currency the same as payout currency?

Not necessarily. Settlement can occur into a merchant/provider balance before a separate bank payout. Exact terminology and mechanics depend on the provider and contract.

Does offering a currency mean every payment method supports it?

Is a difference between gross transaction value and bank payout an FX loss?

The main editorial move is to make currency a data lineage problem. The brief’s anchor is not merely that FX exists; it is that the customer can pay in one currency while the merchant ultimately receives another, with transaction, processing, account, settlement and payout currencies potentially sitting between those two events.

The strongest differentiator here is the opening three-number problem: €120 → $128.43 → $126.90. It gives finance and engineering the same mystery to solve and makes the article’s thesis concrete: without an explicit currency layer map, even a successful payment can become financially opaque.

Editorial package: Presentment Currency vs Settlement Currency

Concise interpretation of the editorial brief

Customer/payment problem: the shopper sees and authorizes one currency, while the merchant's finance team later sees another amount or currency and cannot explain where the change occurred.

Unique evidence anchor: one payment can contain several economically distinct currency layers. The customer-facing transaction currency, the customer's account currency, the processing currency, the merchant settlement currency and the eventual payout currency do not have to be identical.

Editorial position: merchants should treat currency as a sequence of fields and events, not a single currency attribute. Preserve each economically relevant amount, currency, conversion, rate, timestamp and converting party.

Common assumption challenged: “If the customer pays in EUR, the merchant receives EUR.”

Merchant decision: where should the merchant deliberately allow currency conversion, which participant should perform it, which currencies should be preserved through settlement, and where does the resulting FX exposure belong?

Selected format: payment currency layer map.

Structural rationale: the brief explicitly assigns this article ownership of the architecture linking presentment, processing, customer account, settlement, merchant balance and payout currencies rather than customer preference, pricing strategy or DCC mechanics.

SEO metadata

H1: Presentment Currency vs Settlement Currency: How Payment Currency Layers Fit Together

Meta description: Learn how presentment, customer billing, processing, settlement and payout currencies differ, where FX can occur, and how merchants should reconcile multi-currency payments.

URL slug: /solve/customers-cant-pay-their-way/currency-pricing/presentment-currency-vs-settlement-currency/

Secondary keywords: presentment currency; settlement currency; transaction currency vs settlement currency; payment currency explained; merchant settlement currency; card presentment currency; payout currency; multi currency settlement

Related entities: presentment currency; transaction currency; processing currency; cardholder billing currency; settlement currency; payout currency; foreign exchange; acquirer; PSP; merchant balance; treasury

Article excerpt: A customer's payment currency and the merchant's settlement currency can differ. Merchants need to preserve each currency layer—and every conversion between them—to understand FX exposure, reconcile payouts and make reliable multi-currency decisions.

Suggested structured data: Article; add FAQPage only if the technical FAQ remains visible.

Internal-linking plan

Context

Suggested anchor

Target

Deliberate local prices

multi-currency pricing

Multi-Currency Pricing Explained

Merchant currency holdings

multi-currency settlement

Multi-Currency Settlement Explained / Settlement cluster

Choosing what to retain

how to choose settlement currencies

Settlement cluster

Customer conversion choice

dynamic currency conversion

Dynamic Currency Conversion Explained

Refund example

refunds and currency conversion

Refunds and Currency Conversion

Customer FX surprises

unexpected FX charges

How to Prevent Unexpected FX Charges

Acquiring model

local acquiring

Local Acquiring

This article owns the relationships among currency layers; it should link rather than expand into complete treasury, DCC, pricing or refund strategy.

Authoritative source recommendations

Use for the current platform reference list, while separately validating method and merchant-account compatibility.

Use to establish method-specific processing currencies rather than assuming platform-level currency support applies universally.

Use for the explicit amount/currency transaction input.

Use for the distinction between balances/settlement funds and merchant payout, but flag dated support articles when exact operational parameters are cited.

Visa Foreign Exchange / VisaNet documentation

Use as a card-network example of transaction currency versus cardholder billing currency and multiple exchange-rate concepts.

For any Mastercard-, Amex- or country-specific network claim added during editing, obtain equivalent current first-party documentation rather than extrapolating Visa terminology.

Proposed author and reviewers

Recommended reviewers:

•payments architect;

•treasury specialist;

•finance/reconciliation lead;

Best first-hand contribution: one anonymized real reconciliation example showing a single transaction's original currency, settlement conversion and bank payout lineage.

Do not invent the example or reviewer sign-off.

Currency-support fact-check items

Before publication verify:

•Brick card transaction currencies;

•acquirer-specific card currency support;

•local-method processing currencies;

•merchant/MoR differences;

•transaction limits that vary by currency;

•minor units/decimal support;

•unsupported legacy currency codes;

•country restrictions.

Current method pages clearly have method-specific processing constraints.

FX fact-check items

Confirm for the actual merchant configuration:

•conversion stage;

•source currency;

•target currency;

•rate provider;

•reference rate;

•spread;

•explicit fee;

•rate timestamp;

•settlement date;

•conversion date;

•rounding;

•merchant ability to retain original currency;

•payout FX;

•refund FX.

DCC fact-check items

DCC is only a boundary topic here.

If included beyond the brief explanation, verify:

•which card/ecommerce transactions are eligible;

•network/provider;

•customer-choice requirements;

•currency detection;

•exchange-rate disclosure;

•markup disclosure;

•opt-out;

•transaction currency after selection;

•merchant/acquirer responsibilities.

Do not call merchant-defined local pricing DCC.

Country-pricing fact-check items

Only include country-specific pricing conclusions if evidence supports:

•local-currency customer expectation;

•method compatibility;

•pricing regulation;

•tax-inclusive/exclusive interaction;

•currency controls;

•local acquiring impact;

•relevant FX volatility;

•pricing convention.

This architecture article should generally link country pricing rather than own it.

Settlement fact-check items

Verify current:

•merchant balance currencies;

•settlement currencies;

•transaction-level versus batch settlement;

•settlement timing;

•uncollected-funds treatment;

•net settlement deductions;

•rolling reserve currency;

•payout schedules;

•payout currencies;

•bank-account currency requirements;

•payout conversion;

•conversion fees;

•multi-entity behavior.

Subscription fact-check items

If subscriptions appear beyond the short architectural boundary, verify:

•original signup currency;

•recurring transaction currency;

•fixed versus FX-derived local price;

•stored credential currency compatibility;

•settlement currency;

•customer migration;

•price-change handling;

•refund currency;

•merchant reporting.

Do not infer that a one-time currency configuration automatically applies to recurring billing.

Refund fact-check items

Verify:

•original transaction currency;

•refund currency;

•whether refunds must use original transaction currency;

•provider conversion at refund;

•settlement adjustment;

•rate timing;

•partial refund handling;

•customer account conversion;

•customer support messaging.

Do not guarantee that the customer's final home-currency refund will equal the original home-currency debit unless the applicable system actually guarantees that result.

Conversion and incrementality fact-check items

This article should not claim that local currency increases conversion.

If merchant data is later added, define:

•eligible traffic;

•currency shown;

•currency charged;

•payment-method changes;

•payment success;

•completed-order rate;

•margin;

•FX cost;

•refunds;

•customer complaints;

•control group.

Ask:

Would the transaction have completed if only the base currency were available?

The brief explicitly prohibits treating local-currency transaction share as incremental conversion.

Regulatory and consumer-protection fact-check items

If DCC, FX disclosure, recurring pricing or customer-price rules are discussed for a specific jurisdiction, verify:

•applicable law;

•payment regulation;

•card-network rule;

•consumer-price disclosure;

•recurring-billing disclosure;

•tax-price presentation;

•provider requirements.

Keep:

law

network rule

provider requirement

and:

merchant policy

separate.

Amber-flag claims

“Presentment currency is whatever currency appears on the product page.”

Too broad. Display and actual transaction currency can differ.

“If the customer pays in EUR, their account is debited in EUR.”

Not necessarily. Customer billing/account currency can differ. Visa's current architecture explicitly distinguishes those concepts.

“If the customer pays in EUR, the merchant receives EUR.”

Not necessarily. That is the core assumption challenged by the brief.

“Local-currency payment means local acquiring.”

Incorrect; they are separate configuration dimensions.

Unsupported. Current method pages specify distinct processing currencies.

“Settlement currency is the bank-account currency.”

Do not assume; settlement/balance and payout can be separate stages.

“The difference between transaction revenue and bank payout is FX.”

“The exchange rate was X.”

Incomplete unless rate source, currency pair, timestamp and conversion event are defined.

“Charging in local currency eliminates foreign transaction fees.”

Do not promise issuer-controlled outcomes.

Reverify internally. The specific public payout-currency article surfaced in research is dated October 15, 2020.

Before publication, obtain internal confirmation for:

•processing-currency terminology;

•method-specific currency support;

•card acquiring currency matrix;

•merchant balance currencies;

•settlement currencies;

•payout currencies;

•multi-currency balance functionality;

•settlement-to-payout conversion;

•bank-account currency restrictions;

•conversion rates/source;

•FX markups/fees;

•conversion timestamps;

•net-settlement treatment;

•refunds;

•subscription currency behavior;

•reporting/base-currency conversions;

•settlement report fields;

•reconciliation export fields;

•Merchant/MoR differences;

•legal-entity differences;

•country restrictions.

Provider/network verification requirements

For any payment route used as an example, verify:

•terminology;

•transaction currency;

•processing currency;

•supported settlement currencies;

•customer billing conversion;

•FX party;

•rate;

•markup;

•network fee;

•settlement timing;

•refund conversion;

•minor-unit requirements.

Do not assume the Visa currency model uses exactly the same terminology or economic sequence as every alternative method.

Measurement plan

Primary operational hypothesis

Explicit currency-layer tracking materially reduces unexplained FX differences and reconciliation ambiguity while allowing the merchant to make better presentment and settlement choices.

Primary architecture metric

Currency lineage completeness

Transactions for which every applicable currency layer and conversion event can be reconstructed

÷ multi-currency completed transactions

Supporting metrics

Transaction volume by presentment currency

Settlement value by currency

Presentment-to-settlement FX incidence

Payout-conversion incidence

FX cost by currency pair

Reconciliation exception rate

Unexplained currency-difference value

Refund currency exceptions

FX-related support contacts

Segmentation

•customer country;

•transaction currency;

•payment method;

•acquirer/provider;

•settlement currency;

•payout currency;

•transaction value;

•Merchant versus MoR;

•one-time versus recurring;

•customer-selected versus merchant-selected currency.

Validation exercise

Select representative transactions from:

•base-currency card payment;

•local-currency card payment;

•local payment method;

•transaction requiring merchant settlement FX;

•same-currency settlement;

•payout conversion;

•full refund;

•partial refund;

•subscription renewal where relevant.

For every transaction answer:

•What did the customer see?

•What did the customer authorize?

•Which transaction currency entered the provider?

•Which processing route handled it?

•Was another currency required?

•Where did FX happen?

•Who converted?

•At what rate and time?

•What did the merchant settle?

•What appeared in merchant balance?

•What was paid to the bank?

•Which fees/adjustments explain the difference?

•Can finance reproduce the result from raw data?

Disconfirming evidence

The architecture is insufficient if:

•reporting overwrites original transaction currency;

•finance cannot identify the conversion party;

•payouts cannot be mapped to transaction currencies;

•settlement FX cannot be separated from provider fees;

•customer account conversion is incorrectly inferred;

•or refunds lose linkage to original currency.

Cluster sameness-audit fields

Field

Presentment Currency vs Settlement Currency

Title

Presentment Currency vs Settlement Currency: How Payment Currency Layers Fit Together

First two sentences

Customer pays €120. Merchant reporting shows $128.43.

Opening device

Three monetary values from one hypothetical transaction

Customer problem

Customer and merchant see different currencies/amounts without a clear explanation

Main currency layer

Presentment → settlement → payout

Primary market

Cross-market

Primary format

Payment currency layer map

Evidence anchor

Customer can pay in one currency while merchant receives another

Editorial position

Preserve every economically meaningful currency layer

Merchant decision

Where should currency conversion occur and who should bear exposure?

Original framework

Payment Currency Layer Map

Primary metric

Currency lineage completeness / reconciliation exceptions

Conclusion

Currency should be modeled as a sequence, not one field

CTA

Trace representative payments from catalog through bank payout

Closing element

Layer-map validation exercise

H2 fingerprint

•Stop treating “payment currency” as one field

•Layer 1: catalog currency

•Layer 2: display currency

•Layer 3: transaction or presentment currency

•Layer 4: customer account or billing currency

•A customer can pay “in EUR” and still experience FX

•Layer 5: processing currency

•Currency choice can therefore change method availability

•Layer 6: settlement currency

•Presentment and settlement solve different problems

•Layer 7: merchant balance currency

•Layer 8: payout currency

•Settlement and payout are also different in time

•One payment can contain several different FX events

•Transaction FX and treasury FX should not be conflated

•Customer FX exposure and merchant FX exposure are separate

•Never use “the exchange rate” without naming the rate

•The Payment Currency Layer Map

•Do not manufacture a customer billing currency

•Reporting should preserve originals and derived equivalents

•Why $128.43 and $126.90 cannot be explained from the totals alone

•Reconciliation should work from transaction to payout

•Batch payouts make transaction lineage even more important

•Multi-currency settlement can reduce one conversion and create another treasury decision

•Choosing settlement currencies should follow economic flows

•Local-currency presentment is not local acquiring

•DCC introduces another decision, not another synonym

•Refunds prove why original currency data must survive

•Subscriptions make currency lineage persistent

•Merchant architecture decision 1: where should conversion happen?

•Merchant architecture decision 2: who bears the exposure?

•Merchant architecture decision 3: what must reporting preserve?

•Measurement requirements

•Final recommendation

Sameness safeguard: unlike the local-currency preference article, this piece does not lead with customer familiarity. Unlike Multi-Currency Pricing, it does not own price-setting. Unlike DCC, it does not own customer currency-choice mechanics. Unlike the settlement cluster, it does not recommend a treasury strategy. Its territory is the technical lineage connecting every currency layer in one payment.

Information notice: This article provides general information and does not constitute legal, regulatory, tax, financial, treasury or accounting advice. Merchants should verify current requirements and product capabilities with qualified advisers, payment providers, acquirers, card networks, banks and relevant authorities.