Visa condition 12.3 concerns incorrect currency. The merchant response therefore needs to show what currency the customer was offered, what currency the transaction was authorized and processed in, and whether any currency conversion or choice was presented. A generic invoice showing only a number is not enough when the dispute is about denomination.
Preserve the purchase-time price display, checkout or terminal currency, receipt, authorization/capture records, and settlement data available to the merchant. If dynamic currency conversion or another conversion path was involved, keep the disclosure and choice records that actually applied to the transaction.
Put a currency label beside every amount
Create a small reconciliation table listing displayed price, authorized amount, captured amount, refunded amount if any, and disputed amount. Write the three-letter currency code beside each amount. This immediately exposes whether the dispute is a currency mismatch, an exchange-rate misunderstanding, or a different problem such as an incorrect amount.
Do not compare bare numbers such as 100 and 100 without identifying USD, EUR, CAD, or the applicable denomination. Currency disputes become confusing when screenshots use symbols that can represent more than one currency or when the merchant's back office converts amounts for reporting.
Preserve what the customer saw at purchase
For ecommerce, keep the product page or checkout record showing the transaction currency at the time of purchase, not a current page that may now use localization. For point of sale, preserve the receipt or terminal record that identifies the transaction currency.
If the site selected currency based on locale or the customer manually switched currencies, record that event only if the system actually retains it. Do not infer a customer choice from IP location or browser language. The evidence should distinguish observed system behavior from assumptions about intent.
Trace authorization and capture in the same currency
Confirm the authorization message and captured transaction use the expected currency code. If the payment provider exposes both merchant settlement currency and transaction currency, label them separately so the reviewer does not confuse what the customer was charged with how the merchant was funded.
Where the transaction was adjusted, partially captured, or refunded, keep the currency attached to each financial event. An otherwise correct amount can look wrong if the refund screenshot is shown in settlement currency while the disputed sale is in transaction currency.
Handle conversion disclosures as their own evidence
If the customer was offered a conversion option, preserve the purchase-time disclosure, rate or converted amount shown, and the customer's recorded selection when available. The point is to document the actual choice path, not to paste a current currency-conversion policy into the packet.
If the merchant cannot show what was presented or selected, be cautious about claiming the customer knowingly chose a currency. A policy can explain the system, but transaction-specific evidence is stronger than a description of what the checkout usually does.
Separate issuer exchange-rate complaints
A customer may object to the final statement amount because the issuer converted a correctly processed foreign-currency transaction. The merchant should first verify its own transaction currency and amount. Do not promise that the issuer's exchange rate, fees, or statement conversion was controlled by the merchant unless the merchant actually handled that conversion.
Keep the rebuttal limited to facts the merchant can prove: what currency was displayed, authorized, captured, and refunded. If those records are internally inconsistent, resolve the merchant-side issue before contesting.
Prevent repeat 12.3 cases
Audit currency labels across product pages, cart, checkout, receipts, confirmation emails, and refunds. Mixed labels are a customer-experience problem even when the payment record itself is technically correct.
For international stores, retain purchase-time pricing and currency selection as structured order data. That makes future 12.3 investigations faster and reduces dependence on screenshots of pages that may have changed after the transaction.
Example: USD storefront, CAD settlement account
A U.S. ecommerce site displays and charges a Canadian customer in USD, while the merchant's own settlement account reports the proceeds converted into CAD. A dispute about incorrect currency can become confused if finance exports the CAD settlement amount and treats it as the customer charge.
The case should label transaction currency and merchant settlement currency separately. The purchase-time checkout, authorization/capture currency, receipt, and any conversion choice shown to the customer are the relevant chain.
Reconcile customer-facing currency, processor currency, and settlement currency separately
Currency disputes are often caused by teams treating every amount as though it were denominated the same way. Create a table with the customer-facing price currency, checkout total, authorization currency and amount, captured currency and amount, and merchant settlement currency. The customer's card statement may involve issuer conversion that the merchant does not control, so distinguish the merchant's transaction currency from the issuer's later exchange-rate presentation.
Preserve the purchase-time display. A merchant selling in USD while settling internally in CAD can still have a valid USD transaction if the customer clearly saw and agreed to USD. Conversely, a storefront that displays a local currency but submits another currency without clear disclosure can create a real problem. Store the checkout version, cart total, receipt, and any dynamic-currency or conversion disclosure that applied. Today's website is not enough if the display changed since the transaction.
Trace authorization and capture without silently converting values. If the merchant authorized 100 USD but the capture appears as 100 CAD, the numeric equality hides a currency mismatch. If a provider converts internally for settlement, show the processor record proving the card transaction itself remained in the agreed currency. Do not use the merchant's bank settlement amount as evidence of what the cardholder agreed to pay unless the two are directly linked and clearly labeled.
Use 12.3 cases to test pricing architecture. Review multi-currency configuration, locale detection, payment-provider settings, currency symbols, checkout copy, and reconciliation systems that may drop currency codes. Require internal exports to store ISO currency with every amount rather than carrying bare numbers. Most currency disputes are easier to prevent with explicit data and display controls than to explain after a cardholder sees an unexpected denomination on a statement.
Test multi-currency checkout using a customer-visible receipt sample
For every supported storefront currency, run a sample order and compare cart, checkout, receipt, processor authorization, captured transaction, and settlement reporting. The card transaction should retain an explicit currency at each stage. This test catches configuration where the storefront symbol changes but the gateway still submits a default currency, or where an internal export drops the currency code and leaves ambiguous amounts.
Store the test result after major payment or localization changes. Currency disputes can emerge only in one market, browser locale, or payment method. A repeatable QA matrix is more useful than discovering a mismatch months later through 12.3 chargebacks.
VERIFY CURRENT RULES
Primary references
Processor interfaces, reason-code mappings, filing windows, and network rules can change. Check the active dispute notice and current official documentation before submitting.