Dynamic Currency Conversion: Follow the Customer's Choice

A visitor finishes a meal in Germany. The bill is in euros, but the card terminal also offers an amount in the card's billing currency. The second amount is easier for the visitor to recognise. It is still a currency-conversion offer that needs an active decision.

Dynamic currency conversion, or DCC, gives an eligible cardholder a conversion choice at the point of payment. For a product team, the job extends beyond displaying two buttons: the selected currency and terms need to remain consistent through the payment response, receipt and any later investigation.

The restaurant example is fictional. The arithmetic below is invented to explain the comparison, not a current exchange-rate quote or a claim that either option is always cheaper.

Make the offer understandable before the customer chooses

Visa's consumer guidance calls for the local and cardholder-currency amounts, identifiable currencies, the conversion rate and additional fees or markup to be displayed. It says the merchant or ATM should leave the choice to the cardholder and avoid presentation that steers the decision. Visa also says declining conversion does not prevent the underlying purchase or withdrawal. These statements describe Visa's published guidance; they are not a substitute for the merchant's applicable network rules and acquiring agreement. Visa's DCC guidance

A product review should examine the complete decision screen. Can the customer distinguish the local-currency amount from the converted amount? Is the rate's direction understandable? Can someone choose local currency without a cashier suggesting that the purchase will fail? Do the two actions receive comparable visual treatment?

Observe the cashier's behavior as well as the interface. A neutral screen does not protect the customer's choice if another person selects an option before handing over the terminal. Training and transaction evidence belong in the launch review alongside the screen design.

Compare the same bill without inventing a guaranteed saving

Assume the restaurant bill is EUR 100 and a hypothetical DCC offer is USD 112. The implied offered conversion is USD 1.12 per euro. That calculation describes the displayed offer; it does not reveal how much markup is embedded relative to any reference rate.

For comparison only, suppose the card's alternative conversion would be USD 1.09 per euro and a hypothetical fee were 3% of the converted amount. The arithmetic would be 100 × 1.09 × 1.03 = USD 112.27. With a hypothetical zero fee, it would instead be USD 109. Neither result is a forecast for the visitor's actual card.

This small example changes the result when one input changes. If the card's terms are unknown, keep that input unknown. A product should not label an option "best value" using an assumed fee or rate that the customer has not established.

The remittance comparison guide uses a related discipline: compare the same underlying amount and identify missing charges. A DCC offer concerns a card transaction at the point of payment, so its records and rules need their own treatment.

Preserve the selection through the provider response and receipt

Adyen documents a terminal flow in which accepting DCC applies conversion and declining it continues the transaction in local currency. Its generated receipt carries conversion information. For custom receipts, its documentation specifies fields including both amounts, the rate and its source, markup and the acceptance statement. These are Adyen integration requirements, not proof that an arbitrary custom screen or receipt is compliant. Adyen's DCC integration guide

For a proposed acceptance test, record the offer shown, the customer's selection, the provider reference and the amounts/currencies in the response and receipt. Use appropriately protected transaction references; avoid collecting raw card credentials for a screenshot or test report.

If the customer selects euros but the resulting record shows a different currency, open an exception. A successful payment response does not resolve that mismatch. The investigator needs the original offer and selection, not an explanation reconstructed from today's rate.

Follow the decision through the system

Treat refunds as a separate test

J.P. Morgan Payments documents why the original transaction data matters in its terminal integration. The point of sale supplies the original currency for a refund. Its guide describes a merchant-currency fallback if that information is missing or does not match the available offer, and a current conversion rate when a DCC refund qualifies. That is this provider's documented behavior, not a universal refund rule or proof of network compliance. Confirm the applicable rules and supported route with the acquirer before setting the expected test result. J.P. Morgan's DCC refund documentation

Test a full refund and a partial refund using the original reference. Compare the request, provider response and refund receipt with the original currency and amount. Establish how the configured integration handles the rate, rounding and any fees. If the documented route cannot preserve the required currency, resolve that discrepancy with the acquirer before approving the test.

For broader quote-to-refund recordkeeping, see the payment FX operations guide. The terminal tests here address the customer's DCC choice.

A shopper selecting DCC for the purchase is not evidence that any later conversion is correct. Nor does an initiated refund prove that the customer has received a credit. Keep the processing outcome and customer-credit evidence separate, as the merchant launch checklist does for payment and refund cases.

Reconcile the merchant's records separately

Adyen's DCC reporting distinguishes acceptance, decline and non-offer outcomes. Its settlement report can include a DCC markup field, where a negative amount represents a merchant credit. That sign convention belongs to that report; it should not become a universal fee formula in an infographic. Adyen's DCC reporting documentation

For the restaurant, the useful launch evidence is a small set of completed cases: each customer choice, a non-offer case with its reason, an interrupted outcome investigated against its original reference, and supported refund cases. Confirm that operations can trace them through the receipt and finance can reconcile them without treating the customer's converted amount as the merchant's complete payout calculation.

A clear terminal helps the visitor make the choice. Consistent records let the business explain what happened after the visitor leaves.