Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Indian D2C and B2C businesses processing thirty thousand to two lakh monthly transactions across Razorpay, PayU, Cashfree, and cross-border Stripe absorb 0.05% to 0.25% of monthly volume in fee leakage because the aggregated settlement layer hides MDR slippage, instrument-mix repricing, GST-on-MDR alignment errors, undisclosed convenience and chargeback fees, paise-truncation in the aggregator's favour, and currency-conversion margin on cross-border. Without per-transaction fee-column reconciliation against the contracted rate sheet, the variance is closed every day as 'fee adjustment' and the recovery window expires unused.
Pull per-transaction settlement files daily by payment aggregator and channel. For every transaction, compute expected fee as contracted rate by instrument slab times gross. Compare to actual fee column. Surface variances by instrument, by day, by month. Aggregate month-on-month instrument-mix drift to detect repricing. Reconcile aggregator monthly tax invoice against per-transaction GST totals. For cross-border, compute expected currency conversion spread against published RBI reference rate and surface margin variance. File chargeback or rate-correction claims within platform dispute window.
Per-transaction settlement file pipeline by aggregator. Contracted rate-sheet table by instrument slab and payment channel. Fee-column reconciliation engine with PAN-merchant, transaction-id, instrument-slab, gross, expected-fee, actual-fee fields. Month-on-month instrument-mix drift detector with two-percentage-point threshold. GST-on-MDR ITC alignment workflow against aggregator monthly tax invoice. Cross-border FX spread calculator versus RBI reference rate. Chargeback dispute filer with 60-90 day window tracker. Recovery register feeding Discovered Money on fee-deduction class.
A daily fee-leakage dashboard by aggregator with rupees recoverable, dispute window, and recovery probability. A monthly instrument-mix drift report flagging repricing candidates. A monthly GST-ITC alignment report. A quarterly fee-leakage trend by aggregator for contract review preparation. A standing chargeback register tracking claims filed, claims accepted, claims rejected.
A D2C personal-care brand based in Gurgaon runs 38,000 monthly transactions through a primary Razorpay account and a secondary Cashfree account, with ₹4.2 crore of monthly gross processed volume. The contracted MDR is 1.95% on standard cards, 2.25% on premium cards, 0.4% on UPI. The CFO pulls a six-month settlement history into a single audit workbook. Multiplying contracted rates by per-channel volume, expected fees come to ₹62.3 lakh. The actual fee column on the same six months: ₹65.9 lakh. Gap: ₹3.6 lakh — 0.14% of processed volume, or roughly ₹7.2 lakh annualised at current run-rate.
That is platform fee leakage. Not theft. Not a single failure of the contract. The cumulative drag of instrument repricing, GST-on-MDR alignment drift, undisclosed convenience fees, and paise rounding that flowed in the aggregator’s direction every single day. This guide is the audit-grade playbook to find it, classify it by sub-cause, and recover it within the platform’s dispute window.
Quick reference: platform fee leakage detection map
| Leakage signal | Source artefact | Operative reference | Recovery action |
|---|---|---|---|
| Actual fee exceeds contracted rate × gross | Per-transaction settlement file | Merchant agreement clause on MDR | Per-transaction fee dispute within window |
| Instrument-mix drift month-on-month | Aggregator channel mix report | Aggregator instrument-slab schedule | Mix-drift query, BIN-range confirmation |
| GST on MDR claim does not match aggregator invoice | Monthly aggregator GST invoice vs settlement file | Rule 36(4), CGST Rules | ITC alignment in next GSTR-3B |
| Convenience fee charged but not in contract | Settlement file fee column entries | Merchant agreement schedule | Contract clause invocation, refund claim |
| Chargeback workflow fee on success | Chargeback success log vs fee debit | RBI PA-PG Guidelines | Reverse charge through dispute desk |
| Paise truncation systematic in aggregator favour | Per-transaction credit vs computed net | Aggregator settlement policy clause | Engine-level rounding query |
| FX margin exceeds disclosed spread (cross-border) | Stripe / international PA settlement vs RBI ref rate | RBI PA-CB Guidelines | Cross-border margin claim |
| Refund handling fee charged twice | Refund settlement file | Aggregator refund policy | Duplicate-charge dispute |
The architecture of platform fee opacity
A payment aggregator’s settlement output to the merchant has three structural layers. Layer one is the per-transaction success record: gross amount, payment channel, instrument tag (card, UPI, netbanking, wallet), MID reference, transaction timestamp. Layer two is the per-transaction fee record: MDR, GST on MDR, any convenience or surcharge, refund-handling if applicable, net credit. Layer three is the daily settlement aggregate that lands in the merchant’s bank.
The merchant’s finance team typically reconciles at layer three (does the day’s net credit match the gross less fees), occasionally at layer one (does each gross match the order management system), but rarely at layer two (does each fee match the contracted rate). Layer two is where the leakage lives.
The reason layer two reconciliation is uncommon: most aggregators provide the per-transaction fee file on request rather than by default, the file structure varies by aggregator and by API version, and the contracted rate sheet itself is typically a paragraph in the merchant agreement rather than a structured table. Without the structured rate table and the per-transaction fee file, the per-transaction match is operationally infeasible.
The four sub-causes of platform fee leakage
Sub-cause 1 — MDR slippage. The simplest case: a transaction was charged 2.05% MDR when the contracted rate was 2.0%. The 5-basis-point gap exists for one of three reasons. The aggregator updated the rate without notification, the merchant agreement’s notification window was abused, or the contracted rate has an unstated exclusion (premium cards above ₹50,000, EMI transactions, international cards) that the aggregator is applying liberally.
Sub-cause 2 — instrument-mix repricing. The transaction was reclassified into a higher-MDR slab. Common patterns: a ‘standard credit card’ moved to ‘premium credit card’ (typically 0.4% higher), a ‘domestic UPI’ moved to ‘UPI-Premium’ (0.2-0.4% higher because of payer-bank category), a ‘debit card’ reclassified after a BIN range update. The detection signal is month-on-month mix drift exceeding 2 percentage points on a stable customer base.
Sub-cause 3 — surcharge and convenience fee. A fee line was applied that was not in the contract. Common: a chargeback workflow fee debited on a successful chargeback that the contract said was free, a convenience fee on EMI transactions where the schedule said the convenience fee was customer-borne, a refund-handling fee on the refund of a refund.
Sub-cause 4 — cross-border FX margin. For merchants on Stripe or other PA-CB aggregators, the international transaction gets converted to INR using the aggregator’s reference rate. The disclosed currency conversion margin is typically 2.0-3.5% over the published RBI reference rate. The actual applied margin sometimes drifts higher, with the variance disappearing into the foreign-currency settlement file.
Worked example — a Gurgaon D2C personal-care brand
Setup. 38,000 monthly transactions. ₹4.2 crore monthly gross processed volume. Channel split: 52% cards (of which 22% premium), 31% UPI, 12% netbanking, 5% wallet. Contracted MDR: 1.95% standard card, 2.25% premium card, 0.4% UPI, 1.8% netbanking, 1.8% wallet. Aggregator: Razorpay primary, Cashfree secondary.
Expected fees on the channel split, computed at the per-instrument level. Standard cards: 30% × ₹4.2 cr × 1.95% = ₹2.46 lakh. Premium cards: 22% × ₹4.2 cr × 2.25% = ₹2.08 lakh. UPI: 31% × ₹4.2 cr × 0.4% = ₹0.52 lakh. Netbanking: 12% × ₹4.2 cr × 1.8% = ₹0.91 lakh. Wallet: 5% × ₹4.2 cr × 1.8% = ₹0.38 lakh. Monthly expected fee: ₹6.35 lakh.
Actual monthly fee column from six-month average: ₹6.95 lakh. Gap: ₹0.60 lakh per month, ₹7.2 lakh per year, 0.14% of processed volume.
Decomposition of the gap. ₹0.18 lakh from instrument-mix drift — premium-card mix moved from a stable 22% to 28% in three of the six months without corresponding customer behaviour change. ₹0.12 lakh from MDR slippage on EMI transactions priced 0.3% above standard credit-card rate. ₹0.14 lakh from chargeback workflow fees that the merchant agreement classified as included in MDR. ₹0.09 lakh from GST-on-MDR alignment — the aggregator’s monthly tax invoice GST total did not match the per-transaction GST sum, causing ITC under-claim. ₹0.07 lakh from paise truncation.
Recovery actions executed. (1) Instrument-mix drift query filed within 90 days — aggregator restored standard-card classification for 4.1% of disputed transactions, refund of ₹2.16 lakh. (2) EMI MDR slippage challenged with the contracted-rate document — aggregator credit-noted ₹1.44 lakh. (3) Chargeback workflow fee disputed against the agreement clause — partial refund of ₹0.84 lakh. (4) GST alignment corrected through next-quarter 3B claim — recovered ₹1.08 lakh ITC. (5) Paise truncation accepted as engine-level, raised at contract review.
Total annual recovery: ₹5.52 lakh out of ₹7.2 lakh standing leakage. Recovery rate: 76%. Residual structural leakage: ₹1.68 lakh, or 0.033% of processed volume.
Estimate platform fee leakage on your settlement volume
Enter monthly volume, channel mix, and contracted rates to project fee leakage and recovery upside across the four sub-causes.
Open the Revenue Leakage Calculator →The GST on MDR alignment problem
Payment aggregators charge GST at 18% on the MDR component of their fee. The merchant pays the GST as part of the fee deduction and claims ITC via the standard Rule 36(4) workflow. Two patterns cause alignment leakage.
Pattern A — per-transaction vs monthly invoice mismatch. The merchant’s daily reconciliation books per-transaction GST as it appears on the settlement file. The aggregator’s monthly tax invoice consolidates all GST into a single line. If the consolidated invoice does not match the merchant’s per-transaction sum, the merchant either over-claims (Section 50 interest exposure) or under-claims (permanent ITC leakage). The standard recovery is to align at month-end by booking the difference as a true-up entry.
Pattern B — convenience-fee GST treatment. Convenience fees collected from the customer (where contractually permitted) are typically a pass-through to the customer’s GST account, not the merchant’s. If the aggregator’s invoice includes convenience-fee GST without clear separation, the merchant may inadvertently claim ITC on a customer-borne component.
The contract-review checklist for the next aggregator renewal
A 6-month fee-leakage audit informs the next contract renewal. Standard asks at the renewal table.
Disclosure schedule — per-transaction fee file by default within 24 hours, not on request. Contracted rate table — structured by instrument slab with explicit exclusion clauses (premium cards, international cards, EMI, high-value above ₹X). Notification window — 60-day prior written notice for any rate change. Chargeback-fee policy — explicit on success vs failure. GST-on-MDR clarity — billing convention stated in plain language. Currency conversion margin (if cross-border) — explicit cap over RBI reference rate. Dispute window — at least 90 days from settlement date.
Putting fee-deduction leakage on the audit committee agenda
The standard quarterly pack for fee leakage: monthly processed volume by aggregator, expected vs actual fee with bps gap, decomposition by the four sub-causes, instrument-mix drift trend, disputes filed, disputes recovered, GST-ITC alignment status. The fee-deduction class is the most contractually recoverable of the seven leakage classes — the audit committee should expect material year-over-year improvement once the workflow is in place.
Continue reading on the leakage backbone
For the umbrella framing, see Revenue leakage and the Seven Classes framework. For the operating model that ties classes to recovery actions, see the Revenue leakage recovery playbook. The Stop Revenue Leakage pillar page anchors the broader story; the dedicated payment gateway reconciliation money page holds the product-side framing.