THE INDEPENDENT PAYMENTS INTELLIGENCE PLATFORMBuilt around merchants. Not a single provider. ↗
Guide · Currency and pricing

Dynamic Currency Conversion Explained

Dynamic Currency Conversion Explained: Who Converts the Currency and What the Customer Actually Chooses A customer is buying something priced at: €100 During card payment, they are offered an alternative: Pay €100 or: Pay $109.40 The dollar amount here is illustrative, not a curr

Research draft awaiting independent review. This material was adapted from an existing research library. Provider-specific promotions have been excluded automatically; facts, regulatory requirements, and conclusions must be verified before the page is indexed publicly.

Dynamic Currency Conversion Explained: Who Converts the Currency and What the Customer Actually Chooses

A customer is buying something priced at:

€100

During card payment, they are offered an alternative:

Pay €100

or:

Pay $109.40

The dollar amount here is illustrative, not a current exchange-rate quote.

The product has not suddenly acquired a second economic price.

What changed is the currency-conversion decision.

Someone identified that the customer's card could be eligible for a different billing currency. Someone generated the converted amount. Someone selected an exchange rate and any applicable markup. And the customer now has to choose which transaction currency to use.

That is Dynamic Currency Conversion.

Understanding DCC therefore starts with three questions:

Who controls the conversion?

Who sets the conversion terms?

When does the customer choose?

Those questions distinguish DCC from local pricing, multi-currency ecommerce and ordinary issuer FX.

What Dynamic Currency Conversion actually is

Dynamic Currency Conversion, or DCC, is an optional card-payment service that lets an eligible cardholder choose to complete a cross-border transaction in a currency associated with their card—typically described by card networks as the cardholder's billing currency—rather than leaving the transaction in the merchant/local transaction currency.

Mastercard's current merchant DCC guide describes the service as being provided by acquirers and their merchants or ATM owners. If the customer chooses the billing-currency DCC option, the account is debited using the conversion rate offered on the acquirer side. If the customer keeps the transaction in the merchant/local currency, the issuer handles any subsequent conversion needed for the customer's account.

That distinction matters:

DCC accepted: conversion occurs on the merchant/acquirer/DCC side before the transaction proceeds in the selected billing currency.

DCC declined: the payment remains in the merchant's transaction currency, and the issuer/account provider may perform the conversion later if the account requires one.

DCC is therefore not merely a different way of formatting a number on the checkout page.

It changes which participant performs the FX conversion.

DCC is a card-payment layer, not a catalog-pricing layer

Imagine that the merchant's catalog price is:

€100

That amount exists before the customer enters card details.

Now compare two experiences.

Merchant multi-currency pricing

The product page itself offers:

€100

or:

$109.40

The merchant has already established both possible transaction prices. The customer can select USD even before the merchant knows which card they will use.

That is merchant pricing or multi-currency pricing.

Dynamic Currency Conversion

The merchant begins with:

€100

The card/payment credential is entered.

The acquiring/DCC system determines that a DCC offer can be made and produces an alternative amount in the relevant card billing currency.

The customer is then asked whether to keep the €100 transaction or accept the converted amount.

That is DCC.

Visa's current rules treat Multi-Currency Pricing and DCC as separate concepts. Its definition of an MCP transaction explicitly states that the merchant displays foreign-currency prices and no DCC conversion is conducted.

The same two currency symbols can therefore appear on screen while representing completely different payment architectures.

Where DCC enters an ecommerce checkout

DCC can apply to ecommerce; it is not limited to airport shops, hotels or physical terminals.

Visa's April 2026 rules specifically state that when an ecommerce merchant uses a cardholder's payment credential to determine eligibility to convert the purchase amount from the merchant's currency to the cardholder billing currency, the transaction must follow the applicable DCC requirements.

Mastercard's current DCC guide likewise contains specific ecommerce requirements and ecommerce screen guidance. It identifies an unclear or nonexistent ability to opt out during ecommerce checkout as an example of improperly applied DCC.

A simplified ecommerce sequence is therefore:

Merchant establishes transaction amount

→ customer enters card/payment credential

→ provider/acquirer evaluates DCC eligibility

→ billing currency is determined where applicable

→ DCC quote is generated

→ original and converted amounts are disclosed

→ customer chooses

→ payment is submitted in the chosen transaction currency.

That point in the flow is what separates DCC from ordinary currency localization.

“Customer currency” should not mean IP-address currency

DCC depends on the payment instrument, not merely customer geography.

A shopper may:

live in France while using a UK-issued card;

travel while using their normal card;

use an account associated with another currency;

use a specialized or multi-currency payment product.

Visa's current rules even exclude certain Visa multi-currency and travel prepaid products from DCC eligibility.

So an ecommerce merchant should not reason:

IP address = customer currency = DCC currency.

The merchant or its DCC/acquiring provider should use the approved payment-credential and network information required by that implementation.

Mastercard's current guide also highlights the operational danger of inaccurate card-account-range data: misidentifying the billing currency can cause an incorrect DCC conversion and potentially another conversion later.

That makes currency identification part of DCC correctness—not simply a personalization feature.

Who actually offers DCC?

The card network sets rules around DCC, but that does not mean the card network itself necessarily supplies the merchant's DCC rate.

Mastercard explicitly describes DCC as an acquirer/merchant or ATM service rather than a Mastercard product. It requires acquirers and DCC service providers to be registered before the service is offered.

Visa similarly requires the acquirer to meet DCC registration/certification requirements and ensure participating merchants comply with its DCC rules.

Depending on the implementation, participants may therefore include:

Merchant

Owns the sale, initial transaction price and checkout experience.

Acquirer

Enables DCC and participates in transaction processing.

DCC service provider

May provide card-currency identification, rate quotation and other DCC infrastructure.

Card network

Defines applicable network processing and cardholder-choice requirements.

Issuer

Owns the customer's card/account relationship and handles issuer-side FX when the transaction is submitted in a currency different from the account's applicable currency.

This is why the phrase:

“Visa converted the transaction”

or:

“Mastercard set the DCC rate”

should not be used casually.

The actual conversion participant must be identified.

Who sets the DCC exchange rate?

There is no universal “DCC exchange rate.”

Under Mastercard's current merchant guidance, the DCC markup can arise from the commercial arrangement involving the merchant or ATM owner and acquirer; its guidance says the acquirer-side merchant sets the exchange rate, often with a DCC service provider facilitating the process. Mastercard itself does not determine the DCC rate or markup.

Another provider or network implementation should be verified independently rather than assumed to work identically.

For merchants, the practical questions are:

What is the rate source?

Who creates the final customer rate?

When is the rate timestamped?

How long is the quote valid?

What spread or markup is included?

Is any separate conversion charge applied?

Which participant receives the economics associated with that markup?

What happens if authorization or capture occurs later?

Without those answers, saying “we offer DCC at the exchange rate” is not precise enough.

Exchange rate and markup are not the same thing

Currency-conversion discussions often collapse several amounts into one “FX fee.”

They should be separated.

Reference rate

An external benchmark used for comparison.

Conversion rate

The actual rate used to turn the transaction amount from one currency into another.

FX spread

The difference incorporated into the conversion rate relative to another reference.

Markup or conversion charge

An additional charge associated with providing the conversion service.

Foreign transaction fee

A charge that may be applied separately by the customer's issuer according to the card/account terms.

Mastercard's current DCC guide explicitly treats markup as distinct from the exchange rate and requires the DCC rate plus applicable fees or markups to be disclosed to the customer.

The merchant should therefore avoid telling customers:

“This is the exchange rate.”

when the commercial proposition actually involves:

reference rate + spread/markup + potentially separate issuer-controlled charges.

What must the customer see?

A valid DCC choice is not merely:

USD or EUR?

Current Visa guidance says cardholders should be shown the purchase amount in both the local and cardholder currencies, both currency symbols, the conversion rate and additional fees or markup. Visa also requires customers to be given the choice to accept or decline conversion and says the merchant must not choose on their behalf.

Visa's April 2026 rules reinforce that requirement: DCC must be described as optional, must not be preselected and requires the cardholder's express agreement.

Mastercard's current standards similarly require:

no default DCC selection;

no steering toward DCC;

clear and neutral presentation;

both the merchant/local and billing-currency amounts;

the conversion rate;

applicable fees/markup;

an explicit customer choice.

This is an important product-design constraint.

A merchant should not optimize DCC acceptance using dark patterns.

DCC choice cannot be an A/B test in disguise

An ecommerce team might normally experiment with:

button prominence;

default selections;

color;

wording;

choice order.

DCC is not a normal upsell widget.

Current Mastercard guidance requires currency options to receive equal presentation and specifically prohibits patterns such as highlighting or preselecting DCC and using misleading language that makes DCC appear more favorable.

Visa likewise prohibits procedures such as preselecting DCC and requires express agreement.

So the appropriate merchant experiment is not:

“How aggressively can we increase DCC opt-in?”

It is:

“Does a compliant, neutral DCC choice improve the currency experience for eligible customers without increasing complaints, payment failure or poor merchant economics?”

What happens when the customer accepts DCC?

Suppose the merchant transaction is:

€100

and the eligible DCC offer is an illustrative:

$109.40

The customer actively selects the dollar amount.

The merchant/acquirer path then proceeds using the DCC-selected billing currency and associated conversion information according to the applicable provider/network implementation.

In Mastercard's description, the customer's account is debited using the exchange rate offered by the acquirer when the billing-currency DCC option is chosen.

Operationally, the merchant should store enough information to answer later:

original transaction amount;

original transaction currency;

DCC transaction amount;

DCC transaction currency;

quoted exchange rate;

applicable markup/fees;

customer choice;

transaction/payment identifier;

provider/acquirer reference.

That information becomes important during support, disputes and refunds.

What happens when the customer declines DCC?

The payment should proceed in the merchant/local transaction currency.

Mastercard's current standards say that where the cardholder does not explicitly choose the billing-currency DCC option, the transaction must be processed in local currency; automatic DCC is not permitted.

If the customer's account is denominated differently, the issuer then determines how that foreign-currency transaction is converted for the customer's account.

Mastercard notes that in a non-DCC transaction the issuer may or may not use a Mastercard foreign-exchange rate and may apply additional foreign-currency fees under the customer's account agreement.

That means the merchant usually cannot tell the customer with certainty:

“Your bank will convert this at X.”

The issuer controls that side of the transaction.

DCC versus issuer conversion

This is the simplest way to explain the difference.

Question

Customer accepts DCC

Customer keeps merchant currency

Transaction submitted in

DCC-selected billing currency

Merchant/local transaction currency

Who performs the customer-facing conversion?

Acquirer/DCC side

Issuer/account side if conversion is required

When does customer see conversion terms?

Before accepting DCC

Usually through issuer/account pricing and statement information

Who controls DCC rate?

DCC/acquirer arrangement

Not applicable

Who controls issuer FX?

Not the merchant

Issuer/account provider

Can merchant promise which is cheaper?

No

No

Mastercard's current merchant guide describes precisely this division of conversion control.

This is why “DCC versus local currency” is not really a question about two currencies.

It is a question about two possible conversion providers.

DCC does not guarantee the lowest FX cost

A DCC offer gives the customer immediate visibility into one conversion proposition.

That does not prove it is cheaper or more expensive than issuer conversion in every case.

The customer would need to compare the DCC rate/markup with the conversion and fees their issuer would apply—information the merchant may not fully know in real time.

Visa therefore frames DCC as a customer choice and requires the relevant conversion terms to be visible before that choice.

Merchants should not use copy such as:

“Save money by paying in your currency.”

unless an appropriately defined and verified comparison actually supports it and the wording complies with network and local requirements.

Likewise:

“Pay in local currency to get the best rate.”

is not a universally supportable claim.

The merchant normally does not control the customer's issuer pricing.

DCC versus merchant local-currency pricing

This distinction should be explicit enough that a merchant can diagnose its own system.

Merchant local/multi-currency pricing

DCC

When currency is chosen

Pricing/catalog/checkout stage

Card-payment stage

Who creates price

Merchant/pricing engine

DCC/acquirer side converts existing transaction

Requires eligible card?

No

Yes

Depends on card billing currency?

Not necessarily

Yes, as applicable

Customer can choose before card entry?

Often

Generally no

Rate controlled by

Merchant pricing methodology

DCC/acquirer/provider arrangement

Purpose

Merchant price/presentment strategy

Payment-stage currency-conversion choice

Is issuer FX avoided automatically?

Depends on final transaction/account currencies

Depends on DCC/account configuration; do not promise universally

Visa's current rules separately regulate DCC and Multi-Currency Pricing and define MCP transactions as merchant-displayed foreign-currency pricing without DCC.

So DCC should not be the merchant's local-pricing strategy.

A merchant can maintain excellent local pricing without DCC.

A merchant can also offer DCC while maintaining a single base transaction currency.

They solve different problems.

What about a local-currency approximation?

There is a third model.

A website might display:

Approximately $109

but ultimately submit:

€100

That is neither necessarily multi-currency pricing nor DCC.

It may simply be an indicative currency display.

The merchant should clearly communicate which amount is merely informational and which currency will actually be charged. The editorial brief specifically requires display currency and actual transaction currency to remain distinct.

A merchant should never describe an approximate display as “paying in local currency” if the actual payment remains foreign-currency-denominated.

DCC disclosure in the European Union

For covered card-based currency conversion in the EU, Regulation (EU) 2021/1230 provides an additional transparency layer.

Article 4 requires the total currency-conversion charge to be expressed as a percentage markup over the latest available ECB euro reference rate and disclosed before the payment transaction is initiated.

The regulation's explanatory text also emphasizes comparability when customers are presented with alternative conversion options and contemplates disclosure on-screen for online purchases.

This is a useful example of why DCC UI cannot be designed solely from a conversion-rate API response.

The merchant/provider must account for:

network rules

plus:

applicable law/regulation

plus:

provider/acquirer implementation requirements.

Do not assume one worldwide disclosure template satisfies every jurisdiction.

The original amount should remain visible

One of the best operational controls is to preserve both sides of the choice.

For a DCC transaction, record:

Original amount: €100

Original transaction currency: EUR

DCC amount: illustrative $109.40

DCC currency: USD

Rate: provider-supplied value

Markup/charge: provider-supplied value

Customer choice: DCC accepted

This is not merely a UX requirement.

It supports:

customer service;

dispute investigation;

refund processing;

finance reconciliation;

network compliance review.

Merchant reporting should not overwrite €100 with $109.40 and discard the pre-conversion information.

DCC and settlement currency are different layers

DCC determines the currency in which the card transaction is completed after the customer's choice.

It does not by itself tell the merchant what currency will ultimately reach its bank account.

Merchant settlement can depend on:

acquirer agreement;

PSP configuration;

merchant balance currencies;

settlement arrangement;

payout bank account.

So:

DCC transaction currency ≠ automatically merchant settlement currency.

The broader relationship among presentment, transaction, settlement and payout currencies belongs in the dedicated Presentment Currency vs Settlement Currency article, as the cluster brief requires.

For this article, the merchant only needs to understand that DCC changes the card transaction's currency choice; settlement remains a separate financial layer.

Refunds need currency continuity

A refund introduces another potential conversion.

Current Mastercard DCC guidance says DCC refunds should be processed in the same currency as the original transaction and describes permitted methods designed to avoid an additional conversion loss.

That is a Mastercard-specific current rule example, not a universal statement about every network/provider.

Before launch, verify:

original DCC transaction currency;

refund currency;

whether the original conversion rate is retained;

provider refund API behavior;

partial refund handling;

merchant settlement adjustment.

The complete customer FX consequences of refunds belong in the cluster's dedicated Refunds and Currency Conversion article.

Incorrect or non-consensual DCC can become a dispute problem

Currency choice is not cosmetic.

Visa's current rules require express customer agreement and preserve dispute rights around incorrect DCC/currency processing when the acquirer cannot demonstrate the necessary cardholder choice.

Mastercard's current guide likewise discusses cardholder complaint and chargeback rights where DCC is applied without proper consent or otherwise processed incorrectly.

This creates a simple merchant control:

Store evidence of the currency choice.

The merchant should be able to reconstruct:

what was offered → what was disclosed → what the customer selected → what currency was submitted.

The DCC Decision Flow

Use the following as the article's practical asset.

Merchant transaction created

Example:

€100 EUR

This is the merchant transaction amount before DCC.

↓

Payment credential supplied

The acquirer/provider obtains sufficient approved card information to determine whether DCC may be offered.

↓

DCC eligibility assessed

Questions include:

Is the card eligible?

Is the transaction cross-currency?

Is the billing currency supported?

Is the merchant/acquirer enabled?

Do provider/network restrictions permit DCC?

Visa's current rules, for example, exclude certain multi-currency/travel prepaid products.

↓

DCC quote generated

Provider/acquirer supplies:

original amount + original currency

and:

converted amount + billing currency

plus:

conversion rate + required markup/fee disclosure.

Mastercard describes the DCC rate as an acquirer-side proposition rather than a Mastercard-set conversion.

↓

Customer receives neutral choice

The customer must be able to select either currency without DCC being forced or preselected. Current Visa and Mastercard standards both require genuine customer choice.

↓

6A. Customer accepts DCC

Transaction proceeds in the selected billing currency under the DCC conversion.

or:

6B. Customer declines DCC

Transaction proceeds in the merchant/local currency.

If the account needs conversion, issuer-side FX follows according to the card/account terms.

↓

Authorization/payment outcome returned

Merchant receives the card-payment result.

↓

Settlement and reconciliation follow

Merchant settlement currency and payout remain contract/configuration-specific rather than being inferred from the DCC currency.

The DCC Currency Control Map

A useful companion to the flow is to assign each decision to the participant that actually controls it.

Decision

Typical controller

Merchant should verify

Base transaction price

Merchant

Catalog/order currency

DCC eligibility

Acquirer/DCC provider under network rules

Eligible cards/currencies

Billing-currency identification

Provider/acquirer

Data source and accuracy

DCC exchange-rate quote

DCC/acquirer arrangement

Rate source and timestamp

DCC markup/charge

Commercial/provider arrangement

Amount and disclosure

Accept/decline DCC

Customer

Express consent retained

Issuer-side FX after decline

Issuer/account provider

Merchant generally cannot control

Merchant settlement

Acquirer/PSP

Contract and settlement currency

Merchant payout

PSP/bank arrangement

Bank-account/payout currency

The point is not that every DCC deployment uses an identical provider stack.

It is that every conversion must have an owner.

When DCC may provide customer value

DCC can give an eligible cardholder one useful property:

a known converted transaction amount before they commit.

That can help a customer who prefers to make a conscious decision in the card's billing currency rather than leave conversion to the issuer later. Current network rules are built around ensuring the customer can see the terms and make that informed choice.

But that does not mean DCC is inherently:

cheaper;

more transparent than every issuer;

better for conversion;

preferable to merchant local pricing.

Those are separate questions.

When DCC may create unnecessary friction

DCC can become problematic when:

the customer already saw and selected an intentional local price;

a second currency screen introduces confusion;

the card billing currency is misidentified;

disclosure is difficult to understand;

the DCC markup is commercially unattractive to the customer;

the merchant's checkout makes one currency appear preferred;

support teams cannot explain which party performed conversion.

In those cases, offering another currency is not automatically a localization improvement.

It can become another payment decision the customer has to interpret.

DCC should not replace a local pricing strategy

Suppose a U.S. merchant deliberately maintains:

€89

for its German market.

That €89 may incorporate:

competitive positioning;

local taxes;

margin;

market-specific pricing;

rounding.

DCC starts from a different idea:

take an existing transaction and offer a cardholder-specific conversion during payment.

If the merchant's commercial objective is to set the right German price, DCC does not solve that problem.

The appropriate tool is local or multi-currency pricing.

This article should therefore resist the claim:

“We don't need local prices because DCC handles currencies.”

It does not handle the same decision.

DCC cannot promise customers zero foreign-transaction fees

The merchant does not control every fee in a customer's card agreement.

Issuer charges can depend on:

issuer;

card product;

transaction geography;

transaction currency;

account terms.

Even where a customer chooses a billing-currency DCC amount, merchants should not make unsupported claims that every issuer-controlled cross-border charge disappears.

Likewise, declining DCC does not let the merchant know the issuer's exact final conversion cost.

The editorial brief specifically requires merchant-controlled FX costs to remain distinct from issuer-controlled foreign-transaction fees.

Double conversion is a configuration failure, not a vague warning

“Double conversion” should identify two actual conversions.

For example:

DCC system converts EUR into an incorrectly identified GBP billing currency.

Customer's account is actually associated with another currency and another conversion occurs.

Mastercard's current merchant guide uses incorrect billing-currency identification as an example of how such a loss can occur.

The prevention is not simply:

“Avoid double FX.”

It is:

use accurate card/account-range data;

preserve the original currency;

apply DCC only to eligible transactions;

ensure the customer can decline;

submit exactly the currency the customer chose.

What merchants should measure

DCC performance should not be reduced to:

“What percentage of customers selected DCC?”

That measures preference among customers shown an offer, not merchant value.

DCC eligibility rate

Eligible card-payment attempts

÷ relevant cross-border card-payment attempts

Define “eligible” using the provider/network implementation.

DCC offer rate

DCC offers actually displayed

÷ DCC-eligible attempts

A gap can reveal technical or configuration issues.

DCC selection rate

Customers selecting DCC

÷ customers shown a valid DCC offer

This is an opt-in metric, not a conversion metric.

DCC payment completion rate

Completed payments after DCC selection

÷ DCC selections

Local-currency completion after DCC decline

Completed payments after customer declines DCC

÷ DCC declines

Do not interpret differences between these two populations causally without controlling for customer/card/market differences.

Currency-choice abandonment

Customers shown DCC who leave during or immediately after the currency-choice step.

FX-related support-contact rate

Transactions producing a DCC/FX support contact

÷ transactions exposed to DCC

Useful categories include:

did not understand second currency;

rate complaint;

unexpected issuer charge;

incorrect currency;

refund discrepancy.

Incorrect-DCC incident rate

Track:

DCC without verified consent;

wrong billing currency;

transaction submitted in currency other than selected;

missing disclosure;

duplicate/double conversion.

DCC dispute rate

Define the relevant currency/DCC dispute conditions rather than mixing them with all card disputes.

Merchant DCC economics

If the merchant's acquiring contract creates any DCC-related revenue, fee, rebate or additional processing cost, measure it explicitly.

Do not assume such economics exist or use a generic industry number.

DCC testing should have compliance guardrails

A merchant can test whether DCC deserves continued use.

It should not test whether a dark pattern can make more customers select it.

A legitimate experiment might compare:

countries;

customer cohorts;

eligible card populations;

transaction values;

DCC-enabled versus not-enabled merchant/acquirer configurations where permissible;

payment completion;

support contacts;

disputes;

merchant contribution.

Keep the choice UI inside the network/provider's compliant presentation rules.

Hypothesis

A compliant DCC option gives eligible cross-border cardholders useful currency certainty without materially worsening payment completion, customer complaints, disputes or merchant economics.

Evidence supporting the hypothesis

customers use the option;

payment completion remains healthy;

FX-related complaints remain low;

incorrect-currency incidents remain rare;

merchant economics are acceptable;

refund/reconciliation operations work reliably.

Evidence against it

the currency-choice step creates material abandonment;

customers frequently dispute or complain about the rate;

billing currency is often misidentified;

issuer/DCC confusion creates support burden;

DCC-related disputes increase;

merchant economics do not justify the operational layer;

local pricing already gives the target customer a better-understood experience.

The merchant should be willing to conclude:

DCC adds little value for this checkout.

Terminology questions

Is DCC the same as paying in local currency?

No.

DCC normally gives an eligible cardholder a choice between the merchant/local transaction currency and a converted billing currency. Paying in the merchant/local currency generally means declining the DCC conversion.

Is DCC the same as multi-currency pricing?

No.

Multi-currency pricing is merchant-defined pricing in multiple transaction currencies. DCC is a payment-stage conversion offer linked to the customer's card/payment credential. Visa's current rules explicitly treat MCP as a separate transaction model.

Can the merchant automatically select DCC?

Current Visa rules require DCC to be optional and expressly agreed to; current Mastercard guidance prohibits automatic DCC and requires a clear, neutral customer choice.

Can DCC be used in ecommerce?

Yes, where the specific merchant/acquirer/network implementation supports it. Visa's current rules explicitly address ecommerce merchants determining DCC eligibility from a payment credential, and Mastercard's current guidance includes ecommerce DCC requirements.

Who sets the DCC rate?

It depends on the DCC arrangement. Mastercard's current guide says its DCC rate is set on the acquirer/merchant side, commonly facilitated by a DCC service provider, rather than by Mastercard itself. Verify the specific network/acquirer/provider arrangement.

What happens if the customer declines DCC?

The transaction remains in the merchant/local currency. If the customer's account requires conversion, the issuer handles that conversion under its own terms.

Does DCC guarantee a better exchange rate?

No. A valid DCC offer should disclose its conversion terms so the customer can make a choice, but the merchant generally cannot know or guarantee how that proposition compares with every customer's issuer/account pricing.

Does choosing DCC eliminate every foreign transaction fee?

Merchants should not make that promise. Issuer-controlled fees and card-product terms are outside the merchant's direct control.

Does DCC change how the merchant settles?

Not necessarily. DCC concerns the card transaction's currency choice. Merchant settlement and bank payout remain separately configured financial layers.

Final recommendation

The most useful way to understand DCC is not:

“The customer sees their own currency.”

It is:

“The customer chooses who controls this conversion.”

One path leaves the transaction in the merchant's currency and lets the issuer/account side handle any required FX.

The other accepts a conversion generated through the merchant/acquirer/DCC arrangement and submits the transaction in the selected billing currency.

Current Visa and Mastercard rules make that choice central: DCC must be optional, the customer must be informed, and conversion cannot simply be imposed by default.

That makes DCC fundamentally different from merchant local pricing.

Local pricing asks:

“What should this product cost in this market?”

DCC asks:

“Who should convert this card transaction?”

Merchants should use DCC only when that second choice is valuable to eligible customers, transparently disclosed and operationally supportable.

The final merchant question is therefore:

“When this customer sees two currencies, can we explain exactly who generated each amount, which conversion they are choosing, what the disclosed FX economics are, and what happens if they say no?”

If the answer is no, the merchant does not yet have a sufficiently controlled DCC experience.

I’ll treat this as Editorial Brief 3: Dynamic Currency Conversion Explained. The brief correctly makes control of conversion the organizing idea: DCC is not “showing a customer their currency”; it is an explicit payment-stage choice about who converts the transaction, at what rate, and under what disclosed terms. Current network rules strongly support that framing: Visa requires DCC to be optional and expressly accepted, while Mastercard requires a clear, neutral choice and prohibits automatic DCC.

The most valuable editorial device to preserve is “same price, different conversion controller.” It prevents the piece from collapsing into another local-currency article and makes the required distinctions—DCC versus local pricing, DCC versus issuer FX, and customer choice versus automatic localization—immediately understandable.

Original practical asset: DCC Decision Flow

Visual layout

START

Merchant transaction

€100 EUR

↓

CARD / PAYMENT CREDENTIAL

Is DCC available for this merchant, transaction and card?

NO

→ Continue in merchant transaction currency.

YES

↓

DCC QUOTE

Display:

Merchant amount: €100 EUR

Converted amount: $X USD

Exchange rate

Required markup/fees

Currency-choice disclosure

↓

CUSTOMER CHOICE

Keep EUR

→ Transaction submitted in merchant/local currency

→ Issuer conversion may follow

Choose USD

→ DCC accepted

→ Transaction submitted in DCC billing currency

↓

PAYMENT OUTCOME

Authorization / payment result

↓

POST-PAYMENT

Merchant reconciliation

→ settlement

→ refund/dispute if applicable

Visual callout:

“Same purchase. Different conversion controller.”

Dynamic Currency Conversion Explained — Editorial Package

Current-state verification date: August 9, 2026

Editorial interpretation

Customer currency problem: A cross-border cardholder encounters a transaction denominated in a currency different from the currency associated with their card/account and must decide whether to accept a conversion offered during payment or leave the transaction in the merchant's currency.

Unique evidence anchor: DCC is a conversion choice inside the card-payment flow. The converted amount is not simply a localized display price. The acquirer/DCC side supplies a conversion offer and the customer decides whether to use it. Mastercard's current merchant guidance describes DCC as an acquirer/merchant or ATM service through which the cardholder chooses between the merchant/local currency and the card's billing currency.

Editorial position: Merchants should evaluate DCC as a customer currency-choice mechanism with explicit FX economics and disclosure requirements—not as a substitute for merchant-defined local pricing.

Common assumption challenged: “DCC and local-currency pricing are basically the same thing.”

Merchant decision: Determine whether an eligible customer benefits from being offered a transparent choice between the merchant's transaction currency and the card billing currency, while ensuring that the rate, markup, consent flow, refund handling and merchant economics are understood.

Selected format: Currency-control flow explainer.

Structural rationale: Follow control of the conversion through the participants: merchant → acquirer/DCC provider → cardholder → card network → issuer. The most important questions are who generates the second amount, who sets the rate, who chooses the transaction currency, and what happens if DCC is declined.

Proposed architecture

One price, two possible transaction currencies

What DCC actually is

Where DCC enters an ecommerce payment

How the card/billing currency is identified

Who generates the DCC rate

What the customer must be shown

What happens when the customer accepts

What happens when the customer declines

DCC versus issuer FX

DCC versus multi-currency/local pricing

Exchange rate versus markup

EU transparency requirements

Settlement, refunds and disputes

DCC Decision Flow

Merchant measurement and testing

Final recommendation

SEO metadata

H1: Dynamic Currency Conversion Explained: Who Converts the Currency and What the Customer Actually Chooses

Meta description: Learn how Dynamic Currency Conversion works, who sets the DCC rate, how customers choose a currency, and how DCC differs from local pricing and issuer FX.

URL slug: /dynamic-currency-conversion-explained

Secondary keywords: dynamic currency conversion; DCC payments; DCC ecommerce; dynamic currency conversion merchant; DCC vs local currency; DCC exchange rate; card currency conversion; merchant DCC.

Related entities: cardholder billing currency, transaction currency, acquirer, issuer, card network, FX markup, ECB reference rate, Multi-Currency Pricing, cross-border card payment.

Article excerpt: Dynamic Currency Conversion is not simply local-currency display. It is a card-payment choice about who converts a cross-border transaction, which rate and markup apply, and whether the customer accepts the conversion or leaves FX to their issuer.

Suggested structured data: Article. Add FAQPage only if the terminology questions remain in publication and current search requirements justify it.

Internal-link plan

Article context

Suggested anchor

Target

DCC transaction currency versus merchant payout

presentment currency vs settlement currency

Presentment Currency vs Settlement Currency

Issuer fees and conversion surprises

unexpected FX charges

How to Prevent Unexpected FX Charges

Broader customer preference for familiar currencies

why customers prefer local currency

Why Customers Prefer Local Currency

Merchant-defined local prices

multi-currency pricing

Multi-Currency Pricing Explained

FX differences after reversal

refunds and currency conversion

Refunds and Currency Conversion

This keeps Article 3 within its assigned ownership: DCC mechanics and conversion choice, rather than the cluster's broader pricing, settlement or conversion-performance questions.

Authoritative source recommendations

Visa

Use the April 18, 2026 Visa Core Rules and Visa Product and Service Rules for current DCC merchant/acquirer requirements, including:

optional DCC;

express agreement;

no default/preselection;

ecommerce applicability;

eligible-product restrictions.

Use Visa's current consumer DCC explanation for the customer-facing disclosure concepts:

both currency amounts;

currency symbols;

exchange rate;

applicable markup/fees;

right to accept or decline.

Mastercard

Use the current Dynamic Currency Conversion Performance Guide — Merchant Edition for:

DCC definition;

acquirer/merchant role;

issuer-versus-DCC conversion flow;

registration;

consent;

neutral presentation;

ecommerce treatment;

rate/markup responsibilities;

refund and complaint/dispute guidance.

European Union

Use Regulation (EU) 2021/1230, Article 4 for current card-based currency-conversion charge disclosure, including the requirement to express the total conversion charge as a percentage markup over the latest available ECB euro reference rate.

Do not generalize the EU rule globally.

Proposed author and reviewers

Primary reviewer: Card-payments specialist.

Acquiring reviewer: Acquirer/card-network operations specialist with current DCC experience.

Finance reviewer: Treasury or merchant-finance specialist.

Product reviewer: Ecommerce checkout/product owner.

Regional/legal reviewer: Appropriate specialist where EU or other jurisdiction-specific DCC requirements are discussed substantively.

Do not invent reviewer names or imply review has occurred before it has.

DCC fact-check requirements

Immediately before publication verify:

Current Visa DCC rules.

Current Mastercard DCC standards.

Other networks if referenced.

Eligible transaction types.

Card/product restrictions.

Ecommerce support.

DCC currencies.

Merchant/acquirer registration.

Billing-currency identification method.

Consent requirements.

Screen disclosure.

Receipt disclosure.

Rate and markup disclosure.

Refund rules.

Incorrect-currency dispute handling.

Regional exceptions.

Network rules change, so the April 2026 Visa rules and current Mastercard guide should be rechecked immediately before publication.

FX fact-check requirements

For every substantive FX example identify:

Original currency

DCC currency

Rate provider

Rate timestamp

Reference rate if used

DCC rate

Markup/spread

Additional conversion charge

Do not fabricate live FX rates.

The brief's €100/$109.40 opening is an illustrative example, not a market quotation.

Customer-choice fact-check requirements

Verify that the implementation:

clearly states DCC is optional;

gives the original transaction currency as a real choice;

does not preselect DCC;

obtains affirmative customer choice;

records that choice;

presents both amounts appropriately;

displays the rate;

displays applicable markup/fees;

follows relevant regional wording requirements.

Visa and Mastercard both currently impose explicit choice requirements.

Country and regulatory fact-check requirements

For every market discussed, verify:

applicable payment-services law;

DCC-specific transparency rules;

pricing disclosure;

consumer choice;

any additional FX disclosure requirements.

European Union

Current Article 4 of Regulation (EU) 2021/1230 requires covered card-based currency-conversion charges to be expressed as a percentage markup over the latest available ECB euro reference rate before transaction initiation.

Do not automatically apply this wording to non-EU markets.

Settlement fact-check requirements

Verify provider/acquirer-specific:

transaction currency;

clearing currency where relevant;

merchant settlement currency;

PSP balance currency;

payout currency;

conversion between those layers;

DCC fee/revenue treatment;

reconciliation fields.

Do not state:

“DCC means the merchant receives the cardholder's billing currency.”

That does not follow from DCC alone.

Refund fact-check requirements

Verify by network/provider:

refund currency;

original DCC conversion data retained;

full refund;

partial refund;

rate reuse;

additional FX conversion;

settlement adjustment;

customer statement behavior.

Mastercard's current guide requires DCC refunds to preserve original-transaction currency treatment according to its documented rules, but this should not be generalized to every network without verification.

Subscription boundary

Do not extend this one-time DCC flow automatically to recurring billing.

If subscriptions are mentioned, verify:

whether DCC is permitted/appropriate for the initial and subsequent transaction type;

whether repeated transactions preserve customer currency choice;

stored-credential/network requirements;

renewal currency.

Detailed recurring-currency strategy belongs in Subscription Billing in Multiple Currencies, not this article.

Conversion and incrementality fact-check requirements

Do not publish:

“DCC increases conversion.”

Instead track:

DCC eligibility;

offer exposure;

DCC selection;

payment completion after selection;

payment completion after decline;

currency-choice abandonment;

complaints;

disputes;

refunds;

merchant contribution.

Do not treat:

DCC transaction share

as:

incremental completed-order growth.

Amber-flag claims

“DCC means paying in local currency.”

Wrong framing. The DCC option normally converts away from the merchant/local transaction currency into a card billing currency.

“DCC is local pricing.”

No. Visa's current rules treat MCP/local multi-currency pricing separately.

“The card network sets the DCC rate.”

Do not generalize. Mastercard's current guide explicitly places its DCC rate on the merchant/acquirer side.

“DCC is automatic.”

Current Visa and Mastercard rules require genuine customer choice.

“DCC gives the best exchange rate.”

Unsupported without a valid defined comparison.

“Issuer conversion is cheaper.”

Also unsupported universally.

“Paying in billing currency avoids all foreign transaction fees.”

Do not promise issuer behavior.

“Customer home currency can be identified by IP.”

Not a valid DCC eligibility model.

“Local-currency settlement follows DCC.”

Settlement is a separate merchant layer.

“DCC increases conversion.”

Treat as a testable hypothesis, not a fact.

Multi-currency support and DCC are different mechanisms.

Exact acquirer/DCC-provider relationship.

Supported card networks.

Merchant countries.

Customer/card countries.

Eligible card products.

Supported billing currencies.

Original transaction currencies.

How billing currency is identified.

DCC quote/rate source.

Rate timestamp.

Markup/spread.

Required customer disclosure.

Consent evidence.

Checkout implementation.

Authorization/clearing data.

Refund behavior.

Partial refunds.

Incorrect-currency disputes.

Merchant settlement impact.

Merchant DCC fees or revenue, if any.

Reporting fields.

Approved DCC performance data.

Until that verification is complete, do not write:

from generic multi-currency documentation alone.

Provider/acquirer verification template

For every DCC implementation, complete:

Question

Required answer

Who provides DCC?

Acquirer / DCC service provider

Which networks?

Verified list

Which merchant markets?

Verified

Which cards are eligible?

Provider/network rules

How is billing currency identified?

Approved credential/account-range source

What is original transaction currency?

Explicit

Who generates the quote?

Named party

Which reference/rate is used?

Defined

What markup applies?

Defined

What must checkout display?

Network + legal requirements

How is consent recorded?

Defined

What happens after opt-out?

Original-currency processing

How are refunds handled?

Verified

What disputes can arise?

Verified

What does merchant settle in?

Contract

What does merchant earn/pay?

Contract

Which reporting fields preserve DCC?

Defined

Measurement plan

DCC eligibility rate

DCC-eligible payment attempts

÷ relevant cross-border card-payment attempts

Offer-delivery rate

Valid DCC offers shown

÷ DCC-eligible attempts

DCC opt-in rate

DCC selections

÷ valid DCC offers shown

DCC completion rate

Completed payments with DCC

÷ DCC selections

Local-currency completion after opt-out

Completed original-currency transactions after DCC decline

÷ DCC declines

Choice-stage abandonment

Sessions abandoning at or immediately after DCC choice

÷ valid DCC offers shown

FX/DCC support rate

DCC-related support contacts

÷ DCC-exposed transactions

Incorrect-currency incident rate

Define and track separately:

wrong billing currency;

missing consent;

currency mismatch;

double conversion;

wrong refund currency.

Merchant contribution

If DCC changes merchant fees/revenue:

incremental merchant DCC economics

minus:

incremental payment + refund + dispute + support + operational cost

Do not publish a universal DCC margin.

Supporting visual

Headline

Dynamic Currency Conversion changes who performs the FX conversion

Left path — Customer declines DCC

Merchant price

€100

↓

Customer keeps EUR

↓

Transaction submitted in EUR

↓

Issuer/account converts if needed

Right path — Customer accepts DCC

Merchant price

€100

↓

DCC quote generated

↓

Customer selects billing currency

↓

Transaction submitted in selected billing currency

Center callout

Customer chooses the conversion controller

Under the DCC branch show:

Acquirer / DCC provider

identifies eligibility;

provides quote;

supplies rate/markup disclosure.

Under issuer branch show:

Issuer / account provider

handles any account-side FX;

controls issuer terms/fees.

Image alt text

DCC Decision Flow comparing a cardholder who keeps the merchant transaction currency with one who accepts Dynamic Currency Conversion into the card billing currency.

Cluster sameness-audit fields

Field

DCC article

Title

Dynamic Currency Conversion Explained: Who Converts the Currency and What the Customer Actually Chooses

Opening device

One product price, two possible transaction currencies

Customer problem

Customer must understand who converts a cross-border card transaction

Main currency layer

Transaction/card billing currency

Primary market

Cross-border card payments; jurisdiction-specific rules where relevant

Primary format

Currency-control flow explainer

Unique evidence anchor

DCC changes control of FX conversion, not simply displayed currency

Editorial position

DCC is a choice mechanism, not local pricing

Merchant decision

Offer only when conversion choice is clear, compliant and economically justified

Original framework

DCC Decision Flow

Primary metric

DCC exposure → choice → payment completion + customer/merchant cost

Conclusion

Ask who generated each amount and who controls each conversion

CTA

Map and verify conversion control before enabling DCC

Closing element

Currency Control Map / provider verification template

This preserves the cluster boundary: Article 3 owns DCC mechanics, while multi-currency pricing, presentment versus settlement, conversion performance and FX-surprise prevention remain separate articles.

Legal and compliance note

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

Need help narrowing down payment options?

Answer a few questions about your business and compare the capabilities that matter to you.

Explore matching options ↗
EXPLORE PAYMENT INTELLIGENCE