Refunds and Currency Conversion
Refunds and Currency Conversion: Why Customers May Receive a Different Home-Currency Amount A customer pays: €100 Their card account is denominated in US dollars. Their statement records: $108 Two weeks later, the merchant issues a full refund: €100 The cardholder eventually sees
A second version is available below; I’d recommend combining the 2 later, if time allows
Refunds and Currency Conversion: Why Customers May Receive a Different Home-Currency Amount
A customer pays:
€100
Their card account is denominated in US dollars.
Their statement records:
$108
Two weeks later, the merchant issues a full refund:
€100
The cardholder eventually sees:
$105
Where did the other $3 go?
The natural reaction is:
“The merchant refunded me less.”
But that conclusion skips a critical part of the transaction.
The merchant sold and refunded in euros.
The customer's account is in dollars.
Somewhere between those two currencies, somebody performed foreign-exchange conversion.
And the conversion attached to the original purchase does not automatically guarantee the same home-currency result when the refund is processed later.
Visa's foreign-exchange tools explicitly distinguish the transaction currency from the cardholder billing currency and calculate converted amounts using currency pairs and applicable dates. Visa also cautions that the cardholder's bank may use different billing treatment or impose its own fees.
Mastercard likewise tells cardholders that the financial institution issuing the card determines the currency-conversion charges applied to foreign transactions; its currency-conversion information also notes that processing timing can determine the rate used in relevant cross-currency circumstances.
The operational lesson for merchants is:
Investigate the refund in two layers: was the correct transaction-currency amount refunded, and what happened when that amount was converted into the customer's account currency?
Do not collapse those into one question.
Start With the Original Transaction Currency
Suppose the checkout displayed:
€100
and the payment was actually submitted as:
€100
That is the first amount the merchant should preserve.
The merchant should be able to retrieve:
Original transaction amount: €100
Original transaction currency: EUR
Payment ID
Provider transaction ID
Purchase timestamp
Merchant entity
PSP/acquirer
Refundable amount remaining
Do not begin a refund investigation with:
“The customer says they paid $108.”
From the customer's perspective, that may be completely accurate.
But $108 may be the customer account debit, not the merchant's transaction amount.
Those are different currency layers.
Transaction Currency vs Customer Account Currency
For this example:
Merchant transaction currency
EUR
Transaction amount
€100
Customer account currency
USD
Customer statement debit
Approximately:
$108
The dollar value exists because EUR had to be converted into USD somewhere in the payment chain.
Depending on the transaction configuration, that conversion can involve the card network and/or issuer, while issuer-specific fees can also affect what ultimately appears on the cardholder's account. Visa specifically notes that the cardholder's bank may not use exactly the rate displayed by Visa's calculator and may impose additional foreign-transaction fees.
Mastercard provides the same type of warning: the issuer may apply its own currency-conversion charges.
Therefore:
€100 transaction
does not universally imply one predetermined:
$X customer debit.
Who Converted the Original Purchase?
Before explaining the refund, determine how the purchase was converted.
Several arrangements are possible.
Scenario A: Issuer-side or card-system conversion
Merchant charges:
€100
Customer account:
USD
The cross-currency card transaction is converted into the cardholder's account currency under the relevant card-system and issuer arrangement.
The merchant receives no instruction saying:
“Charge this customer $108.”
The merchant charged:
€100.
Scenario B: Dynamic Currency Conversion
The customer may instead be offered a choice to transact in their cardholder currency under a Dynamic Currency Conversion arrangement.
Visa describes DCC as a service in which a customer may be offered the choice of paying in their home currency rather than the merchant/local currency, with the applicable exchange rate and additional fees disclosed.
That is a different transaction.
If the customer chose USD through DCC, the original transaction currency itself may be USD under that arrangement.
Do not analyze that case as though the merchant charged EUR and the issuer later converted it.
The dedicated Dynamic Currency Conversion Explained article should own that complete mechanism.
Scenario C: Merchant or Provider Currency Conversion
A merchant or PSP may also operate a pricing or conversion arrangement under which:
Customer sees one currency
Another system converts the amount
Transaction is ultimately submitted in a defined currency
Again, the correct investigation starts with:
What currency was actually submitted as the payment transaction?
Not:
Which approximate currency did the customer initially see?
The Refund Should Be Investigated From the Merchant Outward
Now reverse the payment.
Original transaction:
€100
Merchant initiates:
€100 refund
The merchant should ask first:
Did we return the entire original transaction amount?
If:
Original charge = €100
Refund = €100
then the merchant has issued a full transaction-currency refund.
That statement is materially different from:
“The customer is guaranteed exactly $108 back.”
The merchant can generally verify the first from its own payment records.
It may not control the second.
Full Transaction-Currency Refund vs Home-Currency Equivalence
This distinction should appear directly in customer-support training.
Full transaction-currency refund
Original charge:
€100
Refund:
€100
Refund percentage:
100%
Home-currency equivalence
Original customer debit:
$108
Customer refund credit:
$105
Home-currency recovery:
Less than the original statement debit.
Both can be true simultaneously.
The difference does not by itself prove the refund was incomplete.
Why Can the Customer's Home-Currency Amount Change?
Several mechanisms can potentially create the difference.
Exchange Rates Moved
Foreign-exchange rates are not fixed permanently.
The ECB publishes euro reference exchange rates on working days, and those rates change as currency markets move.
If EUR/USD changes between:
purchase
and:
refund
then converting €100 on those two dates can naturally produce different dollar values.
This article's €108 and €105 figures are deliberately hypothetical.
They illustrate the mechanism rather than represent a real historical rate.
The Conversion Can Occur at a Different Time
The customer may make the purchase on:
Day 1
but relevant processing can occur later.
The refund might occur on:
Day 15
and itself be processed later.
Visa states that for its cross-currency conversion process, if the authorization-time rate cannot be used, the rate available when the transaction is processed can apply.
Mastercard similarly notes circumstances in which processing timing determines the exchange rate applied.
The merchant should therefore record actual transaction and refund processing timestamps rather than assuming:
purchase date = conversion date
or:
refund-button date = customer conversion date.
The Customer's Issuer May Apply Its Own Treatment
Cardholder account pricing is not fully controlled by the merchant.
Visa notes that the cardholder's bank may:
Use different billing treatment from the indicative Visa calculator
Impose additional foreign-transaction fees
depending on the card product and transaction.
Mastercard similarly advises cardholders to contact their issuing financial institution to determine the conversion charges applicable to foreign transactions.
Therefore merchants should avoid saying:
“Visa charged you $3.”
or:
“Your bank kept $3.”
without evidence.
Find the responsible layer first.
Fees May Not Behave Like Principal
Suppose the customer's original statement contains:
Transaction equivalent: $105
Foreign-transaction fee: $3
Total statement impact:
$108
The merchant may refund the full underlying €100 purchase.
That does not automatically prove how the customer's issuer will treat the separate $3 issuer fee.
Issuer fee policy depends on the card product and issuer terms.
The merchant should not promise:
“Every bank fee will also be refunded.”
unless that behavior is verified.
The correct customer-support response is to distinguish:
merchant refund
from:
issuer-applied charges.
FX Difference vs Missing Refund Amount
Support teams should classify these complaints correctly.
FX difference
Merchant records:
Original transaction: €100
Refund: €100
Provider confirms:
Refund successfully processed
Customer sees:
Different USD equivalent
Likely investigation:
Currency conversion / issuer account treatment
Missing refund principal
Merchant records:
Original transaction: €100
Refund: €90
Customer expected full refund.
This is not merely an FX issue.
The merchant refunded only 90% of the original transaction currency.
Refund not completed
Merchant records:
Refund requested
Provider status:
Failed / pending / unknown
This is also not primarily an FX issue.
The customer may not yet have a completed refund.
The Refund FX Flow
The most useful way to explain the problem is to draw both directions.
Original Purchase
Merchant price
€100
↓
Transaction created
Currency:
EUR
Amount:
100
↓
Cross-currency processing
Conversion party:
Verify
Possible participants include:
Card network
Issuer
DCC provider
Merchant/provider under another currency model
↓
Conversion rate
Rate A
Timestamp A
↓
Customer account debit
Example:
$108
Refund
Merchant refund
€100
↓
Refund transaction
Currency:
EUR
Amount:
100
↓
Refund processing
Network/provider/issuer flow
↓
New currency conversion where applicable
Conversion party:
Verify
Rate B
Timestamp B
↓
Customer account credit
Example:
$105
Where Did the $3 Go?
The correct answer is not automatically:
The merchant kept it.
The merchant investigation asks whether:
€100 was originally charged.
€100 was actually refunded.
Refund completed successfully.
EUR was converted to USD on both legs.
Conversion rates differed.
Issuer fees affected either leg.
Any other payment-system adjustment occurred.
Only then can the merchant explain the difference responsibly.
A Four-Currency Investigation Model
Some payment environments can be even more complicated.
Track separately:
Original transaction currency
The currency the customer was charged in.
Example:
EUR
Customer account currency
The currency of the card/account statement.
Example:
USD
Merchant settlement currency
The currency in which the acquirer/PSP accounts for or settles merchant proceeds.
Example:
Potentially EUR, USD or another supported currency depending on arrangement.
Merchant reporting currency
The currency finance uses for consolidated reporting.
Example:
USD
These do not need to match.
A refund investigation should not infer one from another.
Refund Currency vs Settlement Currency
Suppose the merchant:
Charges:
€100
but its PSP converts settlements into:
USD
Merchant's treasury may therefore have received a USD-equivalent amount from the original sale.
That does not mean the customer's refund should necessarily be denominated in USD.
The customer-facing refund is linked to the original payment transaction and provider/network rules.
The merchant's settlement accounting is a separate layer.
This distinction prevents a common mistake:
“We received USD, so we should refund USD.”
Do not change refund currency merely because merchant settlement uses another currency unless the provider/payment-system arrangement specifically supports and requires that behavior.
Merchant Settlement Adjustment
When the merchant refunds a transaction, the PSP/acquirer may reflect that value through:
Current settlement
Future settlement
Merchant balance
Reserve
Bank debit
depending on the provider arrangement.
Finance might therefore see:
Original sale:
€100 customer transaction
Merchant reporting:
USD settlement equivalent
Later refund:
€100 refund
Merchant reporting:
Different USD-equivalent adjustment
The merchant itself can therefore experience an FX-related difference between:
original settlement value
and:
refund adjustment value
even while refunding the exact same €100 to the customer.
That is merchant-side FX economics.
It should not be confused with the customer's USD statement difference.
Customer FX and Merchant FX Can Move Independently
Consider:
Customer:
EUR transaction → USD card account
Merchant:
EUR transaction → GBP settlement
Now one €100 purchase can create two independent FX relationships:
Customer
EUR → USD
Merchant
EUR → GBP
When refunded, both can have new economic equivalents.
Support cares primarily about:
customer EUR → USD
Finance may care about:
merchant EUR → GBP
Do not combine those into a single FX number.
Partial Refunds Add Another Layer
Suppose:
Original transaction:
€100
Merchant refunds:
€30
This is a:
30% transaction-currency refund.
If the customer's account is USD, the amount ultimately credited might be determined by the applicable conversion mechanism on the refund leg.
Do not promise:
“You will receive 30% of your original $108 debit.”
Thirty percent of $108 is:
$32.40
But a €30 refund converted later does not necessarily equal $32.40.
The merchant should communicate:
We refunded €30 of the original €100 transaction.
Then separately explain the customer's account conversion.
Partial Refund vs Proportional Home-Currency Refund
These two concepts should never be conflated.
Transaction-currency calculation
€30 ÷ €100
= 30%
Customer-statement calculation
Current converted value of €30
compared with:
Original converted value of €100
may not equal exactly 30% because the conversion conditions can differ.
The merchant's refund calculation should generally be audited in the transaction currency first.
Partial Refunds and Rounding
Partial refunds can also encounter:
Currency minor units
Provider rounding
Tax allocation
Discount allocation
Shipping refunds
Suppose three items share a discount.
A merchant may need to determine the exact refundable amount in original transaction currency before FX even becomes relevant.
Therefore the correct sequence is:
Determine legitimate transaction-currency refund.
Apply currency-minor-unit requirements.
Process refund.
Analyze downstream conversion separately.
Do not use the customer's current home-currency equivalent to calculate the merchant's refund amount unless that is explicitly how the original transaction was denominated.
Refund Timing Has Two Clocks
Customer support should distinguish:
Merchant refund initiation time
When merchant submitted the refund.
from:
Customer credit availability time
When the credit becomes visible or usable in the customer's account.
Between those events:
PSP
Acquirer
Network
Issuer
may process the refund.
That timing can matter to FX investigation because the relevant conversion timestamp may not simply equal the moment support clicked:
Refund.
Do Not Call a Pending Refund an FX Difference
Suppose the customer sees:
Original debit: $108
Temporary refund credit: $0
The first question is:
Has the refund actually completed?
not:
What exchange rate was used?
Investigate refund status before FX.
Recommended sequence:
Refund requested?
Provider accepted?
Refund processed?
Refund delivered into card/payment system?
Customer credit posted?
Only then investigate amount.
Customer Support Scenario 1: Full EUR Refund, Different USD Credit
Customer says:
“You charged me $108 and only refunded $105.”
Support retrieves:
Original transaction:
€100
Refund:
€100
Refund status:
Completed
Recommended explanation:
The original purchase and refund were both processed for €100. Because your card account is denominated in another currency, the amount shown in that currency can depend on the exchange rate and any issuer-specific currency treatment applying when each transaction is processed. Your card issuer can confirm the exact conversion applied to the statement credit.
This avoids:
Blaming issuer without evidence
Promising a rate
Claiming the merchant under-refunded
Customer Support Scenario 2: Customer Paid Through DCC
Suppose the original transaction was actually denominated:
$108
because the customer selected a home-currency conversion arrangement.
Now the merchant should not automatically explain the case as:
€100 was converted twice.
First inspect:
Original transaction currency
DCC data
Refund transaction currency
Provider's DCC refund rules
DCC is a separate conversion configuration and can have specific refund requirements.
Mastercard's current DCC guidance describes DCC as a service allowing eligible cardholders to choose between local and billing currency, with local-currency transactions otherwise converted by the issuer.
Do not apply ordinary foreign-currency refund assumptions to a DCC transaction without verifying the DCC rules and stored transaction data.
Customer Support Scenario 3: Merchant Refunded Only Part of the Transaction
Customer says:
“My FX refund is wrong.”
Records show:
Original:
€100
Refund:
€80
Do not send an FX explanation.
Investigate:
Restocking
Non-refundable fee
Partial return
Shipping
Merchant refund policy
Refund calculation
The missing €20 exists before currency conversion.
Customer Support Scenario 4: Customer Complains About a Foreign-Transaction Fee
The merchant refunded:
€100
Customer says their original issuer fee was not returned.
The merchant should distinguish:
Transaction principal
Merchant fees
Issuer fees
Visa states that banks may impose their own foreign-transaction fees in addition to currency conversion.
The merchant generally cannot determine another institution's fee-refund policy without specific evidence.
Recommend that the customer check the issuer's statement and terms or contact the issuer.
Customer Support Scenario 5: Refund Is Worth More Than Original Debit
FX does not always work against the customer.
Hypothetically:
Original €100 debit:
$105
Refund €100 later:
$109
That can occur if the currency relationship moves in the customer's favor under the relevant conversion mechanics.
The merchant should not claim the additional $4 is a merchant bonus.
It is another sign that:
transaction-currency equivalence
and:
home-currency equivalence
are different concepts.
Do Not Use Today's Google FX Rate to Prove a Refund Error
A customer or agent may search:
100 EUR in USD
and compare that number with the statement.
That is not sufficient evidence.
Public reference rates and consumer card rates can differ because:
Conversion time differs
Network methodology differs
Issuer methodology differs
Fees may apply
The ECB's euro reference rates are reference rates observed from market activity; they are not a guarantee that a particular cardholder transaction will use that exact commercial rate.
Similarly, Visa warns that a cardholder's bank may not use exactly the rate shown in Visa's own calculator.
Support should use transaction records—not a generic online converter—as the primary evidence.
Refund FX Investigation Checklist
Use this sequence.
What was the original transaction currency?
Record:
Currency:
Amount:
Do not start with statement currency.
What amount did the merchant refund?
Record:
Refund currency:
Refund amount:
Was it full or partial?
Formula:
Refund amount in transaction currency
÷ eligible original transaction amount
Was the same transaction currency used?
If not:
Escalate.
Understand why.
Which party converted the original debit?
Possible:
Network/issuer path
DCC provider
Merchant/PSP conversion arrangement
Verify rather than assume.
Which party converted the refund?
Do not assume it is identical to the first conversion without confirming the payment flow.
Did exchange conditions change?
Record:
Purchase processing timestamp
Refund processing timestamp
Applicable rate information where available
Were fees involved?
Separate:
Merchant amount
Issuer foreign-transaction fee
DCC markup
Other provider/bank charges
Does merchant settlement show the full refund?
Finance should reconcile:
Refund transaction
→ Provider adjustment
→ Settlement/balance effect
Refund Investigation Record
For support and payment operations:
Order ID:
Payment ID:
Provider transaction ID:
Purchase date:
Purchase amount:
Purchase currency:
Customer account currency, if known:
Refund ID:
Refund date:
Refund amount:
Refund currency:
Full/partial:
Provider refund status:
Original conversion party:
Refund conversion party:
Original FX rate, if available:
Refund FX rate, if available:
Issuer fee reported:
Merchant settlement adjustment:
Reconciliation status:
Customer explanation:
Escalation owner:
Preserve Original-Currency Data
This article's most important technical requirement is data retention.
Merchant systems should preserve:
Purchase
Original amount
Original currency
Transaction ID
Provider
Timestamp
Refund
Refund amount
Refund currency
Refund ID
Timestamp
Status
Financial data
Merchant settlement currency
Merchant settlement adjustment
FX data where provided
Fees
Do not convert everything into:
USD equivalent
and discard the original transaction currency.
That destroys the cleanest evidence of whether the refund was complete.
One Reporting Currency Is Not Enough
Finance may need all transactions expressed in USD or EUR.
That is useful for consolidated reporting.
But store both:
Native amount
€100
and:
Reporting equivalent
$X
with:
Rate
Rate source
Timestamp
The same applies to refunds.
Otherwise finance may compare:
Purchase reporting value:
$108
Refund reporting value:
$105
and incorrectly conclude:
$3 unreconciled
when €100 was fully reversed in transaction currency.
Reconciliation Should Start in Transaction Currency
For a full refund:
Original payment:
+€100
Refund:
−€100
Net transaction-currency value:
€0
That is the first reconciliation.
Then reconcile merchant settlement separately.
Example:
Original merchant settlement:
+USD equivalent A
Refund adjustment:
−USD equivalent B
Difference:
Potential merchant-side FX/fee effect
That difference belongs to finance.
It should not be confused with the customer account-credit difference.
The Refund Reconciliation Chain
Order
→ Payment ID
→ Original transaction amount/currency
→ Provider payment
→ Original settlement
→ Refund ID
→ Refund amount/currency
→ Provider refund
→ Settlement adjustment
→ Merchant bank/balance impact
If support can only see the order and finance can only see the bank settlement, both teams lack the evidence needed to explain FX refund cases confidently.
Track FX-Related Refund Tickets
Create a support reason such as:
REFUND_FX_DIFFERENCE
Do not put these tickets under:
REFUND_MISSING
unless the refund is actually missing.
Track:
FX-related refund ticket rate
FX-related refund contacts
÷ completed cross-currency refunds
This helps merchants understand whether the problem is:
Rare
Concentrated by issuer
Concentrated by market
Caused by confusing support messaging
Associated with a particular payment configuration
Refund Completion Time
Define:
Customer-credit confirmation timestamp
− merchant refund initiation timestamp
where reliable customer-credit confirmation is available.
If the merchant cannot observe final customer posting, use:
Provider-confirmed refund completion
and label it accordingly.
Do not claim to measure customer receipt if the system measures only PSP acceptance.
Partial-Refund Rate
Partial refunds
÷ completed refunds
Useful segmentation:
Country
Currency
Product
PSP
Merchant vertical
High partial-refund businesses need stronger refund-currency controls.
Refund Reconciliation Exception Rate
Refund records requiring manual financial investigation
÷ refund records expected to reconcile
Segment by:
PSP
Currency
Settlement currency
Merchant entity
This reveals whether multi-currency refund handling is creating finance operations cost.
Customer Amount-Difference Complaint Rate
Customer contacts alleging refund-value mismatch
÷ cross-currency refunds
Then categorize confirmed causes:
FX movement
Issuer fee
Partial merchant refund
Refund failed
Refund pending
DCC
Unknown
Do not label every complaint as an FX complaint before investigating it.
Customer Communication Before Purchase
Merchants cannot predict every customer's future exchange rate.
But they can avoid creating false expectations.
Where the customer is paying in a currency different from the account currency, merchants should avoid promises such as:
“You will always receive exactly the same dollar amount if refunded.”
unless that is contractually and technically guaranteed.
A safer principle is:
Refunds are issued according to the original transaction and refund policy; if your card/account uses another currency, the final converted amount may depend on your payment provider or issuer's currency treatment.
Legal and consumer-disclosure requirements should be reviewed for the relevant jurisdiction.
Customer Communication When the Refund Is Issued
Useful refund confirmation should include:
Refund amount: €100
Refund currency: EUR
Refund status: Submitted/processed
Refund reference: XXXXX
Where useful:
If your card or account is denominated in another currency, your financial institution may convert the refund when it posts to your account. The converted amount may differ from the amount originally shown in your account currency.
Do not say:
“Exchange rates changed, so there's nothing we can do.”
before confirming:
Full refund
Correct currency
Successful processing
Why Exact Currency Language Matters
Bad:
“We've refunded $105.”
if the merchant actually refunded:
€100
Better:
“We've refunded the full €100 transaction.”
Then, if necessary:
“Your card issuer determines how that credit appears in your account currency under its applicable conversion and fee treatment.”
This tells the customer what the merchant actually did.
Support Should Never Guess the FX Rate
If the merchant does not have:
Rate source
Conversion party
Timestamp
do not tell the customer:
“The exchange rate was 1.05.”
Instead state:
“Our records show the merchant refund was €100. We do not have authoritative visibility into the exact rate your issuing institution used for the account credit.”
Accuracy is better than false precision.
When the Merchant Should Escalate
Escalate to payment operations when:
Refund currency differs unexpectedly
Provider amount differs
Refund status is unclear
Customer reports no credit after normal processing window
DCC was involved
Multiple refunds exist
Refund exceeded or fell below expected transaction-currency amount
Provider FX data conflicts with reporting
Escalate to finance/reconciliation when:
Provider refund is complete
Merchant settlement adjustment is missing
Settlement currency amount cannot be reconciled
Fees are unexplained
Escalate to provider when:
Refund processing behavior is unclear
FX fields are inconsistent
Provider documentation and observed production behavior differ
Control Boundaries
A useful refund investigation identifies who controls what.
Merchant
Typically controls:
Refund decision
Refund amount
Refund initiation
Customer communication
Merchant records
PSP / Acquirer
May control:
Refund API
Processing
Acquiring submission
Merchant balance adjustment
Settlement reporting
Card Network
May control relevant:
Message processing
Currency-conversion mechanics
Network rules
Issuer
Controls or influences:
Customer account posting
Card-account currency treatment
Issuer-specific fees
Customer statement presentation
Customer
Controls:
Card/account selected
DCC choice where offered
Do not assign a dollar difference to one participant until the flow identifies that participant.
What the Merchant Can Promise
The merchant can often promise:
“We will refund the full eligible amount of your transaction in accordance with our refund policy.”
The merchant can verify:
Original transaction currency
Refund amount
Refund status
The merchant should be careful promising:
“The exact home-currency amount that appeared on your original statement will return.”
That outcome can depend on a later conversion process the merchant does not control.
What Evidence Would Prove a Merchant Under-Refund?
Strong evidence includes:
Original transaction:
€100
Merchant refund:
€95
with no policy-based reason for retaining €5.
Or:
Merchant intended:
€100
Provider processed:
€95
That is a payment/refund discrepancy.
What Evidence Does Not Prove an Under-Refund?
Alone, this does not prove it:
Original statement:
$108
Refund statement:
$105
You still need:
Transaction currency
Refund currency
Merchant refund amount
Provider refund status
The $3 difference is evidence that requires explanation.
It is not, by itself, proof of merchant short-refunding.
Special Case: DCC Refunds
DCC deserves separate treatment because the customer may have chosen to transact in the cardholder currency under a conversion service.
Mastercard's current DCC merchant guidance describes DCC as a currency-choice service provided through acquirers/merchants or ATM owners; when customers instead choose the merchant's local currency, currency conversion is handled through the issuer-side process.
For any DCC refund:
Verify:
Original transaction currency
Customer currency selection
DCC provider
Original DCC rate data
Refund requirements
Refund currency
Provider implementation
Do not assume the normal non-DCC refund flow applies.
Special Case: Multi-Currency Accounts
Some customers hold accounts that can maintain multiple currencies.
A customer might:
Pay €100
Have €100 debited directly from an EUR balance
There may be no customer-side FX conversion.
If that refund later returns:
€100
to the same EUR balance, the customer may receive exact currency equivalence.
This illustrates why merchants should not infer:
Customer country = customer account currency.
Special Case: Wallet Payments
A digital wallet may ultimately be funded by:
Card
Bank account
Wallet balance
Refund treatment depends on the wallet/payment arrangement.
Do not apply card-refund FX mechanics universally to every wallet.
Verify:
Wallet
Funding source
Refund destination
Currency
PSP
Special Case: Subscription Refunds
Suppose a subscriber paid:
€20/month
six months ago.
The merchant later refunds one billing period.
The original transaction should determine the relevant refundable currency amount.
Do not calculate the refund from:
today's USD equivalent of €20
unless that is explicitly how the subscription transaction was denominated.
The dedicated Multi-Currency Subscriptions article should own renewal-currency and currency-migration mechanics.
The Refund FX Flow Framework
Purchase side
Step 1 — Merchant price
Amount:
Currency:
Step 2 — Transaction
Amount:
Currency:
Step 3 — Customer-account conversion
Party:
From currency:
To currency:
Rate:
Timestamp:
Fee:
Step 4 — Customer debit
Amount:
Currency:
Refund side
Step 5 — Merchant refund
Amount:
Currency:
Full/partial:
Step 6 — Provider refund
Status:
Provider reference:
Processing timestamp:
Step 7 — Customer-account conversion
Party:
From currency:
To currency:
Rate:
Timestamp:
Fee:
Step 8 — Customer credit
Amount:
Currency:
Merchant financial side
Original settlement currency:
Original settlement amount:
Refund settlement adjustment:
Refund settlement currency:
Reconciliation status:
The FX Refund Investigation Checklist
What was the original transaction currency?
What amount did the merchant refund?
Was the refund full or partial?
Was the same transaction currency used?
Who converted the original customer debit?
Who converted the refund credit?
What dates or processing times governed each conversion?
Did the exchange rate change?
Were issuer, DCC, or other fees involved?
Does merchant settlement show the complete refund adjustment?
Only after those questions should support explain the home-currency difference.
Merchant Recommendation
When a customer says:
“I paid $108 but only got $105 back,”
do not begin by arguing about exchange rates.
Begin with the transaction.
Ask:
What currency did we actually charge?
Then:
What amount and currency did we actually refund?
If the merchant charged:
€100
and successfully refunded:
€100
the transaction-currency refund is complete.
The remaining question becomes:
How did €100 become one USD amount on the original debit and another USD amount on the refund credit?
Investigate:
Conversion party
Conversion time
Applicable rate
Issuer fees
DCC where applicable
The merchant should preserve enough data to answer those questions without guessing.
For customer communication, say what the merchant knows:
Original transaction amount
Original transaction currency
Refund amount
Refund currency
Refund status
And clearly separate what another participant controls:
Account conversion
Issuer fees
Statement posting
A fair refund is not always the same thing as home-currency symmetry.
For cross-currency transactions, the better standard is:
Did the merchant return the correct amount in the currency of the original transaction, and can every later difference be traced to an identified conversion, fee, or processing event?
That is a refund process finance can reconcile, support can explain, and customers can understand.
The brief’s strongest editorial move is to define refund fairness in the original transaction currency first. If the merchant charged €100 and correctly refunds €100, a later $3 difference on the cardholder statement is not automatically a merchant short-refund; the investigation has to identify who converted each leg, when, and under which rate/fee rules.
The most important operational upgrade from this article is to make original transaction amount + original currency + refund amount + refund currency mandatory fields in every refund escalation. Without those four values, support cannot tell whether it is investigating a genuine short-refund, a pending refund, a fee issue, or an FX difference.
Original Practical Asset: Refund FX Flow
Visual
Purchase
Merchant price
€100
↓
Transaction
€100 EUR
↓
FX conversion A
Party: issuer/network/DCC arrangement
Rate: A
Time: A
↓
Customer statement
$108
Refund
Merchant refund
€100
↓
Refund transaction
€100 EUR
↓
FX conversion B
Party: verify
Rate: B
Time: B
↓
Customer statement credit
$105
Central callout
€100 refunded = 100% transaction-currency refund
$108 → $105 difference = separate FX investigation
Measurement Plan
Track:
FX-Related Refund Ticket Rate
FX-value complaints
÷ completed cross-currency refunds
Refund Completion Time
Defined refund processing endpoint
− refund initiation
State whether endpoint is:
Provider completion
Customer posting
Partial-Refund Rate
Partial refunds
÷ completed refunds
Refund Reconciliation Exception Rate
Refunds requiring manual financial investigation
÷ refunds expected to reconcile
Customer Amount-Difference Complaint Rate
Refund-value complaints
÷ cross-currency refunds
Root-Cause Distribution
Classify:
FX movement
Issuer fee
DCC
Merchant partial refund
Refund processing failure
Settlement mismatch
Unknown
Editorial Interpretation
Customer currency problem
A customer buys something priced at:
€100
Their USD-denominated card account records approximately:
$108
The merchant later issues a full refund:
€100
The customer's card account eventually shows approximately:
$105
The customer concludes:
“You kept $3 of my refund.”
But the merchant's records may show:
Purchase: €100
Refund: €100
The missing explanation is the currency conversion between those amounts.
The €100 debit and €100 credit can enter the customer's USD account at different times, under different FX conditions, and potentially with different issuer or payment-system treatment.
Unique evidence anchor
A merchant can refund the exact original transaction amount and the customer can still receive a different amount in their home currency.
Editorial position
Refund correctness should be established first in the original transaction currency. Customer home-currency equivalence should then be investigated as a separate FX layer.
Merchants should:
Preserve the original transaction currency
Refund against the original transaction where possible
Record refund currency and amount
Explain which FX layers they control
Avoid promising an exact cardholder-account credit when downstream FX is outside their control
Common assumption challenged
“A full refund always puts the exact same amount back on the customer's bank statement.”
Merchant decision supported
This article helps merchants determine:
Whether a refund was actually complete
Which currency should be used for the refund
Where currency conversion occurred
Whether FX movement explains a customer-value difference
Whether a fee or missing refund amount needs separate investigation
How partial refunds should be explained
What data support teams need
What finance should reconcile
What merchants can—and cannot—promise customers
Selected format
Reverse currency-flow investigation
Structural rationale
The original payment is followed forward:
Merchant price
→ Transaction currency
→ Customer-account conversion
→ Customer debit
Then the refund is followed backward:
Merchant refund
→ Original transaction currency
→ Network/provider/issuer processing
→ New customer-account conversion
→ Customer credit
Every stage asks:
Currency? Amount? Conversion party? Rate? Timestamp?
That keeps the article separate from:
How to Prevent Unexpected FX Charges, which owns pre-purchase FX surprises
Presentment Currency vs Settlement Currency, which owns the broader currency-layer architecture
Subscription Billing in Multiple Currencies, which owns recurring currency behavior
Local Refund Expectations, which owns broader refund timing and customer expectations
SEO Metadata
Recommended SEO title
Refunds and Currency Conversion: Why Refund Amounts Change
H1
Refunds and Currency Conversion: Why Customers May Receive a Different Home-Currency Amount
Alternative titles
Foreign-Currency Refunds: Why the Amount Can Change
Card Refund Exchange Rates Explained for Merchants
Why International Refunds Can Be Worth Less—or More
FX and Ecommerce Refunds: A Merchant Guide
Foreign-Currency Card Refunds and Exchange Rates
Meta description
Learn why a merchant can refund the full original foreign-currency transaction while the customer's home-currency credit differs because of FX timing, rates or issuer treatment.
URL slug
/refunds-currency-conversion
refunds and currency conversion
Secondary keywords
foreign currency refund
exchange rate refund
refund currency conversion
ecommerce FX refund
card refund exchange rate
international payment refund
multi currency refund
foreign transaction refund amount
Related entities
Foreign exchange
FX
Refund
Card refund
Transaction currency
Cardholder billing currency
Settlement currency
Presentment currency
Issuer
Acquirer
PSP
Dynamic Currency Conversion
Foreign transaction fee
Partial refund
Reconciliation
Article excerpt
A merchant can refund the full original transaction and the customer can still see a different amount in their home currency. This guide traces the purchase and refund FX flows to show where the difference comes from and how merchants should investigate it.
Search intent
Post-payment FX explanation and operational guidance.
Suggested Structured Data
Use:
Article
TechArticle where consistent with site strategy
BreadcrumbList
The customer-support scenarios are better presented as article content than generic FAQ markup.
Internal-Link Recommendations
How to Prevent Unexpected FX Charges
Anchor ideas:
foreign-transaction fees
preventing unexpected FX costs
how customers encounter FX charges
Use for the purchase-side experience.
Presentment Currency vs Settlement Currency
Anchor ideas:
transaction currency versus settlement currency
payment currency layers
Use where readers need the broader currency architecture.
Local Refund Expectations
Anchor ideas:
refund timing expectations
communicating international refunds
Use for broader post-purchase customer experience.
Multi-Currency Subscriptions
Anchor ideas:
subscription refunds in foreign currencies
recurring billing currencies
Use for recurring transactions.
Additional links
Dynamic Currency Conversion Explained
Multi-Currency Pricing Explained
Authoritative Source Recommendations
Card-network FX mechanics
Use current:
Visa foreign-exchange documentation
Visa exchange-rate calculator documentation
Mastercard currency-conversion documentation
Current network rules where refund mechanics require precise rule interpretation
Visa currently distinguishes transaction currency and cardholder billing currency in its foreign-exchange tooling and warns that issuers may apply different billing treatment or additional fees.
Mastercard likewise directs cardholders to their issuing financial institution for institution-specific foreign-currency conversion charges.
Reference FX data
Use:
European Central Bank
Relevant central banks
The ECB publishes euro reference exchange rates on working days, making it useful for demonstrating that currency values change over time—but those reference rates should not be presented as guaranteed consumer card rates.
Merchant evidence
The strongest operational evidence should come from:
PSP transaction record
Refund API record
Network/provider FX fields where available
Settlement data
Merchant bank reconciliation
Support cases
Proposed Author and Human Review
Proposed author
Payment operations lead or international payments specialist
Relevant experience:
Refunds
Cross-currency payments
Provider operations
Customer escalation
Do not invent a person or credentials.
Required reviewer: Finance / reconciliation specialist
Review:
Settlement
Refund adjustment
Original-currency reconciliation
Reporting currency
Required reviewer: Customer support leader
Review:
Scenario accuracy
Customer language
Escalation rules
Required reviewer: Treasury / payments specialist
Review:
FX terminology
Rate timing
Customer versus merchant FX
Strongly recommended: Card/acquiring specialist
Review:
Refund message flow
Network-specific behavior
DCC cases
Currency-Support Fact-Check Items
Verify:
Original transaction currency
Refund currency
Customer account currency where actually known
Settlement currency
Payout currency
Reporting currency
Do not infer one from another.
FX Fact-Check Items
Verify:
Original conversion party
Refund conversion party
Original rate where available
Refund rate where available
Conversion timestamp
Explicit fee
Issuer fee where customer provides evidence
DCC
Merchant/provider conversion
Never claim one universal card FX rate exists.
DCC Fact-Check Items
Where applicable verify:
DCC was actually used
Customer selection
Original DCC currency
Original DCC rate
Markup
Stored rate data
Refund rules
Provider implementation
Current network requirements
Do not extrapolate DCC refund mechanics from ordinary cross-currency transactions.
Settlement Fact-Check Items
Verify:
Original merchant settlement
Refund funding source
Refund settlement adjustment
Settlement currency
FX applied to merchant side
Fees
Reserves
Reconciliation status
Customer FX and merchant settlement FX should remain separate.
Refund Fact-Check Items
Verify:
Refund amount
Refund currency
Full/partial
Original-payment link
Refund status
Refund processing date
Provider reference
Partial-refund calculation
Failed refund behavior
Wallet/payment-method-specific behavior
Conversion / Incrementality Fact-Check Items
This article is not primarily a conversion article.
But where refund experience is connected to commercial outcomes, verify:
FX-related support contacts
Repeat purchase
complaint rates
refund abandonment where relevant
customer service cost
Do not claim better FX explanations increase conversion without merchant evidence.
Regulatory and Consumer-Protection Fact-Check Items
Before adding jurisdiction-specific language, verify:
Refund rights
Refund timing
DCC rules
FX disclosures
Consumer pricing requirements
Card-network rules
Issuer obligations
Distinguish:
Law
Network rule
Issuer policy
Provider rule
Merchant policy
This article provides general information and does not constitute legal, regulatory, tax, financial, or accounting advice. Merchants should verify current requirements and network/provider rules with qualified advisers, payment providers, acquirers, card networks, banks, and relevant authorities.
Amber-Flag Claims
Require direct evidence before publishing:
“The issuer used today's exchange rate.”
“Visa caused the $3 difference.”
“The bank kept the difference.”
“Foreign-transaction fees are never refunded.”
“All refunds use the current exchange rate.”
“All card refunds use the original rate.”
“A full refund always uses the original transaction currency.”
“DCC refunds always reverse at the original rate.”
“The merchant has no control over refund FX.”
“The customer will receive exactly €100 equivalent.”
“Settlement FX caused the customer difference.”
Every claim should identify:
Network/provider
Currency
Transaction type
Geography
Configuration
Effective rule/date
Original transaction-currency storage
Refund API behavior
Full refunds
Partial refunds
Supported refund currencies
Original-payment linkage
Refund status
FX fields
DCC support
Original-rate retention
Refund-rate treatment
Settlement adjustment
Refund reporting
Reconciliation
Cross-currency refunds
Wallet refunds
Async method refunds
Support tooling
Customer refund references
Any quantified refund timing
Provider / Network Verification Template
Provider:
Network/payment method:
Country:
Merchant entity:
Original transaction ID:
Original transaction amount:
Original transaction currency:
Customer billing currency:
Original conversion party:
Original FX rate:
Original processing timestamp:
DCC: Yes / No
Refund ID:
Refund amount:
Refund currency:
Full/partial:
Refund conversion party:
Refund FX rate:
Refund processing timestamp:
Issuer fee:
Merchant settlement currency:
Merchant refund adjustment:
Provider status:
Customer credit confirmed:
Rule/source:
Last verified:
Cluster Sameness-Audit Fields
Title
Refunds and Currency Conversion: Why Customers May Receive a Different Home-Currency Amount
Opening device
Customer pays €100, sees $108 on the card statement, receives a €100 refund that appears as $105, and asks where $3 went.
Primary format
Reverse currency-flow investigation.
Unique evidence anchor
A full transaction-currency refund can produce a different home-currency account credit.
Editorial position
Establish refund fairness in original transaction currency before investigating downstream FX.
Merchant decision
Determine whether a customer complaint reflects an incomplete merchant refund, FX movement, issuer fees, DCC behavior, or processing failure.
Main analytical unit
One purchase and its refund traced through every currency conversion.
Original framework
Refund FX Flow.
Secondary framework
FX Refund Investigation Checklist.
Primary metrics
FX-related refund ticket rate
Refund completion time
Partial-refund rate
Refund reconciliation exception rate
Amount-difference complaints
Conclusion
The customer statement amount and merchant refund amount are different layers; reconcile the transaction currency first and explain home-currency FX separately.
Closing element
Customer-support scenarios and investigation checklist rather than a generic FAQ.
Topics intentionally owned elsewhere
Pre-purchase FX surprises
Full currency-layer architecture
Subscription currency strategy
General local refund expectations
DCC mechanics
2nd version
Refunds and Currency Conversion: Why Customers May Receive a Different Home-Currency Amount
The customer paid €100.
Their card statement showed a debit of $108.
The merchant later issued a full refund of €100.
The customer's statement eventually showed a credit of $105.
The customer contacts support:
“You owe me another $3.”
Did the merchant under-refund the transaction?
Possibly—but the statement alone does not prove it.
The first question is not “What exchange rate should we use?”
It is:
What amount and currency did the merchant originally charge, and what amount and currency did the merchant actually refund?
If the transaction was €100 and the merchant correctly refunded €100 through the original transaction, the merchant may have returned 100% of the merchant-side transaction even though the customer's home-currency credit differs from the original debit.
The difference can arise because the original card purchase and the later refund do not necessarily encounter the same currency conversion conditions.
That makes international refunds a reverse-payment investigation.
You follow the money backward.
A full refund can still produce a different statement amount
Consider this hypothetical transaction.
Purchase
Merchant price: €100
Transaction currency: EUR
Customer card/account currency: USD
Converted customer debit: $108
Refund several weeks later
Merchant refund: €100
Refund transaction currency: EUR
Converted customer credit: $105
The merchant has refunded:
€100 of €100 = 100% of the transaction amount.
But the customer has received:
$105 against an original $108 statement debit.
Both statements can be true.
The missing step is currency conversion.
Cross-border card transactions can involve conversion between the transaction currency and the cardholder's billing currency. Mastercard's current rules describe its currency-conversion rate as tied generally to the transaction date, with processing-date treatment possible in some circumstances. Visa likewise notes that its cardholder FX calculation may use its applicable network rate while the issuer can apply its own treatment or additional foreign-transaction fees.
A refund occurring later is a separate financial event.
If a fresh conversion is performed between EUR and USD, the resulting USD value need not reproduce the earlier USD value.
So the merchant must separate two questions:
Did we return the correct amount?
from:
What was that amount worth after downstream conversion?
Start with the currency the merchant actually charged
The first record to retrieve is not the customer's bank statement.
It is the merchant's original payment record.
At minimum, establish:
original transaction amount
original transaction currency
payment ID
payment method
authorization/capture identifiers where applicable
transaction date
whether DCC was used
refund amount
refund currency
refund date
provider refund ID
For card payments, transaction currency is an actual processing field, not simply what a page happened to display. Visa's April 2026 rules state that an original presentment enters interchange in the authorized transaction-currency amount.
That distinction immediately eliminates one common support mistake.
A website might have displayed:
Approximately $108
while the payment was actually created and processed as:
€100 EUR
In that case, $108 was not necessarily the merchant's transaction amount at all.
It may have been:
an indicative display
an issuer-converted amount
a network-converted amount
a DCC amount, depending on the transaction
Those possibilities produce very different refund investigations.
Do not call every number “the payment currency”
An international refund can involve several currencies.
Catalog currency
The currency in which the merchant maintains its product price.
Display currency
The currency the customer sees while shopping.
Transaction or presentment currency
The currency in which the payment is actually submitted.
Customer account or billing currency
The currency in which the customer's issuer maintains or reports the account.
Settlement currency
The currency in which the PSP/acquirer settles transaction economics into the merchant's balance or settlement process.
Payout currency
The currency ultimately delivered to the merchant's bank account.
Sometimes every layer uses EUR.
Sometimes a transaction looks more like:
USD catalog
→ EUR transaction
→ GBP cardholder account
→ EUR merchant settlement
→ USD merchant treasury reporting
A refund complaint cannot be diagnosed accurately until those layers are separated.
Who converted the original purchase?
The next question is:
How did €100 become $108?
There is no universally correct answer called “the exchange rate.”
Different participants may perform currency conversion under different transaction structures.
For an ordinary foreign-currency card transaction, the card-network/issuer path may convert the transaction into the cardholder's billing currency.
Mastercard's published rules describe its currency-conversion process as using rates observed in wholesale markets or government-mandated rates where applicable, while also requiring issuers to disclose certain cross-border or conversion assessments they impose on cardholders.
Visa's current exchange-rate guidance similarly warns that the cardholder's bank may use different billing treatment and may impose additional foreign-transaction fees; it also distinguishes issuer/network conversion from situations where the merchant or ATM performs the conversion.
That gives the merchant a useful diagnostic split:
Path A: merchant charges foreign currency
Merchant submits €100
→ network/issuer conversion
→ customer account debited in USD
Path B: DCC
Merchant price exists in local currency
→ customer accepts conversion into billing currency
→ DCC provider/acquirer determines disclosed converted amount
→ transaction occurs in the selected currency
These paths should not be treated as equivalent.
Reference FX rates do not tell you what the customer was actually charged
Support teams sometimes try to solve the complaint by opening a public currency converter.
That can be useful for understanding whether currencies moved.
It cannot prove the actual transactional rate.
The European Central Bank explicitly describes its euro FX rates as reference rates intended for informational purposes rather than rates for settling market transactions.
Similarly, card networks and issuers may have their own applicable rate methodologies.
Therefore this calculation:
€100 × today's public EUR/USD rate
does not answer:
What conversion did the customer's card account receive?
The correct investigation uses transaction records first.
Reference-market data can provide context later.
Now follow the refund backward
Once the original purchase has been reconstructed, reverse the chain.
Suppose the merchant's system shows:
Original capture:
€100 EUR
Refund:
€100 EUR
Then ask:
Did the provider accept the €100 refund?
Check the refund object's:
amount
currency
status
linked payment
refund ID
processing timestamp
Did the refund proceed through the original payment path?
A properly linked refund is operationally different from a merchant separately sending money to the customer.
What currency entered the card-payment refund process?
If it remained €100 EUR, the merchant-side refund amount can be tested directly against the original charge.
Was another conversion required before the credit reached the customer's account?
If the customer's account is USD, then usually some mechanism still has to map the EUR refund into the account currency unless the account itself can hold the credited currency under its own rules.
That conversion is where the home-currency amount can diverge.
Why the second conversion can produce another amount
Return to the hypothetical example:
Purchase:
€100 → $108
Refund later:
€100 → $105
The merchant should resist the temptation to say:
“The exchange rate changed.”
until it verifies what happened.
Several explanations are possible.
FX rates moved
EUR/USD may have changed between the relevant purchase and refund conversion events.
Different conversion timestamps were used
Payment systems do not all define the applicable conversion timestamp identically. Mastercard's current published rules, for example, describe transaction-date conversion with processing-date treatment possible in specified delayed-processing circumstances.
Issuer treatment differed
The cardholder's bank controls parts of the account-level billing experience. Visa specifically notes that an issuer may not use the rate shown in Visa's calculator and may impose additional charges depending on the card product.
Fee treatment differed
A fee that appeared with the purchase may or may not be reversed with the refund depending on the issuer, card product, jurisdiction, and transaction structure.
The merchant should not promise that a foreign-transaction fee will automatically be returned.
The transaction used DCC
That creates a different rules path and should be investigated separately.
The merchant's job is therefore not to choose the most convenient explanation.
It is to identify the actual conversion path.
Full transaction-currency refund versus home-currency restoration
This is the article's central distinction.
Transaction-currency question
Customer bought:
€100
Merchant refunded:
€100
Merchant-side refund rate:
100%
Home-currency question
Customer was debited:
$108
Customer was credited:
$105
Home-currency recovery:
not identical to original statement debit
Those measurements answer different questions.
The first assesses whether the merchant returned the original sale amount.
The second describes what happened after conversion into another currency.
A customer can therefore have a legitimate question about the $3 difference without the merchant necessarily having short-refunded the €100 payment.
Good customer support acknowledges both facts.
Do not confuse refund currency with settlement currency
Suppose:
Customer transaction: €100
Merchant settlement currency: USD
Provider settlement equivalent: $X
Later refund: €100
The merchant may see a USD-denominated settlement adjustment related to that refund.
That does not mean the customer was “refunded in USD.”
The customer refund path and merchant settlement path are separate accounting relationships.
A useful internal model is:
Customer transaction currency
≠ necessarily
customer account currency
≠ necessarily
merchant settlement currency
≠ necessarily
merchant reporting currency
For merchant finance, the refund might create an FX gain or loss relative to the original reporting or settlement value.
For the customer, an entirely different currency effect may appear.
Do not merge the two.
DCC refunds are a special case
Dynamic Currency Conversion deserves explicit separation because the cardholder has chosen a converted transaction currency at the merchant/acquirer side rather than simply allowing an issuer-side conversion to occur later.
Visa describes DCC as a choice between the merchant/local currency and the cardholder's home/billing currency, with the DCC offer required to disclose conversion information and preserve customer choice.
Mastercard's 2025 merchant DCC guidance is especially relevant to refunds. It says DCC refunds must remain aligned with the original transaction currency and provides specific permitted approaches, including reversing the original transaction or matching the original DCC amount/rate as specified in its standards.
That creates an important boundary:
Do not apply the ordinary “the rate may simply be different on the refund date” explanation to a DCC complaint until the DCC refund has been checked against the applicable network and acquirer rules.
A badly processed DCC refund can create a second conversion that should not have occurred.
That is an operational defect—not merely ordinary FX movement.
The Refund FX Flow
Original purchase
Merchant price
↓
Final transaction amount and currency
Example: €100 EUR
↓
Identify conversion model
If ordinary foreign-currency transaction:
Issuer/network-side conversion as applicable
↓
Customer account debit
Example: $108 USD
If DCC:
DCC offer
↓
Customer selects transaction currency
↓
Disclosed DCC conversion
↓
Customer account debit
Refund
Merchant refund decision
↓
Refund linked to original payment
↓
Refund amount and transaction currency
Example: €100 EUR
↓
Provider / network refund processing
↓
Identify conversion model again
↓
Account-level conversion if applicable
↓
Customer account credit
Example: $105 USD
Attach four fields to every conversion event
For investigations, preserve or obtain where available:
Converting party
Merchant/DCC provider, network, issuer, or another participant.
Currency pair
For example EUR → USD.
Applicable rate or resulting converted amount
Where the party exposes it.
Timestamp / processing date
So finance and support know which point in time the rate belongs to.
Without those four fields, “the FX was wrong” is difficult to prove or disprove.
Partial refunds make the home-currency comparison even less intuitive
Suppose:
Original purchase:
€100
Customer statement:
$108
Merchant later refunds:
€30
It is tempting to tell the customer:
“You should get 30% of $108, or $32.40.”
That is not a safe promise.
If the €30 refund goes through a new conversion event, the customer's account credit depends on the mechanics and rate applicable to that refund.
The correct merchant-side test is:
Original purchase:
€100 EUR
Partial refund:
€30 EUR
Therefore:
30% of the original transaction currency has been refunded.
Then separately investigate the customer's converted credit.
This distinction becomes especially important for:
travel cancellations
multi-item ecommerce orders
partial returns
marketplace orders
hospitality adjustments
multiple sequential refunds
Do not aggregate the problem exclusively in the customer's billing currency.
Multiple partial refunds require transaction-level lineage
Imagine an order for €200.
The merchant processes:
Refund 1: €40
Refund 2: €25
Refund 3: €15
The customer may see three home-currency credits produced on different dates.
Their sum may not reproduce the same home-currency proportion of the original card debit that a simple historical-rate calculation suggests.
Merchant reporting should therefore preserve each refund independently:
Record
Transaction currency
Amount
Processing date
Payment link
Purchase
EUR
200
T0
Payment P1
Refund 1
EUR
40
T1
P1
Refund 2
EUR
25
T2
P1
Refund 3
EUR
15
T3
P1
Then preserve settlement adjustments separately.
Do not replace those source-of-truth amounts with one converted accounting number.
FX difference versus missing refund
Customer support must distinguish two completely different incidents.
Case A: refund amount is correct; home-currency value differs
Original transaction:
€100
Refund:
€100
Customer account values differ after conversion.
Investigation: FX/conversion path.
Case B: merchant actually refunded too little
Original transaction:
€100
Refund:
€90
Investigation: refund amount.
No amount of FX explanation fixes Case B.
This is why the first support question should be:
What exact amount and currency does our refund record show?
not:
What does Google say EUR/USD is today?
Customer communication: explain what the merchant knows
Poor response:
“Exchange rates fluctuate. Contact your bank.”
That may be directionally relevant but tells the customer almost nothing.
Better support messaging separates verified facts from the part controlled by another participant.
For example:
“Your original purchase was €100 EUR, and our payment record shows that we returned the full €100 EUR to the original payment method. Your card account is denominated in USD, so a currency conversion also appears between the EUR transaction and the USD amount on your statement. That conversion is separate from the €100 amount we refunded. Your card issuer can confirm the rate and any issuer-level fees applied when the refund posted.”
That answer does four useful things:
identifies the original transaction currency;
states the merchant refund amount;
distinguishes merchant refund from account conversion;
avoids promising an FX outcome the merchant does not control.
If the transaction involved DCC, support should not use this generic script until the DCC-specific refund treatment has been verified.
What support should never promise
Avoid statements such as:
“You'll receive exactly the same dollar amount.”
“The bank will refund the FX fee.”
“The exchange rate will be today's rate.”
“Visa/Mastercard always uses the refund-date rate.”
“A smaller home-currency credit means your bank charged a fee.”
“The missing amount is just currency fluctuation.”
Each can be wrong depending on:
card network
issuer
card product
processing timing
DCC
provider
transaction structure
country
Support should describe only the layers it can verify.
The FX Refund Investigation Checklist
When a customer reports an unexpected refund value, investigate in this order.
What was the original transaction currency?
Retrieve it from the payment record.
What was the original transaction amount?
Use the processed transaction—not an approximate display value.
What amount did the merchant refund?
Confirm exact numeric amount.
Was it full or partial?
Compare in the original transaction currency.
Was the refund processed in the expected transaction currency?
Check the refund object and applicable provider/network rules.
Who converted the original purchase?
Determine whether this was:
ordinary network/issuer FX
DCC
another merchant/provider conversion model
Who converted the refund?
Do not assume it was the same party until verified.
Did the conversion conditions differ?
Check timestamps and available rate data.
Were fees involved?
Separate:
network/provider conversion
issuer foreign-transaction fee
DCC markup
merchant/provider fee
Do not combine them under “FX fee.”
Does merchant settlement show the full refund adjustment?
Finance should be able to tie the refund back to the original transaction and settlement record.
Reconciliation should preserve both sides of the transaction
An international refund should be traceable through:
Merchant order ID
→ payment ID
→ original transaction amount
→ original transaction currency
→ capture date
→ refund ID
→ refund amount
→ refund currency
→ refund processing status
→ settlement adjustment
→ settlement currency
→ payout/reporting entry
Where provider data allows, also retain:
network/acquirer references
original capture reference
refund reference
DCC indicator
customer-facing currency
settlement FX information
reporting/base-currency equivalent
The design principle is simple:
Never throw away the original-currency amount just because finance ultimately reports everything in one base currency.
Once the original amount disappears, an FX complaint becomes much harder to investigate.
Merchant finance should track its own FX effect separately
The customer's FX experience is only half of the story.
Suppose the merchant sold:
€100
but ultimately accounts in:
USD
The original sale may have produced one reporting/base-currency value.
The refund weeks later may produce a different economic adjustment.
Depending on the merchant's settlement and provider arrangement, the merchant may therefore experience its own currency effect even though both customer-facing transaction records are €100.
That is a treasury/accounting question separate from whether the customer was fully refunded.
A merchant dashboard should ideally avoid one ambiguous field called:
refund value
and instead maintain:
refund amount in transaction currency
settlement adjustment in settlement currency
accounting equivalent in reporting currency
That allows Payments, Finance, and Support to discuss the same event without talking about three different numbers as if they were one.
Refund completion time matters because FX complaints often arrive before reconciliation does
A customer may contact support when:
the merchant has created the refund;
the provider has accepted it;
but the issuer has not yet posted the final credit.
That situation should be classified separately from an FX-value complaint.
Useful refund states include merchant-defined equivalents of:
requested
→ submitted
→ processing
→ completed/confirmed where exposed
→ reconciled
Do not tell the customer that an amount discrepancy exists until the refund has actually reached the relevant account state.
Similarly, do not treat “refund API call succeeded” as proof that every downstream posting stage has completed unless the provider's documented state means exactly that.
What merchants should measure
FX refunds are usually treated as support noise.
They should be measurable.
FX-related refund contact rate
Customer contacts mentioning FX/refund-value differences
÷ completed cross-currency refunds
This indicates whether currency expectations are producing confusion.
Refund completion time
Elapsed time from the merchant's defined refund-submission event to the best available authoritative completion event.
Define the start and end events.
Partial-refund rate
Partial refunds
÷ all refunds
This identifies businesses where proportional home-currency expectations may generate more support issues.
Refund reconciliation exception rate
Refunds requiring manual finance investigation
÷ processed refunds
Amount-discrepancy complaint rate
Refund contacts alleging an incorrect amount
÷ cross-currency refunds
Then classify each complaint:
actual merchant under-refund
ordinary FX difference
DCC/refund processing problem
fee issue
refund not yet completed
unmatched/unknown
That classification turns anecdotal complaints into an operational dataset.
The merchant-control map
Merchant controls or can usually influence
original product price
transaction currency offered
refund amount requested
refund timing
refund initiation
customer communication
transaction/refund data retention
reconciliation
provider choice
DCC participation/configuration where offered and contractually available
PSP/acquirer/provider may control
refund API behavior
supported refund currencies
transaction linkage
settlement adjustment
DCC implementation
reconciliation data
downstream routing
Card network may control
applicable network rules
transaction messaging
network conversion methodology where network FX is involved
DCC standards
Issuer may control
cardholder account posting
issuer currency conversion treatment
foreign-transaction charges
account-specific fee treatment
customer statement presentation
The exact boundary depends on the payment architecture.
The merchant should therefore communicate responsibility based on evidence, not assumptions.
Customer-support scenarios
“You refunded me $3 less than I paid.”
First check whether the transaction was actually denominated in dollars.
If it was €100 and the merchant refunded €100, explain the transaction-currency refund and investigate the conversion separately.
If the original transaction was $108 and the merchant refunded $105, this is not merely the same situation. The merchant refund itself may be incomplete.
“Why did I receive more than I originally paid?”
The same mechanism can work in the opposite direction.
If a foreign-currency amount is converted again after exchange rates move, the home-currency credit may be higher than the earlier debit.
Do not try to “correct” a transaction merely because the home-currency amounts differ before establishing the actual network/issuer treatment.
“Can you just refund the original dollar amount instead?”
Do not improvise a second payment solely to force the customer's statement to match.
First use the supported refund mechanism connected to the original transaction and verify applicable provider/network requirements.
Creating a separate payout or transfer can introduce:
reconciliation problems
duplicate reimbursement
another currency conversion
fraud risk
accounting complexity
Escalate genuine discrepancies through the payment provider/acquirer rather than inventing an FX adjustment at support level.
“Will my foreign transaction fee be refunded?”
Do not promise that it will.
Issuer/card-product treatment can vary. Visa explicitly notes that banks can apply their own foreign-transaction fees to cross-border purchases.
The merchant can confirm its own transaction and refund amounts.
The issuer should confirm issuer-level fee treatment.
“I used DCC. Why did the refund convert again?”
Treat this as a DCC-specific investigation.
Mastercard's current merchant guidance requires DCC refunds to preserve the original transaction currency and defines mechanisms designed to prevent a second conversion loss.
Verify:
original DCC currency
original converted amount
refund currency
refund processing type
original rate data where required/available
acquirer/DCC-provider behavior
Do not dismiss the difference as ordinary FX movement.
What would disprove the “it's only FX” hypothesis?
Good payment operations should actively look for evidence that the simple explanation is wrong.
Escalate when:
refund amount in transaction currency is below the intended amount;
refund currency differs unexpectedly from the original transaction;
refund is not linked correctly;
DCC treatment does not satisfy current network/acquirer requirements;
settlement records do not show the expected adjustment;
duplicate or missing refunds appear;
provider and merchant records disagree;
multiple customers show the same systematic discrepancy;
the issuer reports that the submitted refund amount itself was incorrect.
“FX moved” should be the result of an investigation—not the default answer before one begins.
Final recommendation
For international merchants, the safest definition of a full refund starts with the original transaction:
Did the merchant return the full amount of the transaction in the correct transaction currency through the appropriate refund path?
If yes, the customer may still see a different amount in their home currency when another conversion occurs downstream.
That difference deserves an explanation.
It does not automatically mean the merchant under-refunded the customer.
The operating model should therefore preserve four different facts:
what the customer bought
what currency the merchant charged
what amount and currency the merchant refunded
what happened when that refund reached the customer's account
Once those layers are separated, most “missing FX refund” investigations become much easier.
The principle is simple:
Judge refund completeness in the original transaction currency first.
Then investigate the conversion.
Do not promise home-currency equivalence when the merchant does not control it.
Practical asset: Refund FX Flow
ORIGINAL PURCHASE
Merchant price
↓
Transaction currency and amount
↓
Who converts?
↓
Rate + timestamp
↓
Customer account currency
↓
Customer debit
REFUND
Merchant refund decision
↓
Refund amount
↓
Refund currency
↓
Provider/network path
↓
Who converts?
↓
Rate + timestamp
↓
Customer account currency
↓
Customer credit
MERCHANT-SIDE PARALLEL TRACK
Original payment
→ settlement currency
→ settlement amount
→ refund adjustment
→ merchant reporting currency
Diagnostic rule
If:
original transaction amount = €100
and
merchant refund amount = €100
but
home-currency debit ≠ home-currency credit
investigate the conversion path before classifying the refund as short.
Editorial interpretation
The currency decision this article owns: how an international merchant should determine whether a refund was financially correct when the original transaction currency differs from the customer's account currency.
The customer payment problem: the merchant can return the entire purchase amount while the customer's statement shows a smaller—or larger—home-currency credit than the original debit.
The merchant currency layer: primarily the original transaction currency and refund amount, while preserving settlement-currency information separately for finance and reconciliation.
The party controlling conversion: depends on the original transaction. It may be the issuer/network path, or a DCC/acquirer conversion path. The merchant must identify this rather than assume there was one universal “exchange rate.”
Unique evidence anchor: a full refund in the original transaction currency and full restoration of the customer's original home-currency statement amount are not necessarily the same thing.
Editorial position: refund fairness should first be tested in the original transaction currency. Downstream currency conversion should then be investigated separately.
Common assumption challenged: “A full refund always restores exactly what the customer originally saw on their bank statement.”
Most important technical distinction: refund amount versus converted refund value.
Selected format: reverse currency-flow investigation.
Merchant decision: preserve the original transaction currency and amount, use the correct linked refund path, retain enough currency data to trace conversion and settlement, and avoid promising an exact customer-account amount when conversion is controlled downstream.
Proposed architecture
A €100 refund that becomes $105
Start with the currency the merchant actually charged
Follow the original conversion
Follow the refund backward
Why the home-currency result can change
The DCC exception merchants must recognize
Partial refunds
Refund FX Flow
Customer-support investigation
Merchant reconciliation
Measurement
Final recommendation
SEO metadata
Refunds and Currency Conversion: Merchant FX Guide
H1:
Refunds and Currency Conversion: Why Customers May Receive a Different Home-Currency Amount
Meta description:
Learn why a full foreign-currency refund can produce a different amount on a customer's statement and how merchants should investigate FX, partial refunds and reconciliation.
URL slug:
/refunds-currency-conversion/
refunds and currency conversion
Secondary keywords:
foreign currency refund
exchange rate refund
refund currency conversion
ecommerce FX refund
card refund exchange rate
international payment refund
multi currency refund
foreign transaction refund amount
Related entities:
transaction currency
cardholder billing currency
foreign exchange
FX rate
settlement currency
Dynamic Currency Conversion
DCC
card refund
partial refund
reconciliation
foreign transaction fee
Article excerpt:
A merchant can refund the complete original transaction and the customer's home-currency credit can still differ from the original statement debit. The key is to separate refund completeness in the transaction currency from the downstream FX conversion that determines the customer's account value.
Suggested structured data:
Article
BreadcrumbList
FAQPage only if the customer-support scenarios are published as a visible FAQ section
Internal-link plan
How to Prevent Unexpected FX Charges
Link from the explanation of issuer fees, merchant conversion, and currency transparency.
Presentment Currency vs Settlement Currency
Link from the section distinguishing customer transaction currency from merchant settlement and payout.
Local Refund Expectations
Link from customer communication and refund-time expectations.
Subscription Billing in Multiple Currencies
Link when discussing refunds against recurring cross-currency charges.
Dynamic Currency Conversion Explained
Recommended additional link from the DCC-specific refund section.
Authoritative source recommendations
Visa Core Rules — April 2026
Use for current Visa transaction-currency and processing rules. The public rules distinguish the transaction amount/currency entered into interchange from subsequent settlement mechanics.
Visa Exchange Rate Calculator / FX documentation
Use for the distinction between Visa's conversion information and issuer-specific billing treatment, including the fact that an issuer may impose its own foreign-transaction fees.
Mastercard Rules — June 2026
Use for Mastercard's current currency-conversion methodology and issuer disclosure obligations.
Mastercard DCC Performance Guide — 2025 merchant edition
Use specifically for DCC conversion and DCC-refund treatment. Its current merchant guidance states that refunds must preserve the original DCC transaction currency and describes appropriate refund structures intended to avoid second-conversion losses.
European Central Bank reference-rate methodology
Use to explain why an ECB reference rate is useful for context but should not be presented as the actual cardholder transaction rate.
Bank of England exchange-rate data
Useful as an additional historical-market reference for sterling-based investigations, with the important qualification that the Bank itself says these are not authoritative commercial transaction rates.
Supporting visual
Refund FX Flow
Recommended design: horizontal “money forward / money backward” investigation.
Top row — Purchase
€100 merchant charge
→ Transaction currency: EUR
→ Conversion party
→ FX rate/time
→ USD account
→ $108 debit
Bottom row — Refund
€100 merchant refund
→ Refund currency: EUR
→ Conversion party
→ FX rate/time
→ USD account
→ $105 credit
Between the rows:
Merchant refunded 100% in transaction currency
At the far right:
$3 statement difference ≠ automatically a €3 merchant short-refund
Add a separate callout:
DCC? Stop and verify DCC-specific refund rules.
Image alt text:
Diagram showing a €100 foreign-currency card purchase converted to a $108 customer debit and a later €100 refund converted to a $105 credit, illustrating how exchange-rate or conversion-path differences can change the home-currency refund value.
Proposed author and reviewers
Proposed author:
Recommended reviewers:
Payment operations lead
Finance/reconciliation specialist
Treasury/payments specialist
Customer support lead
Card/payment-network specialist where detailed card rules remain in the published version
Do not assign names or claim completed review until the individuals have actually participated.
Recommended metadata:
Last fact-reviewed: August 2026; review network/provider refund rules again immediately before publication.
Currency-support fact-check items
Verify before publication:
Supported transaction currencies by relevant provider/account.
Supported refund currencies.
Whether refunds must use original transaction currency for each payment method.
Any provider-specific exceptions.
Treatment when original currency is no longer supported.
Zero-decimal/minor-unit handling.
Currency restrictions on partial refunds.
FX fact-check items
Verify:
Who performs the original conversion.
Who performs refund conversion.
Network rate methodology.
Applicable conversion timestamp.
Issuer-specific treatment where mentioned.
FX markup or spread.
Foreign-transaction fee treatment.
Whether merchant/provider conversion occurred before network processing.
Whether published rates are indicative, reference, or transactional.
Never label one public market rate “the rate the customer should have received.”
DCC fact-check items
Where DCC appears, verify immediately against current network/acquirer documentation:
Original local currency.
Customer-selected DCC currency.
Converted transaction amount.
DCC rate.
markup/disclosure.
consent.
refund currency.
refund conversion methodology.
reversal behavior.
partial-refund behavior.
chargeback/dispute implications.
Current Mastercard guidance explicitly requires special DCC-refund treatment, so generic refund-FX assumptions should not override it.
Country-pricing fact-check items
Only required if country examples are added.
Verify:
consumer price/refund disclosure law
currency requirements
DCC restrictions
card-network regional rules
refund rights
tax/pricing interaction
Do not expand this article into the cluster's Local Currency Pricing by Country topic.
Settlement fact-check items
transaction currency
settlement currency
refund settlement adjustment
settlement conversion methodology
payout currency
FX fees
settlement-report fields
whether refund FX gains/losses are merchant-borne
timing of settlement adjustment
Do not infer customer refund currency from merchant settlement currency.
Subscription fact-check items
Subscription mechanics are adjacent rather than article-owned.
If included in a case study, verify:
original recurring transaction currency
current subscription currency
whether refund follows the individual renewal transaction
changed-price handling
currency migration
provider linkage requirements
Link detailed lifecycle questions to Subscription Billing in Multiple Currencies.
Refund fact-check items
Verify:
full refunds.
partial refunds.
multiple partial refunds.
maximum refundable amount.
refund-to-original-payment-method rules.
asynchronous refund states.
expired/replaced-card handling.
DCC refunds.
original currency preservation.
provider reference IDs.
refund completion timing.
fee treatment.
Conversion/incrementality fact-check items
Conversion is not the primary subject of this article.
If the merchant later tests better refund/FX communication, measure:
FX-related support contact rate
repeat purchase after refund
dispute rate
customer-service handling time
refund satisfaction where measured appropriately
Do not claim better refund messaging improves checkout conversion without an experiment.
Regulatory and consumer-protection fact-check items
Verify by jurisdiction:
DCC disclosure requirements.
applicable payment-services rules.
consumer refund law.
card-network standards.
FX transparency requirements.
recurring-payment rules where relevant.
pricing/tax disclosure where relevant.
Disclaimer:
This article provides general information and does not constitute legal, regulatory, tax, financial, banking or accounting advice. Merchants should verify current requirements with qualified advisers, payment providers, acquirers, card networks, banks and relevant authorities.
Amber-flag claims
Do not publish without transaction-specific or authoritative support:
“Refunds use today's exchange rate.”
“Refunds always use the refund-date rate.”
“Refunds always use the original exchange rate.”
“The issuer caused the difference.”
“The card network caused the difference.”
“The merchant has no responsibility for FX differences.”
“A full refund always means the customer receives the same home-currency amount.”
“Foreign transaction fees are refunded.”
“Foreign transaction fees are never refunded.”
“DCC refunds work like normal foreign-currency refunds.”
“The customer lost money because FX moved.”
“The merchant gained the difference.”
“Refunds always settle at the original merchant FX rate.”
All require more context.
Which presentment/transaction currencies are currently supported.
Which refund currencies are supported.
Partial-refund support.
Multiple partial-refund behavior.
Refund API status model.
Refund reference fields.
DCC availability, if any.
DCC refund behavior, if applicable.
Customer-account FX visibility.
Settlement currencies.
Settlement FX.
Refund settlement adjustments.
reporting/base-currency fields.
Whether original transaction and refund FX information is exposed.
Whether issuer/network converted values are observable.
Any first-party data on refund FX support tickets or reconciliation exceptions.
Provider/network verification requirements
For every provider, acquirer or card network used operationally, confirm:
required refund currency
refund linkage
applicable transaction ID/reference
partial-refund rules
multiple-refund rules
refund status semantics
FX conversion party
FX-rate timing
settlement adjustment
DCC-specific refund rules
issuer escalation process
dispute rights
reporting data
Network-level rules should not be assumed to answer every provider implementation question.
Cluster sameness-audit fields
Title:
Refunds and Currency Conversion: Why Customers May Receive a Different Home-Currency Amount
First two sentences:
“The customer paid €100. Their card statement showed a debit of $108.”
Opening device:
A full refund that appears $3 short after conversion.
Customer currency problem:
Customer judges refund completeness by home-currency statement value rather than original transaction-currency amount.
Main currency layer:
Original transaction currency versus customer account currency.
Primary market:
International/cross-border; provider and network specific where rules matter.
Primary format:
Reverse currency-flow investigation.
Unique evidence anchor:
The merchant can refund the exact transaction amount while the converted statement credit differs.
Editorial position:
Assess refund fairness in transaction currency first, then diagnose FX.
Merchant decision:
Preserve original currency data, use linked refunds, trace conversion responsibility, and communicate only what the merchant can verify.
Original framework:
Refund FX Flow.
Secondary framework:
FX Refund Investigation Checklist.
Primary metric:
FX-related refund contact rate.
Supporting metrics:
Refund completion time, partial-refund rate, amount-discrepancy complaint rate, reconciliation exception rate.
Conclusion:
A home-currency difference is a signal to trace the conversion path, not automatic proof of merchant under-refunding.
CTA:
Make transaction currency, refund currency, settlement currency, and conversion ownership visible to Payments, Finance, and Customer Support before the next cross-border refund complaint arrives.
Closing element:
Customer-support scenarios rather than a generic currency FAQ.
Final editorial recommendation
This article should feel less like an explanation of foreign exchange and more like a payment-forensics investigation.
The reader should move backward through the transaction:
$105 credit
→ Who converted it?
→ What refund entered that conversion?
→ Was it €100?
→ Was €100 the full original transaction?
→ Who converted the original purchase?
→ Was DCC involved?
→ Does merchant settlement reconcile?
That structure is what makes the article different from:
How to Prevent Unexpected FX Charges, which owns the customer's original purchase-side FX surprise;
Presentment Currency vs Settlement Currency, which owns the currency architecture;
Dynamic Currency Conversion Explained, which owns the DCC decision;
and Subscription Billing in Multiple Currencies, which owns currency over recurring payment cycles.
This piece owns what happens after the merchant agrees to give the money back.
The line worth carrying through the final edit is:
Refund the transaction first. Explain the conversion second.
A merchant should be able to prove exactly what it returned.
It should not promise the exact home-currency value of an FX conversion controlled by someone else.
Need help narrowing down payment options?
Answer a few questions about your business and compare the capabilities that matter to you.
Explore matching options ↗