Visa 11.1 Chargeback: Card Recovery Bulletin — Merchant Response Guide

Anchor the case to the disputed transaction

Preserve the processor notice and match it to the merchant receipt or transaction record. Confirm amount, date, location or terminal, transaction ID, and the authorization reference available to the merchant. Any mismatch should be resolved before a response is drafted.

If the store processed multiple transactions for the same customer or card token that day, keep them separate. Nearby legitimate transactions can create accidental evidence mixing, especially when receipts look similar.

Retrieve the original authorization exchange

Export the authorization request and response, approval or decline result, and any issuer/acquirer indicators the processor exposes. Do not replace the original response with a later order status or staff note saying the payment was accepted.

Where the merchant can see a response code but does not know its meaning, use processor documentation or support rather than guessing. The packet should preserve the field as recorded and explain it only to the extent the provider documentation supports.

Check transaction timing and terminal path

Keep the transaction timestamp, entry mode, terminal identifier, and any reversal or retry. These details help distinguish the exact event the dispute is about and can show whether the payment followed the merchant's expected authorization path.

If the terminal was offline, used fallback, or routed differently, document the actual system record. Do not infer that unusual processing caused or cured the dispute without checking the current rule.

Do not lead with commercial fulfillment

A receipt or proof that goods left the store can identify the sale, but the core issue is the payment authorization/recovery context. Put commercial evidence after the authorization records and include it only if the processor asks for it or it clarifies transaction identity.

Long statements about the customer being present, known to staff, or satisfied with the purchase are weak if they are not supported by retained transaction records. Keep the narrative objective.

Escalate unclear bulletin facts

Merchants often do not have direct visibility into issuer-side bulletin details. If the case turns on information the merchant cannot see, use the acquirer or processor channel to understand what evidence or action is actually available rather than inventing a merchant-side interpretation.

A second reviewer should mark which facts are observed in merchant systems and which come from the processor notice. This boundary keeps the response accurate and prevents speculation about issuer decisions.

Use outcomes to review card-present controls

If 11.1 cases recur at particular terminals or transaction paths, review authorization handling, offline behavior, fallback, and staff procedures with the processor. Retain the case IDs and technical records for pattern analysis.

Before filing, compare the packet with current Visa merchant dispute guidance. The live case and current network rules control the actual response rights; the operational checklist only helps the merchant build a reliable record.

Example: merchant cannot see issuer-side bulletin details

The processor case references Visa 11.1, but the merchant dashboard does not expose the issuer-side bulletin detail that created the dispute. The merchant should preserve the authorization, terminal, and transaction record it can see, then use the processor/acquirer channel to understand the action available.

Guessing what the bulletin contained is not useful evidence. Internal notes should mark 'merchant-observed' versus 'processor-provided' facts so the response does not present speculation as a system record.

Use processor escalation when bulletin facts are outside the merchant's visibility

Card Recovery Bulletin-related disputes can depend on issuer/network information the merchant may not directly see. Start with the facts the merchant does control: transaction date/time, terminal, entry mode, authorization response, amount, and settlement. Preserve the original authorization exchange rather than relying on a later account screen. Then compare the live dispute notice with those records and identify which required fact is unavailable on the merchant side.

Do not invent the missing network fact. If the question depends on bulletin status, issuer notification timing, or another element the acquirer can see more clearly, escalate with a precise request. Ask the processor which condition is alleged and which merchant-side evidence is relevant. Keep the response focused on what can be proven from the transaction. A long receipt or fulfillment narrative is unlikely to resolve a technical issuer/network issue.

Transaction timing can still matter. Record when the sale occurred relative to the authorization and any later reversal, retry, or adjustment. If the merchant used offline or manual processing, preserve that context. Where current rules specify handling, use the live guidance supplied by Visa or the acquirer. The article should help the merchant organize the record, not pretend to reproduce confidential network data.

After closure, review whether store procedures increase exposure to transactions that cannot be validated cleanly. Track offline approvals, manual entry, fallback, unusual authorization responses, and staff overrides. If the business repeatedly needs acquirer escalation because terminal records are incomplete, improve the data capture. Stronger merchant-side transaction logs make both technical disputes and ordinary payment investigations easier even when some network facts remain outside the merchant's view.

Preserve the authorization response code exactly as the processor recorded it

Do not translate or paraphrase an authorization response from memory. Store the raw or provider-normalized response code, timestamp, terminal, and transaction reference. If staff need an explanation, link to the processor's current documentation. A later dispute is not the time to invent what an unfamiliar code 'probably meant.'

This practice is especially important where merchant visibility into bulletin or issuer-side facts is limited. A precise merchant-side payment record allows the acquirer to compare the transaction against network information without first resolving ambiguity created by the merchant's own logs.

Escalate before the deadline when merchant-side evidence cannot answer the bulletin issue

Set an escalation deadline earlier than the submission deadline for 11.1 cases where the merchant lacks issuer- or network-side facts. The case owner should send the processor a precise question and retain the response. Waiting until the final day leaves no time to interpret the clarification or retrieve supporting terminal records. A documented escalation path also prevents staff from filling the information gap with irrelevant customer-service evidence simply because they feel pressure to submit something.

When a Card Recovery Bulletin issue cannot be answered from merchant-side records alone, escalation should happen early enough for the acquirer or processor to clarify what information is available. Preserve the original authorization and clearing data, terminal or ecommerce context, transaction identifiers, and the processor notice. Avoid substituting order fulfillment evidence for a payment-network question that the merchant's own systems cannot resolve. The case owner should mark which facts are known, which are inferred, and which require external confirmation. This prevents a rushed response from turning an information gap into an unsupported assertion. It also gives the merchant a reusable escalation path for rare network-specific disputes instead of forcing frontline agents to improvise from generic chargeback templates.