Building a chargeback
response template
library by reason code

Most merchants build one chargeback response and reuse it for every dispute that lands -- swap the invoice number, change the date, resend. It's the fastest way to lose disputes that were actually winnable. A reason code isn't a label; it's a specific question the issuing bank is asking, and every response needs to answer that exact question with the evidence type it's built to evaluate. This piece turns our reason-code reference and the representment packet walkthrough into something usable on day one of building a dispute-response process: five standing templates, one per reason-code family, ready to fill in before the clock on your next notification starts running.

Why one template can't cover every code

The two major networks route disputes through fundamentally different workflows depending on category. Visa's Fraud and Authorization categories (10.x, 11.x) run through what Visa calls an "allocation" workflow -- funds move and liability gets assigned on rule-based criteria quickly, so the response window is tighter and the evidence needed is narrow and specific: proof the transaction itself was authenticated. Visa's Processing Errors and Consumer Disputes categories (12.x, 13.x) run through a "collaboration" workflow closer to traditional back-and-forth representment, with more room for a documentation-heavy response built around proof of fulfillment or a correctly processed transaction record. Mastercard's parallel code set (4837, 4853, 4863, and sub-reasons under 4853) maps onto the same two logical buckets -- authentication-question codes and fulfillment-question codes -- even though its numbering doesn't mirror Visa's category structure. Building templates around that split, rather than around a single all-purpose response, is what keeps a representment packet inside the specific question the bank is actually going to evaluate.

Template 1 — Fraud (Visa 10.1–10.5, Mastercard 4837, 4863)

The question this code family asks: was this specific transaction authorized by the legitimate cardholder? The template needs a fixed evidence checklist and nothing else.

• Evidence checklist: AVS and CVV match results from the original authorization; 3-D Secure authentication data if the transaction ran through it; device fingerprint and IP-to-billing-address consistency where your gateway captures it; order history showing prior undisputed purchases on the same card or account.
• Cover-letter opener: "This transaction [order #] was authenticated at the point of sale. AVS matched [result], CVV matched [result][, and 3-D Secure authentication succeeded with ECI value [X]]. The attached device and order history is consistent with the account's prior undisputed purchase pattern."
• What to leave out: return policy, shipping confirmation, or a note about customer service interactions -- none of it answers the authentication question. See 3-D Secure: liability shift vs conversion cost for when authenticating higher-risk orders upfront is worth the checkout friction.

Template 2 — Authorization (Visa 11.1–11.3)

This family asks whether the transaction was actually processed with a valid authorization. It's less often a fight and more often a records pull.

• Evidence checklist: the original authorization response code and timestamp; confirmation the transaction was captured within the authorization's valid window; gateway logs showing no re-submission after a decline.
• Cover-letter opener: "Transaction [order #] was authorized on [date/time] with approval code [X] and captured within the authorization window. No decline or expiration preceded settlement."
• Standing fix: if this code recurs, it usually points to a gateway or POS configuration issue -- expired-authorization capture, or a batch delay past the authorization's validity window -- worth auditing separately from any single dispute.

Template 3 — Processing errors (Visa 12.1–12.7)

This family asks whether a technical mistake happened in how the transaction was processed -- duplicate charge, wrong amount, wrong currency, late presentment. These are usually the most winnable disputes outright, since the transaction record itself answers the question.

• Evidence checklist: the full transaction record showing the correct amount and currency; confirmation of a single settlement (no duplicate batch entry); presentment timestamp within the required window.
• Cover-letter opener: "Transaction [order #] settled once, on [date], for [amount] in [currency], within the required presentment window. No duplicate transaction exists in our settlement records for this order."
• Standing fix: recurring 12.x disputes point to a batch or settlement process problem, not a customer issue -- tighten the settlement pipeline rather than treating each one as a one-off fight.

Template 4 — Consumer disputes: non-receipt and not-as-described (Visa 13.1, 13.3, Mastercard 4853)

This family asks whether the merchant delivered what was promised. The cardholder isn't disputing that they made the purchase.

Code	Network	What it's disputing	Evidence checklist
13.1	Visa	Goods/services never received	Tracking number with delivery confirmation, signed proof of delivery, or a valid future delivery date within terms
13.3	Visa	Not as described / defective	Itemized product description and photos matching the listing at time of sale, and any return/inspection record
4853 (fulfillment sub-reason)	Mastercard	Goods/services not as described or not received	Same as above, matched to the specific sub-reason listed on the notice

• Cover-letter opener: "The merchandise for order [order #] was delivered on [date], confirmed by tracking number [X] with signature/delivery confirmation attached. The item matches the description and images presented to the customer at checkout."
• What to leave out: AVS/CVV or 3-D Secure results -- authentication was never in question here, and attaching it signals the wrong template was used.

Template 5 — Subscription cancellation (Visa 13.2, 13.7, Mastercard 4853's billing sub-reasons)

This is the family that most directly needs its own template rather than folding into the general consumer-dispute one, because the two Visa codes inside it allege different failures. 13.2 (Cancelled Recurring Transaction) is the cardholder saying they cancelled the subscription and were billed again anyway. 13.7 (Cancelled Merchandise/Services) is the cardholder saying they cancelled a purchase or service and the promised credit never posted. Mastercard folds both patterns into 4853's broader recurring-billing and credit-not-processed sub-reasons.

• Evidence checklist (13.2): the customer's original cancellation request (date and channel), confirmation of when it was processed relative to the next billing date, and the cancellation-notice terms the customer agreed to at signup (e.g. "cancel by the 5th to avoid the next cycle").
• Evidence checklist (13.7): refund transaction ID, amount, and post date if a credit was issued; if not, the cancellation/refund policy the customer agreed to and proof the cancellation came after the policy's cutoff.
• Cover-letter opener (13.2): "No cancellation request for subscription [ID] was received prior to the billing date of [date]. Our records show the customer's account remained active per the terms agreed to at signup on [date]."
• Cover-letter opener (13.7): "A refund of [amount] for order [order #] was issued on [date], transaction ID [X]." Or: "Per the cancellation policy accepted at checkout on [date] (attached), cancellations after [cutoff] are not eligible for a refund of the current billing period; the customer's request was submitted on [date], after that cutoff."

The single habit that wins the most 13.2, 13.7, and 4853 credit-not-processed disputes isn't a better cover letter -- it's logging every refund with a timestamp and transaction ID the moment it's issued, so the evidence already exists instead of needing to be reconstructed inside a 30-to-45-day window.

Deadlines: build the templates so the clock is the only variable

Mastercard's documented first-chargeback response deadline is 45 days from the notification date. Visa's timelines vary by category and workflow -- allocation disputes (Fraud, Authorization) move faster than collaboration disputes (Processing Errors, Consumer Disputes) -- but 30 days is the figure most consistently cited across chargeback-management vendor documentation of Visa's published rules. Both deadlines run from the date the notification was issued to the acquirer, not the date a team member opens it. A template that's already built and only needs order-specific facts filled in removes the biggest cause of missed deadlines: time spent deciding what to attach.

Keeping the library current

A template library is only useful if it reflects what actually wins. Two habits keep it current: reviewing any loss that wasn't caused by a missed deadline (a loss like that usually means the template answered the wrong question for that code), and updating the evidence checklist whenever your gateway, processor, or subscription-billing platform changes what data is actually captured at checkout -- a new AVS/CVV field, a new 3-D Secure integration, or a new refund-logging step in your subscription tool should get reflected in the relevant template the same week it ships, not discovered the next time a dispute lands.

Frequently asked questions

What should a chargeback response template library actually contain?

One template per reason-code family, not one generic template for every dispute -- a fraud template built around authentication evidence (AVS/CVV, 3-D Secure results, device history), a processing-error template built around transaction-record proof (exact amount, single settlement, timestamp), a consumer-dispute template built around fulfillment proof (tracking, signed agreements, itemized description), and a subscription-cancellation template built around cancellation-policy proof (the terms the customer agreed to, the date they cancelled, and whether a refund was owed under those terms). Each template should have the required evidence list, the deadline for that network, and a short cover-letter structure that states the reason code and answers it directly.

How is a 13.2 dispute different from a 13.7 dispute?

Both are Visa Consumer Dispute conditions and both can involve a subscription, but they allege different failures. Visa 13.2 (Cancelled Recurring Transaction) is the cardholder saying they cancelled the recurring billing itself and were charged again anyway -- the winning evidence is proof the cancellation request was never received, or proof it was received after the billing date it would have affected. Visa 13.7 (Cancelled Merchandise/Services) is the cardholder saying they cancelled a one-time purchase or service and the promised credit never posted -- the winning evidence is a refund transaction ID and post date, or proof no refund was owed under the disclosed terms.

Should the same evidence ever be reused across reason codes?

Some documents show up in more than one template -- a signed terms-of-service acceptance can support both a 13.2 cancellation dispute and a 13.7 credit dispute, for example -- but the cover letter and framing should never be copy-pasted between fraud and non-fraud templates. A fraud rebuttal is arguing the transaction was authenticated; a consumer-dispute rebuttal is arguing the transaction was fulfilled or the cancellation terms weren't met. Sending a fraud-framed letter with fulfillment evidence attached, or vice versa, is one of the most common reasons a winnable packet gets rejected.

How often should a chargeback response template library be updated?

Review it whenever a representment loses for a reason other than a missed deadline -- that's a signal the template sent the wrong evidence type for that code. It's also worth a light review after any processor, gateway, or subscription-billing platform change, since those changes can affect what evidence (AVS results, refund IDs, cancellation timestamps) is actually available to attach when a dispute lands.