MDR Charged on Zero-MDR UPI / RuPay Debit: The Most Common Leakage Pattern

Last updated: 23 June 2026 — Pattern #1 of the eight-pattern merchant-fee leakage taxonomy. Reflects the Income-tax Act 2025 framework live since 1 April 2026 (Section 393 sub-clauses + payment codes 1001-1092 replacing the legacy 194x sections).

Quick Reference

A finance controller running a per-network effective-rate audit on a UPI-heavy merchant for the first time almost always discovers that UPI bank-account volume — which has zero network MDR by statute since January 2020 — is being charged a flat percentage that the settlement report calls “MDR”. For a business with two or three crore of monthly UPI volume the recovery is six- to seven-figure rupees per quarter, and the dispute is among the cleanest in the merchant-fee category because the underlying law is settled and the data is in the gateway’s own settlement file. This article is Pattern #1 of the eight-pattern leakage taxonomy used across the merchant-fees cluster; it is the highest-frequency, highest-recovery class and the one most CFOs and controllers find first.

Zero-MDR on UPI P2M is current law as of June 2026 but under active review — the Parliamentary Standing Committee on Finance (report tabled 12 March 2026) and the Payments Council of India have proposed tiered/30 bps MDR for large merchants; no binding RBI/CBDT notification yet.

What does zero-MDR actually cover?

Zero network MDR applies to two clearly defined instruments. The first is UPI P2M settled directly bank-to-bank — a payer’s account is debited via UPI and a merchant’s account is credited; no card, no wallet, no credit line is in the rail. The second is RuPay debit at the point of sale or online, where the network has waived MDR since the same January 2020 effective date. Both are anchored in Section 10A of the Payment & Settlement Systems Act 2007, which prohibits a payment system provider or system participant from imposing a charge on a payer or beneficiary for the prescribed electronic modes; the prescribed e-modes are notified through Rule 119AA of the Income-tax Rules read with Section 269SU of the Income-tax Act.

What zero-MDR does not cover, and where leakage frequently hides under the label “UPI”, are the high-cost variants. RuPay credit card on UPI carries zero interchange at or below Rs 2,000 per transaction and approximately 2% above Rs 2,000 (split roughly 1.5% to the issuer and 0.5% to the network and acquirer) per the NPCI circular operative since October 2022. PPI and wallet-on-UPI carry interchange of 0.5% to 1.1% above Rs 2,000 under the NPCI wallet-interoperability circular dated 24 March 2023. Credit-line-on-UPI is another distinct instrument with its own commercials. These three cells are not zero-MDR — and Pattern #3 of the leakage taxonomy is the case where they masquerade under a generic “UPI” label on the settlement file. For this article we restrict attention to bank-account UPI and RuPay debit, where the mandate is unambiguous.

How does this leakage happen?

There are three operating mechanics that produce the same accounting outcome, and a controller running a fresh per-network audit will encounter all three across different gateways and different merchant categories.

Flat platform fee billed against zero-MDR volume. The most common pattern. A gateway publishes a headline 1.95% or 2% blended rate that is meant to be a platform fee for routing, reconciliation, fraud screening, and dashboard. The same flat percentage is then applied to the merchant’s UPI bank-account volume on the settlement file. The merchant sees one line called “MDR” or “gateway fee” against UPI volume and reads the magnitude as roughly 2%; the legal network MDR is zero, and the contracted platform fee for a UPI-heavy enterprise account is typically a fraction of the card-grade percentage. The over-billing is the difference between the flat card-grade percentage and the contracted UPI-specific rate.

Mis-labelled instrument. A bank-account UPI transaction is classified on the settlement file as a card or wallet payment, picking up the corresponding card-rate MDR. This shows up as a per-transaction anomaly rather than a per-network systematic gap, and the detection is a join between the instrument classification on the gateway’s settlement file and the UPI reference (RRN/UMN) on the merchant’s order-management system.

Card-grade MDR applied where the network MDR is mandated zero. Rarer in 2026, but still present in older mid-market plans and in plans where the merchant was originally onboarded on a card-heavy assumption. The settlement file shows a positive percentage line explicitly called “MDR” on UPI bank-account or RuPay debit cells. Under Section 10A read with Rule 119AA there is no lawful basis for a positive network MDR on these instruments — the dispute is direct.

Where does the leakage hide on a settlement file?

Three places.

The first is the percentage column. Any non-zero value in a column called “MDR” or “TDR” or “Network MDR” against an instrument of UPI bank-account or RuPay debit is a flag, full stop. There is no legitimate non-zero value in that column for those cells.

The second is the line label. Many gateways label their platform fee as “MDR” on the settlement file because the historical convention treated the entire merchant cost as MDR. The label itself does not constitute leakage; what matters is the underlying classification. Audit discipline requires separating “platform fee” (legitimate, billed at the contracted rate) from “network MDR” (zero on UPI bank-account and RuPay debit). The dispute language must use the right term — a gateway will defend the platform fee as a legitimate cost but cannot defend a positive network MDR on a zero-MDR instrument.

The third is the GST treatment. GST at 18% applies on the merchant fee, not on transaction value. If the GST line is calculated on the gross UPI value and not on the platform fee, that is a separate compliance error layered on top of the MDR-on-UPI question. Reconcile the GST line against the platform-fee line, not against the settlement-credit amount; the platform fee with 18% GST is what enters the merchant’s ITC claim.

Worked example: B2B SaaS, Rs 4 crore monthly UPI bank-account volume

A B2B SaaS company processing Rs 4 crore monthly UPI bank-account volume is on a Razorpay plan with a published flat rate of 2%. The settlement file for one calendar month shows a “MDR” line of Rs 8,00,000 on the full Rs 4 crore UPI bank-account volume — that is, 2% of Rs 4 crore.

The network MDR component on bank-account UPI is zero by statute. The platform fee — the legitimate gateway-billed component for routing, dashboard, reconciliation, and risk — is what the merchant contractually owes. When the SaaS company opens the contract and finds the contractually agreed enterprise platform-fee rate is 0.6% on UPI bank-account volume (the gateway’s enterprise UPI rate for this account size), the reconciliation is:

• Billed line under “MDR” label: Rs 4 crore x 2% = Rs 8,00,000
• Legitimate platform fee, reclassified at the contracted enterprise rate: Rs 4 crore x 0.6% = Rs 2,40,000
• Recovered leakage per month: Rs 8,00,000 minus Rs 2,40,000 = Rs 5,60,000
• Annualised recovery, holding volume constant: Rs 5,60,000 x 12 = Rs 67,20,000

The gateway dispute is to reclassify the deducted line. The merchant does not argue that Razorpay’s platform fee is zero — Razorpay is a regulated payment aggregator providing a real service for which a platform fee is legitimate. The merchant argues two things: first, that the deduction is not network MDR (it cannot be, on a zero-MDR instrument under Section 10A), and second, that the platform fee under their enterprise contract is 0.6%, not the card-grade 2% flat. The gateway re-cuts the settlement at 0.6%, refunds the difference for the disputed periods, and updates the rate card on the account.

GST at 18% follows the corrected fee, not the original. On the corrected Rs 2,40,000 platform fee the merchant’s GST is Rs 43,200 — a separate line, claimable as input tax credit per the standard GST treatment for payment-aggregator services. The corrected GST is also adjusted in the dispute settlement.

Detection technique: the per-network effective-rate audit

The detection methodology is the same regardless of gateway and the same regardless of business model. The discipline is to compute an effective rate per network — total fees divided by network-specific volume — and compare it to the contracted rate per network. The headline blended rate billed at the account level is not the reconciliation baseline; the per-network contracted rate is. A blended 2% headline conceals a zero-MDR UPI cell, a 0.30% to 0.90% RBI-capped non-RuPay debit cell, a ~2% Visa/Mastercard credit cell, and a 2.95% to 3.5% Amex/Diners cell — the per-network decomposition is the only way to see leakage in the UPI cell distinctly from leakage in the Amex cell.

The audit runs in five steps.

Step 1 — Decompose by instrument and network. Take the settlement file for a representative period (one month for a regular cycle; one quarter if the monthly volume is concentrated). Split every transaction into (a) instrument — UPI, card, net banking, wallet, EMI — and (b) network — UPI bank-account, RuPay credit on UPI, PPI on UPI, RuPay debit, Visa/Mastercard debit, Visa/Mastercard credit, Amex, Diners, international card. A UPI transaction that is not decomposed into the three UPI sub-networks should be reclassified per the RRN/UMN before the audit begins.

Step 2 — Sum volume and fees per network. Build a matrix where each row is a network and the columns are total volume, total deducted fee, total GST, and effective rate (deducted fee divided by volume).

Step 3 — Flag zero-MDR cells with non-zero MDR. Any positive value in the effective-rate column on UPI bank-account or RuPay debit rows is the Pattern #1 flag. This is the deterministic check.

Step 4 — Compare effective rate to contracted rate per network. For non-zero-MDR cells the audit continues to Patterns #2 through #8 (Amex/Diners premium slab, premium/rewards cards, commercial/corporate cards, domestic-as-international, refund non-reversal, recurring add-on stacking, and flat-rate cross-subsidy). For the zero-MDR cells the dispute is already actionable on the basis of step 3 alone.

Step 5 — Quantify recovery per cell and per month. Multiply the gap between effective rate and contracted rate by the network volume. Annualise. Compile the per-transaction exception list as evidence for the gateway dispute.

What is the recovery playbook?

Disputes on Pattern #1 are clean because the law is unambiguous. The playbook has three steps.

Step A — Open the dispute with a transaction-level exception report, not a summary. The gateway account manager will defend the magnitude until they see the per-transaction list with the network classification, the deducted line, the legal basis (Section 10A and Section 269SU), and the contracted rate. A summary creates negotiation room; a transaction list creates a deterministic claim. NPCI’s public position on zero-MDR is a useful third-party citation when escalation is needed — see the NPCI domain referenced in the external authority block below.

Step B — Request reclassification, not a new line. The dispute is not “we want a refund” — it is “the deducted line is mis-classified and should be reclassified as a platform fee at the contracted enterprise rate, with the difference refunded for the audit period”. This framing prevents the gateway from booking a separate “goodwill credit” line that leaves the original misclassification in place and recurs the leakage in the next cycle.

Step C — Update the rate card on the account. The settlement-period refund is the recovery for past leakage. The forward-looking remediation is the corrected rate card on the account — UPI bank-account billed at the contracted enterprise platform-fee rate, not the card-grade flat. Confirm in writing (account-management email is sufficient) that the corrected rate is live on the account from a specified settlement period onward, and re-run the per-network effective-rate audit on the first settlement after the corrected card to verify.

For a B2B SaaS, the dispute typically resolves in two to four weeks at the account-manager level. Where it does not, escalation is to the gateway’s enterprise relationship leadership, with the regulatory citations and the transaction-level exception list as the dispute pack. Reconciliation discipline thereafter is to run the per-network audit on every monthly settlement so the next misclassification is caught in the same cycle it appears, not annualised.

How does this interact with TDS and GST?

Three reconciliation lines per UPI transaction, kept separate at all times.

Network MDR. Zero on UPI bank-account and RuPay debit. Any positive number here is the Pattern #1 flag.

Platform fee with 18% GST. Legitimate gateway charge at the contracted enterprise rate, with 18% GST on the fee (not on the transaction value). The platform fee plus GST is the merchant’s deduction from the gross transaction value; GST is claimable as input tax credit subject to the standard conditions.

TDS by the e-commerce operator where applicable. Under the Income-tax Act 2025 framework live since 1 April 2026, the e-commerce operator deducts on payments to the e-commerce participant on gross transaction value at 0.1% under Section 393(1) Sl. 8(v) using payment code 1035 (the legacy 194O at 0.1% effective from 1 October 2024 carries forward at the same rate; the older 1% rate was pre-October 2024 and should not appear in current reconciliations). 5% applies under the PAN/Aadhaar default rule (legacy 206AA equivalent). No threshold for companies, firms, and LLPs; Rs 5 lakh threshold for resident individuals and HUFs with PAN/Aadhaar. The TDS line is distinct from MDR and from GST on MDR — keep all three as separate lines and reconcile each to the appropriate statutory artefact (Form 26AS for TDS, GSTR-2B for GST input tax credit, gateway settlement file for fees).

For a B2B SaaS selling directly to enterprise customers through its own checkout, code 1035 typically does not bite because the SaaS company is not selling via a third-party e-commerce operator. For an OTT or D2C business selling through an aggregator, the operator deducts code 1035 at 0.1% on gross transaction value and the merchant claims it in Form 26AS. None of this introduces any network MDR on a bank-account UPI debit.

What does “good” look like after remediation?

A controller running the per-network effective-rate audit one settlement period after remediation should see:

• Effective rate on UPI bank-account and RuPay debit cells equal to the contracted enterprise platform-fee rate (e.g., 0.6% in the worked example), with the “MDR” column reading zero or the platform fee labelled as platform fee rather than MDR.
• Effective rate on Visa/Mastercard debit cells within the RBI cap (0.40% for merchants with annual turnover up to Rs 20 lakh, 0.90% above; 0.30% / 0.80% for QR; per-transaction cap of Rs 200 / Rs 1,000) — note that RuPay debit at zero, not the Visa/Mastercard cap, applies to RuPay debit volume.
• Effective rate on Visa/Mastercard credit within the contracted enterprise rate (commonly 1.4% to 1.6% for crore-scale monthly volume) and Amex/Diners separately and explicitly priced rather than blended into the standard cell.
• GST at 18% on the platform fee, not on the transaction value, as a separate line.
• Refund credits on disputed periods explicitly tied to UPI bank-account and RuPay debit volume, not as a goodwill credit.

The forward-looking discipline is monthly. The per-network audit takes one analyst-day per month once the data pipeline is in place, and the recovery for a UPI-heavy merchant in the first audit usually pays for the discipline several times over.

Continue reading in this cluster

• Amex and Diners surcharge hidden inside blended MDR — Pattern #5
• MDR not reversed on refunds and chargebacks — Pattern #7
• RuPay credit on UPI masquerading as UPI — Pattern #3
• Merchant-fee leakage cluster hub — all eight patterns
• Payment gateway reconciliation — money page