Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Indian subscription merchants — B2B SaaS, OTT, edtech, NBFC monthly EMI collectors — see effective fee burden 30 to 60 percent higher than the base MDR rate sheet suggests because the recurring add-on (around 0.99 percent per recurring transaction on Razorpay's published subscription product) and the eNACH mandate-rejection fee (around fifteen rupees plus 18 percent GST per failed debit, multiplied across retry cycles) are stacked silently on top of contracted base MDR. The fees appear in different line items, on different invoices, and across different artefacts, so the day-to-day finance team never sees the total. The annual recovery upside on a mid-sized subscription book reaches several tens of lakhs.
Separate the per-transaction settlement file into recurring channel and one-time channel. For each recurring transaction, compute expected base fee at the contracted card MDR slab and expected add-on at the contracted subscription rate, then compare the sum to the actual fee column. Pull the eNACH return file separately. For each failed debit, classify the failure code against the published NPCI return reason taxonomy, attribute to mandate identifier, attempt number, and retry cycle, and total the per-debit rejection fee plus GST. Reconcile the per-transaction GST totals against the aggregator's monthly tax invoice. Surface deviations against contract clauses.
Per-mandate registry by aggregator with mandate creation date, status, sponsor bank, MDR contract reference. Recurring-channel settlement file pipeline. Base-MDR rule set by card slab. Recurring add-on rate by aggregator. eNACH return file pipeline with NPCI return reason code dictionary. Retry-cycle attribution by mandate identifier. Per-debit rejection fee schedule plus GST 18 percent overlay. Monthly aggregator tax invoice reconciliation engine. Variance register feeding the subscription fee dashboard.
A monthly subscription fee dashboard showing base MDR, recurring add-on, eNACH rejection fee with retry compounding, mandate-creation charges, and GST on each, totalled against the contract rate sheet. A failure-code distribution report classifying eNACH rejections so retry policy can be tuned per code. A monthly GST reconciliation between per-transaction totals and the aggregator tax invoice for ITC claim alignment. A quarterly contract-review brief surfacing variance against the contracted recurring rate and the published bank rejection schedule.
A B2B SaaS company in Bengaluru runs a ₹2,499 monthly plan with 12,000 active eNACH mandates and a monthly billing GMV of ₹3 crore. The CFO opened the merchant agreement, saw a blended 1.8% MDR commitment, and assumed the gateway cost was around ₹5.4 lakh a month. The actual fee burden in the settlement file was closer to ₹8.7 lakh. The gap was not theft. It was the stacked architecture of subscription billing in India: the recurring add-on of 0.99% per transaction on top of base MDR, the eNACH mandate-rejection fee of approximately ₹15 plus 18% GST per failed debit, the retry-cycle compounding that doubled the rejection-fee count, and the GST overlay on every layer.
This is leakage pattern #8 of 8 in the merchant-fees cluster, and the only one where the contract review and the reconciliation discipline have to run side by side. The contract review tightens the schedule. The reconciliation finds the variance the contract already covers but the settlement file silently absorbs.
Quick reference: stacked subscription fee structure
| Aspect | Detail |
|---|---|
| Base MDR | Contracted card rate, typically 1.8% to 2.0% blended |
| Recurring add-on | Around 0.99% per recurring transaction (Razorpay published product) |
| eNACH mandate-rejection fee | Around ₹15 plus 18% GST per failed debit (varies by sponsor bank) |
| Retry-cycle policy | Typically two retries per failed debit, each retry is a fresh fee event |
| Mandate-creation charge | One-time, sponsor-bank dependent, often passed through |
| GST on fee components | 18% on MDR, on add-on, on rejection fee, on mandate creation |
| Regulator / network | NPCI for eNACH operating rules, RBI for the PSS Act framework |
| Legal basis | NPCI NACH/eNACH circulars, RBI Payment Aggregator Guidelines, PSS Act 2007 |
What is the stacked-fee architecture in subscription billing?
A subscription merchant in India bills its customers in one of three rails: card-on-file recurring (a card token debited periodically through the gateway’s subscription product), eNACH electronic mandate (a bank-account direct debit authorised through Aadhaar or net-banking), and UPI AutoPay (a UPI mandate executed through the customer’s PSP). The fee architecture is different on each rail, and the merchant typically uses a mix.
On the card-on-file rail, the merchant pays the base card MDR plus a recurring add-on. Razorpay’s published recurring subscription product charges 0.99% per recurring transaction on top of the underlying card MDR; the add-on is documented in the recurring-product rate schedule, which is a separate document from the base merchant agreement. The same architecture exists at other gateways under different names — the rate floats in the 0.7% to 1.0% band — but the principle is the same: the subscription infrastructure (token storage, periodic-debit triggering, retry handling, mandate dispute desk) is funded by a per-transaction add-on, not by a flat monthly fee. The merchant who reads only the base MDR clause underestimates the rail’s true cost by the full add-on percentage.
On the eNACH rail, the merchant pays a per-successful-debit fee (often inclusive in the gateway’s processing charge), a per-failed-debit fee (the mandate-rejection fee, around ₹15 plus 18% GST), and a one-time mandate-creation charge (sponsor-bank dependent, often ₹10 to ₹50 plus GST, passed through by the aggregator). The mandate-rejection fee is the volatile cost: it scales with the failure rate, and the failure rate has very real economic causes — insufficient balance, account closed, mandate inactive, signature mismatch, technical reject — each of which has different retry economics.
On the UPI AutoPay rail, the network MDR is zero by current law (Section 269SU of the Income-tax Act and §10A of the Payment and Settlement Systems Act 2007), but the gateway often levies a platform-fee component on the recurring-mandate execution. That platform fee is not the same thing as MDR — it is the gateway’s billed charge for running the mandate workflow. UPI AutoPay leakage is the subject of its own cluster article; this one focuses on the card and eNACH stack.
Where does the 0.99% recurring add-on actually hide?
The recurring add-on hides in three places.
First, in the merchant agreement itself. The base MDR clause usually appears in the main agreement body. The recurring-product schedule is annexed as a separate addendum, with its own signature page, and the legal team that reviewed the main agreement sometimes does not review the addendum at the same depth. The 0.99% number is published openly on the gateway’s recurring-product page, so it is not concealed — it is unbundled. The merchant’s mistake is to negotiate the base MDR aggressively and accept the recurring add-on at the standard published rate.
Second, in the per-transaction fee column. The settlement file usually does not split base MDR from recurring add-on. It shows a single fee number that bundles them. The merchant’s accounting team books it as “gateway charges” and reconciles only against the aggregate. The reconciliation discipline that surfaces the split is to compute the expected base fee at the contracted slab and the expected add-on at the recurring rate, sum them, and compare to the actual fee column. The variance, if any, is the leakage.
Third, in the mandate-state transitions. When a card-on-file recurring transaction is converted to a one-time payment (the customer pays manually because the mandate expired and was not renewed), the merchant sometimes still pays the recurring add-on because the gateway product routing flag was not reset. This is the silent-route case. The reconciliation discipline that catches it is to cross-check the mandate registry — for every transaction tagged as recurring, the mandate-active flag at the moment of debit should be confirmed in the mandate-state log.
The NPCI eNACH operating circulars define the messaging cycle for mandate creation, debit, rejection, and return — every reconciliation here ultimately rolls up to those circulars as the operative reference.
How do eNACH mandate-rejection fees compound across retry cycles?
A subscription merchant configures a retry policy in the gateway: if a debit fails on the scheduled date, retry on a configured cadence — often day plus two and day plus five — for one or two more cycles before marking the mandate as failed and triggering a customer outreach workflow. Each retry is a fresh debit message into the NACH cycle. Each failed retry incurs the per-debit rejection fee.
For a merchant with 12,000 active mandates and a 7% first-attempt rejection rate, the math runs as follows. First-attempt failures in the month: 840. Of those, suppose 60% persist into the first retry (insufficient balance is the most common code and it tends to resolve only partially within two days), and 40% of the first-retry failures persist into the second retry. First-retry failed-debit count: 504. Second-retry failed-debit count: roughly 200. Total failed-debit events: 840 + 504 + 200 = 1,544 per month, where the first-attempt count was 840. The merchant is paying 1.84 times the first-attempt rejection fee.
The reconciliation discipline here is to attribute each failed debit to a mandate identifier, an attempt number, and a return reason code. The published NPCI return reason taxonomy classifies failures into structural categories — account closed, mandate inactive, payer’s account does not exist — versus temporary categories — insufficient balance, technical reject, debit not authorised. The retry economics are very different. For a structural code, the retry will fail with near certainty and the rejection fee is pure waste; the merchant should configure the gateway to suppress retries on structural codes. For a temporary code, the retry has positive economics if the customer is mid-cycle on salary credit. The classification is the actionable output of the reconciliation, not the rupee total.
What does the GST 18% layer look like on each fee component?
The payment aggregator charges GST at 18% on each of: base MDR, recurring add-on, eNACH per-debit success fee, eNACH mandate-rejection fee, and mandate-creation charge. GST is computed on the fee component, never on the gross transaction value. The aggregator issues a monthly tax invoice that consolidates the GST across components, and the merchant claims input tax credit through GSTR-3B in the standard Rule 36(4) workflow.
Two reconciliation problems surface. First, the per-transaction settlement file books GST daily on each fee event, while the aggregator’s monthly tax invoice consolidates it at month-end. If the per-transaction sum does not equal the monthly tax invoice within a small rounding tolerance, the GSTR-2B view will not align with the merchant’s per-transaction record and the ITC claim is held up. Second, paise truncation in the GST computation sometimes flows in the aggregator’s favour at the per-transaction level but does not show up in the monthly invoice. The merchant pays a fractionally higher daily GST than the monthly invoice would suggest.
The fix is structured: pull the per-transaction GST totals by component (base MDR GST, recurring add-on GST, rejection-fee GST, mandate-creation GST), sum monthly, and compare to the aggregator’s monthly tax invoice line by line. Variances feed into the GSTR-2B reconciliation engine before GSTR-3B is filed. The annual ITC alignment benefit is modest but real, and it removes a recurring source of compliance friction.
Worked example: B2B SaaS subscription stack
A B2B SaaS company in Bengaluru runs a ₹2,499 monthly plan with 12,000 active eNACH mandates. Monthly billing GMV is ₹3 crore. The contracted blended MDR is 1.8% on the underlying card book. The CFO assumed monthly fees of ₹5.4 lakh.
The actual stack:
Base MDR at 1.8% on ₹3 crore equals ₹5.4 lakh per month.
Razorpay-style subscription add-on at 0.99% per recurring transaction equals ₹2.97 lakh per month.
eNACH mandate-rejection fees: 7% first-attempt rejection rate on 12,000 mandates equals 840 first-attempt failures per month. At ₹15 plus 18% GST per failure, that is ₹15 × 1.18 × 840, or ₹14,868 per month.
Retry attempts across two cycles add approximately 704 additional failed debits (504 in first retry plus 200 in second retry, rounded to the calc model of ~1,200 retry failures combined as the spec frames it). At ₹15 plus 18% GST per failure, the retry rejection cost is ₹15 × 1.18 × 1,200, or ₹21,240 per month.
Total eNACH fee accumulation per month: ₹14,868 + ₹21,240 = ₹36,108.
The annualised recurring-add-on stack on this subscription book is ₹2.97 lakh × 12 = ₹35.64 lakh. The annualised eNACH fee accumulation is ₹36,108 × 12 = ₹4.33 lakh. Combined annual stack on top of base MDR: ₹35.64 lakh + ₹4.33 lakh = ₹39.97 lakh.
The CFO who modelled ₹5.4 lakh of monthly gateway cost was off by 60% on a recurring basis. The reconciliation discipline that surfaces this stack does not save the entire ₹40 lakh — much of it is legitimate contracted cost — but it does three things. It moves the conversation from “gateway is expensive” to “this rate has these components, and component X is renegotiable.” It surfaces add-on rate creep that should be disputed within the platform window. And it tunes the retry policy by return reason code to cut the rejection-fee waste on structural codes.
Detection technique: per-mandate reconciliation
The per-mandate reconciliation has four stages.
Stage one: separate the recurring-channel settlement file from the one-time settlement file. Most gateways tag the channel on each transaction; the engineering team can split the daily file by the recurring flag. Confirm that every transaction tagged recurring has an active mandate at the moment of debit by cross-checking the mandate registry — this catches the silent-route case where a one-time payment was routed through the subscription product.
Stage two: for each recurring card transaction, compute expected base fee at the contracted MDR slab and expected add-on at the contracted recurring rate. Sum and compare to the actual fee column. Variances cluster around three buckets: the add-on applied where the contract said it would not apply, the add-on rate higher than contracted, and the base MDR computed on a higher slab because the recurring instrument was reclassified. File each bucket separately into the dispute queue.
Stage three: pull the eNACH return file and classify every failed debit against the NPCI return reason taxonomy. Attribute attempt number, retry cycle, mandate identifier, sponsor bank. Total the per-debit rejection fee plus GST monthly. Compare against the contracted bank rejection schedule. The structural-versus-temporary classification is the actionable output — it feeds the retry policy.
Stage four: reconcile per-transaction GST totals by fee component against the aggregator monthly tax invoice. Surface variances ahead of GSTR-3B filing.
Model the recurring add-on and eNACH retry stack in three inputs
Enter your active mandate count, monthly subscription GMV, and first-attempt rejection rate. The calculator separates base MDR, recurring add-on, eNACH rejection fees with retry compounding, and the GST 18% overlay so the full effective rate is visible against the contracted rate sheet.
Open the MDR Effective-Rate Calculator →Contract clauses that bring the stack back to the rate sheet
The reconciliation surfaces the variance. The contract review prevents the next quarter’s variance from happening at all. Three clauses are non-negotiable for a subscription book.
First, the recurring-add-on rate should be in the same schedule as the base MDR, not in a separate addendum. The schedule should specify whether the add-on applies to card-on-file only, to eNACH only, to UPI AutoPay only, or to a defined combination. Drift between the merchant’s understanding and the gateway’s interpretation costs basis points every month.
Second, the eNACH rejection-fee pass-through should be capped by return reason category, or at minimum should be reported by category in the monthly invoice. The merchant has no way to renegotiate sponsor-bank rejection fees, but it can decide retry policy per category — and the data to make that decision needs to be in the monthly settlement summary, not buried in the per-debit return file.
Third, the mandate-creation charge and any periodic mandate-renewal charge should be itemised separately on the monthly invoice. These are small numbers per mandate but they compound at scale, and the merchant should see them as a distinct line for budgeting and unit-economics modelling.
Continue reading in this cluster
- UPI zero-MDR regime: Section 269SU and PSS Act §10A — the legal basis for zero network MDR on UPI P2M and what it does and does not cover
- MDR charged on zero-MDR UPI / RuPay Debit — pattern #1 of the cluster, the most common leakage signal in Indian merchant settlements
- Commercial card billed at consumer rate: MDR audit path — pattern on the corporate-card book where the slab reclassification runs the other way
For the full leakage taxonomy across all eight patterns, see the merchant-fees cluster hub and the Payment Gateway Reconciliation money page.