UPI MDR (Bank Account): What You Actually Pay vs What Gateways Charge

Last updated: 23 June 2026 — Companion to 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 and payment codes 1001-1092 replacing legacy 194x sections).

Quick Reference

A finance controller looking at a settlement file for a UPI-heavy merchant will see one line that the gateway calls “MDR” or “TDR” or “gateway fee” deducted from the gross UPI credit. The instinct is to treat that as the cost of UPI — and on a card-grade 2% flat plan it reads as 2% of UPI volume per month. The statutory cost of UPI bank-account is zero. The number the controller is looking at is the gateway’s platform fee, which is a real and contractually legitimate charge, but it is structurally a different line from network MDR — and conflating the two is the most common source of fee leakage on the largest cell of an Indian merchant’s method mix. This article separates the two for CFOs and controllers, walks through a D2C ₹4 crore monthly example, and ends with the recovery playbook.

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 is network MDR on bank-account UPI?

Network MDR is the regulated or contracted instrument cost paid to the rail — for UPI, the cost the merchant would owe by virtue of the payment being made over the UPI network. For UPI P2M settled bank-to-bank, network MDR is zero by statute. The anchor is 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, and Section 269SU of the Income-tax Act read with Rule 119AA of the Income-tax Rules, which notifies UPI and RuPay debit as prescribed e-modes. The effective date is 1 January 2020 and the regime has been continuous since.

“Bank-account UPI” is a narrower category than “UPI” as the term is colloquially used. It covers a UPI transaction where the payer’s bank account is debited directly and the merchant’s bank account is credited — no card, no wallet, no PPI, no credit line in the rail. Three other UPI variants exist and they are not zero-MDR. RuPay credit card on UPI carries zero interchange at or below ₹2,000 per transaction and approximately 2% above ₹2,000 per the NPCI circular operative since October 2022. PPI and wallet-on-UPI carry interchange of 0.5% to 1.1% above ₹2,000 under the NPCI wallet-interoperability circular dated 24 March 2023. Credit-line-on-UPI is a separate instrument with its own commercials. These three cells frequently masquerade as “UPI” on the settlement file — that masquerade is the subject of a separate article in the cluster. The discipline for this article is to restrict the term “UPI” strictly to bank-account UPI P2M, where the network MDR is unambiguously zero.

What is the gateway platform fee, and why is it positive?

The gateway platform fee is the payment aggregator’s contractually agreed charge to the merchant for its services. The aggregator does real work that the merchant could not do alone — routing the transaction through the appropriate switch, running real-time risk and fraud checks, delivering a merchant dashboard, generating reconciliation files, supporting customer refunds and disputes, complying with RBI’s payment-aggregator licensing and reporting requirements. The platform fee is the price of that bundle.

For a small merchant on a headline plan the platform fee is a blended flat percentage — Razorpay and PayU publish 2%, Cashfree publishes 1.95% with a limited 1.6% promotional rate, PhonePe PG publishes 1.95% struck through with a limited “Free” promotional offer. These headline rates are designed for sub-₹5-lakh-monthly volume merchants and are not the right baseline for an enterprise account. A crore-scale UPI-heavy merchant negotiates an enterprise rate that is typically a fraction of the headline percentage on UPI bank-account volume and that may differ materially across cards, UPI, and net banking. The contracted rate per network is the reconciliation baseline; the published rate is a marketing reference.

The gateway is entitled to its contracted platform fee on every UPI bank-account transaction. What it is not entitled to is to call that fee “network MDR” on the settlement file, or to bill it at the card-grade flat percentage when the contract specifies a lower UPI-specific rate, or to apply a positive network-MDR component in addition to the platform fee. Those three are the leakage cells.

Why is conflation the leakage flag?

Three reasons.

First, the law is symmetric on the network-MDR cell. A controller defending a positive network-MDR line on bank-account UPI to an auditor has nothing to point to — Section 10A and Section 269SU are unambiguous and continuous since January 2020. A controller defending a positive platform-fee line on bank-account UPI has the master service agreement, an RBI-licensed payment-aggregator counterparty, and a legitimate service delivered. The two lines have entirely different defensibility postures, and folding them on the books erases the asymmetry.

Second, the right reconciliation baseline differs. Network MDR reconciles against the statutory zero — any positive value is a deterministic flag. Platform fee reconciles against the contracted enterprise rate per network — a per-network audit against the master service agreement. Carrying both as a single percentage line forces a single, blended reconciliation that is wrong on both ends: it concedes a positive network MDR on a zero-MDR instrument, and it benchmarks the platform fee against the wrong reference. Splitting the line restores the right baseline for each.

Third, the GST treatment differs. GST at 18% applies on the gateway’s charge to the merchant — the platform fee. It does not apply on the gross transaction value of the UPI debit. When the file carries the platform fee folded into a line called “MDR”, the GST calculation is forced onto an ambiguous base — usually the same blended line, sometimes (incorrectly) onto the gross transaction value. Splitting the platform fee onto its own line, with 18% GST on the fee as a separate line, restores the right base for the GST calculation and protects the merchant’s input-tax-credit position.

What is the right four-line structure on the books?

For one UPI bank-account transaction of gross value X processed through a payment aggregator at a contracted enterprise platform-fee rate of p percent on UPI bank-account volume, the right line structure on the books is:

The merchant’s net credit is X minus (X × p%) minus the GST on the platform fee. Where the merchant sells through a third-party e-commerce operator that deducts TDS, a fifth line captures the operator-deducted amount under the Income-tax Act 2025 framework — Section 393(1) Sl. 8(v) using payment code 1035 at 0.1% (legacy 194O at the same 0.1% rate effective from 1 October 2024 carries forward; the older 1% rate was pre-October 2024 and should not appear in any current reconciliation). The 5% rate under the PAN/Aadhaar default applies under the legacy 206AA equivalent. The TDS line is reconciled to Form 26AS rather than to the gateway settlement file.

On a direct-checkout UPI sale (the merchant’s own storefront, no marketplace operator), lines 1 to 4 are the full set and the operator-deducted line is absent.

Worked example — D2C brand, ₹4 crore monthly UPI bank-account volume

A direct-to-consumer brand on its own Shopify storefront processes ₹4 crore monthly UPI bank-account volume through Razorpay. Net banking, cards, and wallets are on the same gateway but are not in scope for this example — the focus is on the UPI bank-account cell.

The contracted enterprise plan with Razorpay specifies a 1.5% platform fee on UPI bank-account volume (illustrative — the actual contracted rate varies by merchant; for the worked example we use a rate consistent with published enterprise-tier negotiated baselines). The settlement file for one calendar month shows:

This is the correct structure. The platform fee at ₹6 lakh per month is a real, contractually agreed charge — Razorpay is an RBI-licensed payment aggregator providing routing, dashboard, settlement, and risk services for the gross UPI bank-account volume, and the platform fee is what the merchant owes for those services. The 18% GST on the platform fee is also legitimate and is claimable by the merchant as input tax credit per the standard GST treatment for payment-aggregator services.

The leakage version of the same month, on a card-grade 2% flat plan that does not separate UPI bank-account from cards, would read:

The leakage in this version is the difference between the card-grade 2% flat and the contracted enterprise rate of 1.5% on UPI bank-account volume — ₹2 lakh per month before GST, ₹2,36,000 per month with GST factored, ₹28,32,000 annualised at constant volume. The dispute language is precise. The merchant does not argue that the platform fee should be zero — Razorpay is delivering a real service for which the contracted 1.5% on UPI bank-account is owed. The merchant argues two things. First, the deducted line is not network MDR — under Section 10A and Section 269SU, the network MDR on bank-account UPI is statutorily zero, so labelling the deducted line as MDR is incorrect. Second, the deducted line is the platform fee, and the platform fee on UPI bank-account under the enterprise contract is 1.5%, not the card-grade 2% flat. The gateway re-cuts the settlement at the contracted UPI rate, refunds the difference for the audit period, and updates the rate card on the account.

Both are legitimate when correctly categorised. Conflating them is what produces the leakage.

Detection discipline — separate the two lines on every settlement

The detection methodology has four steps and runs once per settlement cycle.

Step 1 — Reclassify the deducted line. On the settlement file, identify the column the gateway uses for the deducted percentage — often labelled “MDR”, “TDR”, “Convenience fee”, or “Gateway fee”. For UPI bank-account rows, this line is the platform fee, not the network MDR. Re-label the column in the merchant’s working file to “platform fee” so the downstream reconciliation does not inherit the historical convention.

Step 2 — Capture network MDR as an explicit zero line. Add a column for network MDR with the value zero on all UPI bank-account rows. This is not cosmetic — it documents the statutory position in the audit trail and creates the deterministic flag (any positive value here is Pattern #1, a hard dispute item).

Step 3 — Compute effective platform-fee rate per network. Sum the platform fee across UPI bank-account rows and divide by the UPI bank-account volume. The result is the effective platform-fee rate on UPI for the cycle. Compare it to the contracted enterprise rate per the master service agreement. The gap times the volume is the leakage for the cycle.

Step 4 — Reconcile GST on its own line. Sum the GST line across UPI bank-account rows and confirm it equals 18% of the platform fee (not 18% of the gross UPI volume). Any deviation is a GST-base error layered on top of the platform-fee question and must be corrected before the input-tax-credit claim is filed.

For a merchant with a multi-gateway footprint, the same four-step discipline applies per gateway and the per-network effective rates are compared across gateways. A consistently lower effective platform-fee rate on UPI bank-account at gateway A versus gateway B for the same merchant size and method mix is a signal to renegotiate gateway B at the next contract cycle. The audit itself is the renegotiation evidence pack.

Recovery playbook when the lines have been conflated

Where the audit reveals that the deducted line has been carried as a single percentage against UPI bank-account volume at a card-grade flat rate, the recovery playbook has three steps.

Step A — Open the dispute as a reclassification, not a refund. The framing is critical. The merchant is not arguing that the gateway’s charge should be zero; the merchant is arguing that the charge is a platform fee, not network MDR, and that the platform fee should be billed at the contracted enterprise rate per the master service agreement rather than at the card-grade flat. This framing prevents the gateway from booking a “goodwill credit” line that leaves the underlying misclassification in place.

Step B — Present the transaction-level exception list. A summary at the network level invites negotiation. A per-transaction list with the UPI reference, the gross value, the deducted line, the contracted rate, and the corrected platform fee leaves no negotiation room — the file is the claim. Pair this with the regulatory citations (Section 10A of the Payment & Settlement Systems Act, Section 269SU of the Income-tax Act, and the NPCI public position on zero-MDR for UPI bank-account) so the account manager can route the dispute internally without re-arguing the law.

Step C — Update the rate card on the account. The dispute settlement covers the audit period. The forward-looking remediation is the corrected rate card on the account — UPI bank-account billed at the contracted enterprise platform-fee rate (typed as a platform fee, not as MDR), with the network-MDR column explicitly at zero. Confirm in writing (an account-management email is sufficient) that the corrected card is live on the account from a specified settlement period, and re-run the per-network effective-rate audit on the first settlement after the corrected card to verify.

The discipline thereafter is monthly. The per-network audit takes one analyst-day per month once the data pipeline is in place, and the recovery on a UPI-heavy merchant in the first cycle of audit usually pays for the discipline several times over. For a deeper walk-through of the same Pattern #1 case with a SaaS persona and the gateway-dispute pack template, see the cluster sibling MDR charged on zero-MDR UPI / RuPay debit. For the Razorpay-specific settlement file layout and the platform-fee column conventions across instruments, see Razorpay MDR reconciliation. For the statutory anchor itself, see the UPI zero-MDR regime under Section 269SU and the PSS Act.

What does “good” look like after remediation?

A controller running the four-line decomposition one settlement period after remediation should see:

• A column called “Network MDR” carrying zero on every UPI bank-account row, explicitly captured.
• A column called “Platform fee” carrying the contracted enterprise rate per network — UPI bank-account at the negotiated UPI-specific rate, cards at the negotiated card rate, with Amex/Diners and international cards in their own separately priced cells rather than in the standard cell.
• A column called “GST” carrying 18% of the platform fee, not 18% of the gross transaction value, and tying back to the master service agreement schedule.
• Where applicable, a column called “TDS by operator” carrying 0.1% under Section 393(1) Sl. 8(v) code 1035 (Income-tax Act 2025 framework live since 1 April 2026), reconciled to Form 26AS rather than to the gateway settlement file.
• Refund credits on the disputed audit period explicitly tied to UPI bank-account volume reclassified to the contracted rate, not to a goodwill credit line.

The forward-looking baseline is the corrected rate card on the account and the monthly per-network audit. The conflation that produced the leakage is gone because the line structure no longer permits it — network MDR is its own line at zero, platform fee is its own line at the contracted rate, GST is its own line at 18% of the fee, and any future deviation surfaces on the first cycle in which it occurs.

Continue reading in this cluster

• MDR charged on zero-MDR UPI / RuPay debit — Pattern #1 — the cornerstone leakage class
• Razorpay MDR reconciliation — settlement file layout and platform-fee column conventions
• UPI zero-MDR regime under Section 269SU and the PSS Act — the statutory anchor
• Platform fee leakage on Razorpay and PayU — published vs negotiated rate decomposition
• Merchant-fee leakage cluster hub — all eight patterns
• Payment gateway reconciliation — money page