What does Visa reason code 12.2 actually cover?

It covers transactions processed with an incorrect transaction code, with the classic case being a customer who requested a refund and got charged again instead. The dispute corrects the direction of the funds movement. It is a processing-error claim, so the fight is entirely about what your settlement records show, not about the merits of the sale.

The customer already got a correcting refund. Why did a 12.2 still arrive?

Chargebacks and refunds run on different rails, and the cardholder often calls their bank before or despite your correction. Respond with the correcting credit's reference and date; that evidence typically resolves the dispute. If the chargeback settles anyway, pursue the double-credit through your acquirer, because the customer should not keep both.

How do I stop refunds from being processed as sales?

Force all refunds through the original transaction in your gateway, which inherits the correct type and amount automatically, and shut off standalone credit or debit keying in the virtual terminal for most staff. Pair that with a daily reconciliation that flags any credit-direction anomaly. Most 12.2 events trace to manual keying that these two controls eliminate.

Visa · Processing Errors

Reason code 12.2: Incorrect Transaction Code

The transaction was processed with the wrong transaction code, most commonly a refund processed as a sale or a sale processed as a credit. The cardholder ends up debited when they should have been credited, or the amounts move in the wrong direction entirely. These are operational keying and configuration errors rather than disputes about the underlying purchase.

Issuer filing window

120 days from the transaction processing date

Merchant response window

typically 20-30 days to respond, depending on the acquirer

Why 12.2 chargebacks happen

A staff member selected sale instead of refund on the terminal or virtual terminal, debiting a customer who was owed money back.
A refund API call was mapped to the wrong transaction type in a custom integration.
Batch adjustment entries were keyed with reversed debit and credit codes.
A partial-refund workflow re-ran the original sale instead of issuing the credit.
Terminal configuration after a hardware swap defaulted to the wrong transaction type for a specific menu option.

How to fight a 12.2 chargeback

Compare the transaction code the issuer cites against your processing records; if the transaction was actually coded correctly, submit the settlement detail proving it.
Show that any error was already corrected, including the reversal or correcting credit with its date and reference number, which removes the basis for the dispute.
Provide the original order documentation demonstrating the transaction direction matched what the cardholder agreed to.
If a correcting credit and the chargeback would double-refund the customer, document both movements so the issuer can see the net position.
Move quickly, since processing-error disputes are usually clear-cut and the evidence is entirely in your own records.

How to prevent 12.2 chargebacks

Issue refunds only through the original transaction record in your gateway rather than as standalone keyed credits or debits.
Restrict virtual terminal access and require a second review on manual adjustments.
Add automated tests around refund and void code paths whenever billing integrations change.
Reconcile daily settlement files against expected transaction types and alert on anomalies like credits appearing as sales.
Train new staff on terminal workflows and remove unused transaction-type options from terminal menus.

Frequently asked questions

What does Visa reason code 12.2 actually cover?: It covers transactions processed with an incorrect transaction code, with the classic case being a customer who requested a refund and got charged again instead. The dispute corrects the direction of the funds movement. It is a processing-error claim, so the fight is entirely about what your settlement records show, not about the merits of the sale.
The customer already got a correcting refund. Why did a 12.2 still arrive?: Chargebacks and refunds run on different rails, and the cardholder often calls their bank before or despite your correction. Respond with the correcting credit's reference and date; that evidence typically resolves the dispute. If the chargeback settles anyway, pursue the double-credit through your acquirer, because the customer should not keep both.
How do I stop refunds from being processed as sales?: Force all refunds through the original transaction in your gateway, which inherits the correct type and amount automatically, and shut off standalone credit or debit keying in the virtual terminal for most staff. Pair that with a daily reconciliation that flags any credit-direction anomaly. Most 12.2 events trace to manual keying that these two controls eliminate.

Related Visa codes