Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Chargeback-won recoveries return money to a streaming merchant weeks or months after the original settlement, but payment gateway settlement files rarely provide a distinct label — the credit lands as a generic adjustment or a refund reversal. Without a dedicated chargeback lifecycle log, the ledger loses the linkage between the original transaction, the dispute case number, the representation evidence, and the recovery.
Track every disputed transaction through a four-state lifecycle: Filed (acquirer notification), Represented (evidence submitted within 30 days), Won (network decision in merchant's favour), Lost (network decision against). Attach a case_id that persists across all states. Match the settlement credit at Won to the case_id, not just to the original payment_id, so the reconciliation records the dispute outcome as well as the money movement.
Chargeback lifecycle log with four states, mandatory case_id capture from acquirer notifications, positive-credit classifier that separates refund_reversed from chargeback_reversed, GL entry templates per state (Receivable at Filed, reversal at Won, write-off at Lost), and a Section 34 gate that prevents auto-generation of credit notes for chargeback_reversed events.
Chargeback case ledger with full audit trail from filing to recovery, disputes-won recovery register matched to acquirer case IDs, correctly classified settlement analytics that do not pollute refund rate, and clean GSTR-3B position with no false credit notes.
When a payment dispute is filed against a streaming merchant in India, the money is provisionally pulled from the merchant’s settlement while the case is investigated. If the merchant wins — because the representation evidence proves the transaction was authorised and the service was delivered — the acquirer returns the disputed amount in a later settlement. That returned amount looks, at first glance, identical to any other positive gateway credit. Most reconciliation systems have no dedicated label for it. It gets classified as a refund reversal, or worse, an “other adjustment”, and the audit trail from the original dispute case to the recovery is lost.
The reconciliation in one paragraph
Chargeback dispute won recovery reconciliation is the process of matching the positive credit that appears in a payment gateway settlement — the acquirer returning funds after the merchant successfully defended a chargeback — to the original disputed transaction, the acquirer’s case identifier, and the representation evidence pack that led to the win. The reconciliation must classify this credit distinctly from a refund reversal (which cancels a merchant-initiated refund) and from a settlement adjustment (which corrects a gateway posting error). Under the RBI Chargeback Framework 2018, every dispute has a case_id assigned by the acquirer or card network. That case_id — not the original payment_id alone — is the anchor for the reconciliation. Without it, a merchant handling a few dozen disputes a month can reconcile the settlement but cannot answer the CFO’s question: which of our defended chargebacks did we actually win, and how much did we recover last quarter?
What the chargeback lifecycle looks like in India
A streaming platform selling monthly subscriptions in India — plans like the Netflix India Basic tier, a Sony LIV Premium annual pack, a ZEE5 Premium plan, or a Prime Video India membership — receives payments through a payment aggregator such as Razorpay, PayU, Cashfree, Bill Desk, or CCAvenue. Payments are captured on the customer’s credit or debit card, and settlement typically arrives T+1 or T+2 net of Merchant Discount Rate (MDR), GST on MDR, and any per-transaction fees.
Some weeks or months later, the customer raises a dispute with their card-issuing bank. In India, the RBI Master Direction on the Chargeback Framework 2018 gives the issuer up to 120 days from the transaction date to file most card-not-present disputes. The typical grounds against a streaming merchant include:
- The transaction was unauthorised (customer alleges the card was used without consent).
- The service was not received (customer claims they were charged but never got access).
- Duplicate charge (customer sees two identical debits for the same billing cycle).
- Cancelled subscription still charged (auto-renewal after cancellation).
The card network — Visa, Mastercard, RuPay, Diners, or American Express, depending on the card BIN — assigns a reason code and notifies the acquirer. The acquirer notifies the merchant, usually via the payment gateway dashboard and an email, and the disputed amount is provisionally debited from the merchant’s settlement. The merchant then has a defined window — typically 30 days — to submit representation evidence.
For a streaming platform, the representation evidence pack usually includes:
- The IP address and device fingerprint captured at signup and at the disputed viewing sessions.
- Viewing telemetry: which titles were streamed, at what times, from which devices, and for how long.
- Login history around the disputed period.
- Communication records: welcome email delivery confirmation, receipt emails, any support tickets from the customer.
- Terms and conditions acceptance record showing the auto-renewal disclosure.
The card network adjudicates the representation. Where the evidence demonstrates that the service was delivered and the transaction was authorised, the network rules in the merchant’s favour. The acquirer then re-credits the disputed amount to the merchant’s next settlement — this is the chargeback-won recovery that reconciliation systems struggle to label correctly.
The regulatory and PG-rules overlay
RBI Master Direction on Chargeback Framework (2018) — This is the operating document for card dispute handling in India. It codifies the roles of the issuer, acquirer, merchant, and card network; the timelines within which each stage must complete; and the merchant’s right to submit representation. Every acquirer operating in India must maintain a chargeback log with case IDs, dispute reason codes, representation status, and outcome. The framework is card-network-neutral — Visa, Mastercard, RuPay, and others each add their own operational rules on top, but the RBI framework sets the floor.
RBI Payment Aggregator and Payment Gateway (PA-PG) framework 2020 — Under this framework, payment aggregators such as Razorpay, PayU, Cashfree, Bill Desk, and CCAvenue take responsibility for merchant onboarding, dispute handling, and settlement. When a chargeback is filed, the PA is required to notify the merchant, hold the disputed amount from settlement, and route representation evidence to the acquirer. The PA’s dispute API or dashboard is the merchant’s primary interface with the framework — the merchant does not deal directly with the card network.
GST treatment — Section 34 and Section 15 of the CGST Act 2017 — When a chargeback is lost, the merchant may treat the loss as a reduction in value of the original supply and issue a credit note under Section 34, or write it off as bad debt (which does not permit GST recovery). When a chargeback is won, no credit note is required and the original tax invoice remains valid. Section 15 governs the value of the taxable supply — the recovery does not alter that value. This distinction is where many reconciliation systems get GST wrong: auto-generating a credit note whenever a chargeback event is recorded, without checking whether the outcome was Won or Lost.
MDR treatment on chargebacks — The MDR charged on the original transaction is generally not refunded when a chargeback is won. Some acquirer contracts do refund MDR on won disputes; others treat MDR as a service fee for the transaction processing itself, independent of dispute outcome. The reconciliation must read the acquirer’s specific contract term and reflect the correct MDR position in the recovery entry.
A worked example — illustrative numbers
Consider an illustrative streaming subscription: a customer signs up on 5 January for an annual Sony LIV Premium-tier equivalent plan priced at ₹1,499 inclusive of 18% GST (₹1,270.34 taxable value + ₹228.66 IGST). The transaction is processed through Razorpay on a Visa credit card. Settlement lands on 6 January, net of MDR at 2.0% (₹29.98) plus 18% GST on MDR (₹5.40).
The merchant receives in settlement on 6 January:
| Line | Amount |
|---|---|
| Gross transaction value | ₹1,499.00 |
| Less: MDR at 2.0% | (₹29.98) |
| Less: GST on MDR at 18% | (₹5.40) |
| Net credited to merchant | ₹1,463.62 |
The merchant books this as revenue ₹1,270.34, IGST liability ₹228.66, MDR expense ₹29.98 with ITC ₹5.40, and a net settlement receivable of ₹1,463.62 cleared to bank.
Chargeback filed on 20 February — 45 days after the transaction, the issuer files a chargeback on grounds of “unauthorised transaction”. Razorpay notifies the merchant on 21 February, provisionally debiting ₹1,499 from the 22 February settlement. Razorpay assigns case_id CBK-2026-0217-A9E4 and requests representation within 30 days.
The merchant’s accounting on the Filed state:
| Account | Dr | Cr |
|---|---|---|
| Chargeback Receivable — Razorpay | ₹1,499.00 | |
| Bank / Settlement Clearing | ₹1,499.00 |
Note: no reversal of the original revenue or IGST — the dispute is open, the supply has not been formally reduced, and Section 34 does not apply until an outcome is reached.
Representation submitted on 15 March — The merchant compiles the evidence pack: IP and device match between signup and viewing sessions, 240 hours of viewing activity across the subscription period on the disputed account, login history from three devices consistent with normal household use, and receipt email delivery confirmation. No accounting entry — the case remains open.
Network decision on 12 April — Won — Visa rules in the merchant’s favour. Razorpay confirms the reversal in the settlement on 14 April, crediting ₹1,499 back to the merchant with a line item that reads “adjustment_credit” and references payment_id pay_JAN0000123 but does not clearly say “chargeback_reversed”.
The merchant’s accounting on the Won state:
| Account | Dr | Cr |
|---|---|---|
| Bank / Settlement Clearing | ₹1,499.00 | |
| Chargeback Receivable — Razorpay | ₹1,499.00 |
No credit note. No GST reversal. No ITC change. The original supply is intact.
Where reconciliation breaks: without a distinct chargeback_reversed classification, the reconciliation engine sees a positive ₹1,499 in the settlement referencing pay_JAN0000123 — a payment that already settled 98 days ago — and either flags it as an unmatched credit, or worse, matches it to a refund event and auto-generates a credit note under Section 34. Both outcomes are wrong. The first leaves an open item on the reconciliation dashboard; the second creates a GST filing error that overstates ITC reversal and understates output tax.
Common reconciliation breakages
No distinct chargeback_reversed transaction type in the settlement file. Most gateway settlement schemas provide settlement, refund, adjustment, and chargeback as core types. The chargeback field is used at the Filed state (when the amount is debited from settlement) — there is often no matching field for the Won state (when the amount is credited back). The credit lands under adjustment or refund_reversal, and the reconciliation engine has to infer the chargeback linkage from the reference field or dashboard metadata.
Missing case_id capture at Filed. Many finance teams book the chargeback debit against the original payment_id only, without capturing the acquirer’s case identifier. Months later, when the recovery arrives, there is no case_id to match against, and the credit becomes an orphaned positive item.
Refund rate KPI pollution. When chargeback-won recoveries are miscategorised as refund reversals, the refund analytics get skewed. A merchant reviewing their monthly refund-to-gross-transaction-value ratio sees an inflated refund cancellation rate, which distorts fraud-monitoring dashboards and product-analytics feeds.
Auto-generated credit notes on positive gateway credits. Some ERP integrations trigger a Section 34 credit note whenever a positive credit references a prior payment_id that already settled. This is correct for refund reversals — where the merchant had cancelled a refund and the customer’s money is going back to the merchant. It is wrong for chargeback wins — where the supply was legitimate and the dispute failed. The Section 34 gate must check outcome, not just event.
Timing mismatch between chargeback provision and recovery periods. A dispute filed in Q1 and won in Q2 crosses a reporting boundary. If the merchant provisioned a chargeback loss at Filed under a conservative policy (some do, some do not), the recovery in Q2 requires a matching income entry to reverse the provision. Without a linked case_id, the two entries do not connect and the P&L shows both a Q1 loss and a Q2 income that never net.
MDR recovery uncertainty. Different acquirer contracts treat MDR differently on won disputes. Some refund MDR when the chargeback is reversed; some do not. If the reconciliation assumes MDR refund and the acquirer does not remit it, the settlement line is short by the MDR amount and shows as an unmatched shortfall.
Multi-currency streaming subscriptions. Where a streaming merchant serves international customers charged in USD or GBP, and the dispute is filed in the customer’s currency, the recovery amount in INR at the Won date will differ from the debited amount in INR at the Filed date due to FX movement. The reconciliation must recognise both an INR chargeback receivable reversal and an FX gain or loss.
How a reconciliation platform handles this
A reconciliation platform built for Indian payment gateway operations handles chargeback-won recoveries through five capabilities that most manual and generic tools lack.
One — a dedicated chargeback lifecycle log. Every disputed transaction is tracked through the four states (Filed, Represented, Won, Lost) with the acquirer’s case_id as the primary key. The log persists across settlement periods so a recovery in April can be matched to a filing from January.
Two — positive-credit classification. When a positive credit appears in the settlement file, the platform classifies it into one of four categories: fresh settlement, refund reversal (merchant cancelled a refund), chargeback reversed (dispute won), or gateway posting correction. The classifier uses the reference fields, the linkage to the case_id captured at Filed, and any acquirer-specific metadata. Where classification is ambiguous, the item is queued for review rather than defaulting to refund reversal.
Three — a Section 34 gate. No credit note is generated automatically for a chargeback_reversed event. The gate checks the classifier output and only triggers credit note workflows for refunds and refund cancellations where the original supply value is actually being reduced.
Four — GL entry templates per state. The platform posts a Chargeback Receivable at Filed, no entry at Represented, a receivable reversal at Won or a receivable write-off to Chargeback Loss expense at Lost. Where the merchant’s accounting policy provisions a chargeback loss at Filed, the platform posts both the receivable and the provision expense, and reverses both correctly at Won.
Five — dispute-outcome analytics. A separate KPI stream tracks dispute win rate, recovery quantum, average days from Filed to Won, and reason-code distribution. This dashboard is kept out of the refund analytics feed so refund rate remains a clean signal.
Structured payment gateway reconciliation closes the gap between the settlement view and the dispute-lifecycle view. Reconciliation software India automates the four-state lifecycle tracking, the positive-credit classifier, and the Section 34 gate so a streaming merchant handling hundreds of disputes a quarter can keep the ledger, the GST filings, and the fraud dashboards consistent without manual per-case investigation.
The Reserve Bank of India publishes the Master Direction on the Chargeback Framework and the PA-PG framework, both of which set the operating rules for how disputes flow between customer, issuer, acquirer, and merchant in India.
The five FAQs below address the GST treatment, the lifecycle timing, the classification gaps, the GL entries, and the GSTR-3B position that arise most frequently in streaming merchant reconciliation.
Frequently Asked Questions
Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
- ▸ Reserve Bank of India — Master Direction on Chargeback Framework (2018) — Chargeback lifecycle, timelines, and merchant representation rights for card-not-present transactions
- ▸ Reserve Bank of India — Guidelines on Regulation of Payment Aggregators and Payment Gateways (17 March 2020) — Payment Aggregator (PA) framework governing merchant onboarding, dispute handling, and settlement obligations
- ▸ Central Goods and Services Tax Act, 2017 — Section 34 — Credit note provisions where the value of a supply is reduced after invoicing — the treatment differs for a chargeback lost versus a chargeback won
- ▸ Central Goods and Services Tax Act, 2017 — Section 15 — Value of taxable supply — determines whether a chargeback loss constitutes a reduction in value under Section 34 or a bad-debt write-off