Visa 13.6 is fundamentally a reconciliation problem. The cardholder says a credit or void that should have been processed was not. The merchant should be able to trace the original sale and the offsetting credit through the payment system. If the only evidence is an internal note saying “refund approved,” the file is incomplete.
Start with the money trail. Identify the original payment, the amount allegedly owed back, the refund or reversal reference, the date it was submitted, and its final processor status.
Separate “approved” from “processed”
Customer-support systems often treat approval as the end of the workflow. Payment systems do not. A refund can fail, remain pending, be sent for the wrong amount, or be attached to the wrong transaction. Export the processor record that shows the credit event and its status.
If the merchant issued a void rather than a refund, explain the difference using the processor record. The cardholder’s statement may display those events differently, so the merchant should avoid promising a posting date that its records cannot establish.
Prove the offset against the same disputed sale
Use transaction IDs and amounts to link the credit to the disputed payment. If multiple purchases have similar amounts, label them carefully. A $75 refund on order 801 does not answer a $75 dispute on order 802 merely because the customer and amount match.
For partial credits, show the arithmetic. State the original amount, credit amount, remaining amount, and reason the credit was partial. The reviewer should not have to calculate whether the merchant actually offset the disputed sum.
Credit-not-processed cases are ledger problems. The merchant should identify whether a credit was promised, whether it was actually initiated, the exact amount, the payment method, processor refund identifier, and the date the processor accepted it. A support message saying “your refund is on the way” is not proof that the credit entered the payment system. Conversely, if the refund was processed, the cleanest evidence connects the refund transaction back to the original sale and explains any partial amount.
When the merchant says no credit was due
Sometimes the cardholder requested a refund but the merchant denied it under the applicable terms. In that case, the response should show what happened: the request, the policy or transaction terms in effect, the reason for denial, and any product or service evidence relevant to the decision.
Do not rely on a generic “all sales final” page without showing that it applied to the purchase. And if the merchant promised a refund anyway, the promise can become the key fact regardless of the standard policy.
Build a refund exception queue
Every approved refund should eventually land in one of a few states: completed, reversed, failed, cancelled, or under investigation. Finance should review exceptions rather than waiting for customers to report that the money never arrived. A daily reconciliation between support-approved refunds and processor credits is a strong control.
Store the refund transaction ID back on the order and support ticket. That single linkage makes future disputes much easier to investigate and reduces the risk of a second credit being issued after a chargeback opens.
Why this code is valuable operationally
13.6 cases reveal gaps between customer service and payments. If support can promise money that finance cannot trace, the merchant is exposed to both chargebacks and customer-trust problems. The fix is not a better rebuttal template; it is a closed-loop refund process.
Track failed refunds, slow refunds, wrong amounts, and duplicate credits separately. Over time, that data tells the merchant whether the problem is processor behavior, integration reliability, staff error, or unclear refund policy.
Use one refund owner across support, finance, and the payment platform. Multiple teams issuing credits independently can create double refunds, while handoffs with no owner create the opposite problem: everybody believes someone else processed it. Record the original payment ID, refund ID, amount, reason, requester, approver, and customer notice. That operational record prevents future disputes and gives the reviewer a traceable financial event rather than screenshots of internal conversation.
Example: refund approved but processor status failed
Support approves a $75 refund and tells the customer it will arrive within several days. The internal order note says 'refunded,' but the payment processor marks the credit failed. The customer later files Visa 13.6. The merchant must use processor status, not the support label, to determine whether the credit was actually processed.
If a second refund attempt later succeeds, show both attempts with references and timestamps. The evidence should make clear that the first approval was an intention and the second event moved the money. This also exposes why support systems should not use 'refunded' before payment confirmation.
Treat a credit dispute as a money-movement investigation
A credit dispute should be audited like a small ledger investigation. Start with the event that allegedly created the credit obligation: returned merchandise, canceled service, duplicate payment, price adjustment, support concession, or another documented reason. Record the amount the merchant agreed to credit and the date that obligation was recognized. Then trace the credit through the processor: refund request, processor transaction or refund ID, status, amount, destination payment, and completion or failure. This sequence separates the business decision to refund from the financial event that actually moved funds.
A common failure is a mismatch between systems. The commerce platform may mark an order as refunded as soon as an API request is created, while the payment processor later shows the refund failed. Support may then tell the customer the money was returned even though no completed credit exists. Another mismatch occurs with partial refunds: support expects $80, the warehouse selects a $60 line item, and finance never notices the remaining $20. The dispute response should use processor-confirmed money movement and reconcile it to the amount the customer was promised.
If the merchant's position is that no credit was due, the evidence question changes. Preserve the return or cancellation terms that applied at purchase, the customer's request, the merchant's response, and the facts that explain why the request did not meet those terms. Avoid relying on a current policy if it changed after the sale. Also distinguish a denial from a refund delay. A merchant that approved a credit but has not processed it should not present the policy as though the request was rejected from the beginning.
Build a refund exception queue outside the dispute process. Monitor refunds stuck in pending or failed status, credits whose amount differs from the approved concession, refunds issued to the wrong transaction, and promises that were never handed to the payments system. Reconcile support and processor data daily or at another cadence appropriate to volume. Visa 13.6 cases are often more useful as a quality signal than as a representment opportunity: they expose where the merchant's refund language, system states, and actual settlement do not agree.
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.