Visa condition 12.5 concerns an incorrect amount. The safest merchant workflow is a numeric reconciliation: what amount was agreed, what amount was authorized, what amount was captured, what adjustments were made, and what amount the cardholder is disputing. A long narrative cannot compensate for arithmetic that does not reconcile.
Collect the order or invoice, authorization response, capture record, tip/tax/shipping adjustments where applicable, receipt, refund or partial-refund records, and processor case data. Then build one amount table before deciding whether the merchant should contest the case.
Start with the amount the customer agreed to pay
Use the purchase-time order, signed receipt, invoice, or other transaction record to establish the expected total. Break out subtotal, tax, shipping, gratuity, deposit, or other components if they explain the final number. Do not rely on a current product price when the price may have changed.
If the amount changed after the initial agreement, identify the event that authorized or justified the change and preserve the corresponding record. The key question is not whether the business normally makes adjustments, but whether this transaction's amount path is documented.
Reconcile authorization and capture
Place authorized amount and captured amount side by side with timestamps and transaction references. If the processor allows an adjustment or multiple captures, show how the final captured total relates to the original authorization and the customer's purchase.
If an amount was accidentally entered twice, transposed, or captured with an incorrect adjustment, the merchant's own ledger will usually reveal it. Do not hide the discrepancy behind a generic receipt; fix or accept the error as appropriate and use the case to trace the control failure.
Separate tips, tax, shipping, and deposits
These components often create apparent mismatches. For restaurants or hospitality, preserve the signed or accepted final amount where retained. For ecommerce, keep tax and shipping calculations tied to the order version at checkout. For deposits or partial payments, show the agreed payment structure.
Avoid presenting a single total when the dispute is about one component. A reviewer should be able to see whether the difference came from a legitimate line item, a later adjustment, or an unexplained merchant-side change.
Account for credits before arguing the original amount
Check whether the merchant already issued a full or partial refund. A case can look like an incorrect-amount dispute when the real issue is that the customer expected a credit or the credit was applied to only part of the sale.
Record each refund with amount, currency, timestamp, reference, and status. Then compare the remaining net amount with the amount still being disputed. This prevents the business from defending money it has already agreed to return.
Use a one-page amount bridge
A useful exhibit starts with the agreed amount and moves through authorization, adjustments, capture, credits, and final net amount. Every line should point to a source record. This is easier to review than five screenshots that each display a different total without explanation.
Keep the narrative to the arithmetic: state which amount is alleged to be wrong, what the correct amount was, and which records demonstrate it. Product-quality or fulfillment evidence belongs elsewhere unless the live dispute also makes it relevant.
Fix the source of the mismatch
Tag the root cause as manual entry, tip handling, tax calculation, shipping adjustment, multiple capture, integration logic, refund timing, or another documented category. Trend these cases by system and merchant location if relevant.
Before filing or changing process, check current Visa merchant dispute guidance and the processor case. The article provides an evidence workflow, not a substitute for live network rules.
Example: restaurant tip changes the final amount
A restaurant authorizes $80, the customer later signs for a $96 total including tip, and the final capture is $96. An incorrect-amount case should show the original authorization, signed final receipt where retained, final capture, and any processor-supported adjustment path. The story is numeric, not rhetorical.
If the captured amount is $106 because of a manual keying error, the same bridge exposes the merchant mistake immediately. A reconciliation table is useful precisely because it makes legitimate adjustments and accidental overcharges look different.
Create an amount bridge from quoted price to final settled total
Incorrect-amount disputes should be answered with arithmetic. Start with the price or estimate the customer accepted, then add or subtract every component that legitimately changed the total: tax, shipping, tip, deposit application, quantity, approved change order, partial capture, or other disclosed adjustment. End at the settled amount. If the bridge cannot reproduce the charge exactly, do not write around the difference. Investigate which system or staff action created it.
Authorization and capture should be shown as separate steps. Some businesses legitimately authorize one amount and capture another under payment-network and processor rules, but the merchant still needs a record explaining the difference. A restaurant tip, fuel amount, hotel incidental, or order modification can create a changed final total. Preserve the customer-facing receipt or agreement and the payment-system trail. Avoid citing a generic industry practice without tying it to the actual transaction and current rules.
Credits and adjustments belong in the same bridge. If a merchant overcharged by $25 and later refunded $25, show the correction with amount and processor reference. If the chargeback amount reflects the full original charge despite a partial refund, make the remaining balance visible. If the merchant promised an adjustment that never settled, that failure is part of the case rather than a footnote.
Use 12.5 losses as reconciliation defects. Track mismatches caused by tax recalculation, manual tip entry, duplicate add-ons, partial shipment logic, currency conversion, stale cart totals, or staff overrides. Create system checks where the final capture exceeds the expected tolerance or lacks a linked customer-approved adjustment. A clean amount bridge is valuable evidence, but the better control is preventing unexplained amount differences from settling at all.
Handle estimated, variable, and final amounts as separate customer expectations
Some businesses begin with an estimate and finalize the charge later. Preserve the estimate, the rule for adjustment, the final itemized total, and the customer's receipt. The dispute team should show why the final amount changed rather than implying the estimate was a firm authorization for any later total. Where the payment flow requires additional authorization or other controls, rely on current provider and network guidance.
If customers repeatedly dispute the difference even when technically valid, improve the customer-facing expectation. Display ranges, pending adjustments, and final receipts clearly. Chargeback prevention is not only about proving the amount; it is also about reducing the surprise that causes a customer to believe the merchant overcharged them.
Incorrect-amount cases also need a clear treatment of taxes, tips, deposits, preauthorizations, and post-service adjustments. The merchant should identify which amount the customer saw first, which amount was authorized, which amount was finally captured, and why any difference occurred. If the business model legitimately uses an estimate followed by a final amount, preserve the disclosure and the event that established the final charge. If the amount changed because of a staff correction, manual adjustment, or duplicate fee, document that too. A reviewer should be able to trace the disputed amount without performing arithmetic across several receipts. When the merchant cannot explain the bridge cleanly, that is a signal to investigate the transaction before defending it rather than forcing the case into a generic “customer agreed” narrative.
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.