Visa Condition 13.2 centers on recurring billing after permission to charge has been withdrawn or on related recurring-payment eligibility issues. The merchant’s most important job is to reconstruct the timing. Was the disputed renewal processed before or after the customer cancelled? Did the cancellation apply immediately or at the end of the billing period? Did the merchant’s system receive the request but fail to stop future billing?
This is why a screenshot of the subscription’s current status is rarely enough. A reviewer needs the state of the subscription when the disputed charge occurred, not what the dashboard says today.
Build a subscription event log before you build the evidence packet
Export the signup date, plan, recurring cadence, billing date, renewal timestamp, cancellation request, cancellation effective date, and any refund. If the customer changed plans, paused service, or reactivated, include those events because they can explain why the account history looks inconsistent.
A clean event log lets the merchant answer the basic question without relying on memory. It should show who or what changed the subscription state and at what time. For a high-volume subscription business, this history should come from the billing system rather than a manually edited support note.
What evidence helps when the merchant says the renewal was valid
Useful records can include the original recurring authorization, purchase-time billing terms, a cancellation timestamp that falls after the disputed renewal, and evidence that the service remained active under the agreed plan. If the customer used the service after renewal, include targeted usage records only when they help explain the sequence.
Do not make “continued use” carry the whole case. A customer can use a product after a billing problem, and the network still evaluates the recurring-billing facts. The strongest packet establishes that the recurring charge was authorized at the time it was processed and that no earlier cancellation had taken effect.
Build a recurring-billing timeline that begins before the disputed renewal. Include the original enrollment, the recurring amount or pricing rule, billing cadence, renewal notices if used, the date of the disputed charge, the first cancellation request, and the effective cancellation date. If support accepted a cancellation before the renewal but billing failed to stop, that fact usually matters more than pages of login history. If the customer cancelled after the charge, distinguish the already-billed service period from future renewals rather than treating every cancellation as retroactive.
What makes a 13.2 case weak
The merchant’s position is difficult when the customer cancelled before the charge and the billing engine ignored the cancellation. It is also weak when the cancellation path technically existed but the business cannot show the request was received, processed, or confirmed. A hidden or broken cancellation flow is an operational defect, not an evidence gap that a rebuttal can repair.
Be cautious with policy language that says “cancellations require 30 days’ notice” or similar. The relevant question is not only what the policy says, but whether it was disclosed, accepted, and applied consistently to this transaction under current network and processor rules.
Refunds need their own timestamps
If a credit was issued, tie it to the disputed renewal with the payment and refund transaction IDs. A support message saying “we refunded you” does not prove the processor completed the credit. If the refund is partial, explain the amount and what service period it covers.
Do not issue a duplicate credit just because the customer says they have not seen the first one. When a chargeback is already open, follow the processor’s instructions for an existing refund so the merchant does not lose the renewal amount twice.
Design the subscription so the dispute file already exists
A good subscription system keeps a ledger of enrollment, plan changes, billing events, cancellation attempts, cancellations, and access termination. Confirmation emails should state the effective date in plain language. Finance should be able to reconcile approved refunds against actual processor credits.
Those controls reduce both disputes and evidence work. When every 13.2 case requires engineers to query production logs just to discover when a customer cancelled, the merchant has a billing-operations problem that deserves attention even if some individual disputes are won.
The merchant should preserve the exact subscription terms presented at enrollment and any later change notice. Screenshots created today are weak if the checkout changed since the customer subscribed. Store versioned terms, plan identifiers, timestamps, and cancellation confirmations with the account record. That record improves both dispute handling and billing QA because it lets the team identify whether the failure was customer misunderstanding, a delayed support action, or a technical renewal that should have been stopped.
Example: cancellation request arrived before renewal but after invoice generation
A subscription platform generates an invoice on June 28, the customer cancels on June 29, and the payment captures July 1. The merchant must distinguish invoice creation from the actual renewal/billing event and apply the purchase-time cancellation terms to the real timeline.
If support confirmed cancellation before capture, that promise becomes a material transaction fact. The correct response may be very different from a case where cancellation occurred after a valid renewal and the customer continued using the service. A timestamped lifecycle prevents those two scenarios from being treated alike.
Audit the cancellation boundary, not just the subscription status shown today
Recurring-billing disputes become confusing when teams rely on the account's current label—active, canceled, expired, paused—instead of reconstructing the state at the moment the challenged renewal was processed. Build a state history that includes enrollment, plan changes, billing-cycle changes, pause or reactivation events, cancellation attempts, confirmation messages, renewal, and access termination. For every change, identify the system that created it. A customer-service note, billing-provider object, and product-access flag can disagree, and that disagreement is often the real cause of a 13.2 case.
The most important boundary is the time between the customer's withdrawal of permission and the challenged charge. Preserve the first cancellation request, not merely the date an employee later closed the account. If the business offers self-service cancellation, export the event showing when the request was submitted and whether it completed. If support handles cancellation, keep the customer's message and the agent's response. If cancellation becomes effective at the end of a paid period, show that effective date in the terms and confirmation rather than assuming the reviewer will understand the product's billing model.
Then reconcile access and money separately. Continued access after a valid renewal can help explain what service period the merchant says was purchased, but it should not erase an earlier cancellation request. Likewise, a canceled account does not automatically mean every earlier charge was invalid. Map the disputed charge to one service period, show what access or performance belonged to that period, and list any refund. If the merchant promised a refund, confirm the payment processor actually completed it. A support message using the word refunded should never substitute for the credit transaction itself.
Use losses to test the subscription design. Customers should be able to tell the renewal amount, cadence, cancellation method, effective date, and whether a cancellation applies immediately or after the current term. Internally, support and billing should change the same source of truth or have a reliable synchronization path. Track cases where support said canceled but billing renewed, where a cancellation event failed, and where a refund promise did not settle. Those are operational defects that a stronger dispute packet cannot permanently solve.
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.