Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →
Debit MDR in India is split along network lines: RuPay is zero by mandate, Visa and Mastercard remain under the 2017 RBI cap. Merchants whose debit volume skews toward Visa and Mastercard pay full cap-bound MDR on every transaction that could have been routed through RuPay at zero cost, and many gateways do not surface this network mix in their default reporting.
Reconciliation classifies each debit transaction by network (BIN-derived), recomputes expected MDR as zero for RuPay and as the contracted rate (capped at 0.40% or 0.90%) for Visa and Mastercard, and compares to actual MDR deducted. Any non-zero MDR on RuPay debit is flagged as a billing error. Per-network effective-rate analysis quantifies how much of the Visa and Mastercard volume is on RuPay-eligible BINs that could have been steered through the RuPay rail.
Network-mapped MDR rule set per gateway, BIN-tier classifier (RuPay vs Visa/Mastercard vs co-badged), zero-MDR check for RuPay debit, RBI cap enforcement (0.40% / 0.90% with Rs 200 / Rs 1,000 per-transaction caps) for non-RuPay debit, monthly per-network effective-rate report.
Per-transaction MDR variance report with recoverable over-charges on RuPay debit, per-network effective-rate dashboard, BIN-mix optimisation report quantifying potential savings from steering RuPay-eligible cards through RuPay rails, and a clean fee-line reconciliation feeding the monthly expense book.
| Aspect | Detail |
|---|---|
| Instrument | Debit card (P2M) |
| Network MDR — RuPay | 0% (mandated) |
| Network MDR — Visa/Mastercard, small merchant | Up to 0.40% POS/online, 0.30% QR (per-txn cap Rs 200) |
| Network MDR — Visa/Mastercard, other merchant | Up to 0.90% POS/online, 0.80% QR (per-txn cap Rs 1,000) |
| Platform fee | Gateway-billed (varies, separate line) |
| Surcharging | Prohibited — merchants may not pass debit MDR to the customer |
| Effective date — RuPay zero | 1 January 2020 |
| Effective date — RBI cap | 1 January 2018 (still current) |
| Regulator | NPCI / RBI |
| Legal basis | PSS Act Sec 10A + Income-tax Act Sec 269SU + RBI/2017-18/105 DPSS.CO.PD No.1633 |
A finance head running a D2C or quick-commerce brand looks at the gateway settlement and sees a single fee line called “debit MDR.” It is rarely a single rate. India has structurally split debit MDR along network lines since 2020, and that split is the most under-exploited cost lever in the merchant fee stack — quieter than UPI zero-MDR, but worth real money on a debit-heavy book. RuPay debit is zero. Visa and Mastercard debit are capped, but the cap is the ceiling, not zero. The merchants who benefit are the ones whose gateway and acquirer are configured to push every RuPay-eligible BIN through the RuPay rail, and who reconcile per-network effective rates each month to confirm it is happening.
Why is RuPay debit treated differently from Visa and Mastercard debit?
The split is regulatory, not commercial. Two separate instruments overlap here, and the difference is structural.
First, the RBI circular RBI/2017-18/105 (DPSS.CO.PD No.1633/02.14.003/2017-18), effective 1 January 2018, imposed a tiered cap on debit-card MDR: 0.40 percent (POS and online) and 0.30 percent (QR-code) for “small merchants” defined as those with annual turnover up to Rs 20 lakh, subject to a per-transaction cap of Rs 200; and 0.90 percent (POS and online) and 0.80 percent (QR-code) for all other merchants, subject to a per-transaction cap of Rs 1,000. The circular also prohibits passing debit-card MDR to the customer through surcharging. This cap remains current as of June 2026.
Second, the zero-MDR mandate of January 2020 (Section 10A of the Payment and Settlement Systems Act, 2007 read with Section 269SU of the Income-tax Act, 1961 and Rule 119AA) prescribed UPI bank-account P2M and RuPay debit P2M as e-modes that businesses with turnover above Rs 50 crore must mandatorily offer, and on which no network MDR may be charged. The mandate carries a parallel Section 271DB penalty of Rs 5,000 per day for non-compliance and is funded through a Ministry of Finance incentive scheme.
Because the zero-MDR mandate covers RuPay debit specifically, and because Visa and Mastercard sit outside it, the 2017 RBI cap now binds only non-RuPay debit. A small merchant on Visa/Mastercard debit pays up to 0.40 percent; a small merchant on RuPay debit pays zero. The structural cost gap is between zero and the cap.
Where does the cost actually land in the settlement file?
In a settlement file with per-transaction detail, every debit transaction carries a payment instrument field and a card-network field (commonly VISA, MASTERCARD, or RUPAY) inferred from the card’s first six digits, the Bank Identification Number. For a Visa or Mastercard debit transaction the gateway deducts MDR within the RBI cap; for a RuPay debit transaction the gateway should deduct zero network MDR.
The cleanest audit is to group debit transactions by network and compute the per-network effective rate — total MDR divided by network volume. RuPay debit should compute to zero. Visa and Mastercard debit should compute at or below the applicable cap, subject to the per-transaction caps of Rs 200 (small merchant) or Rs 1,000 (other merchant). Anything above this is either a billing error or a configuration mismatch on the merchant-tier classification. Anything non-zero on RuPay debit is unambiguously a recoverable over-charge.
This is independent of the gateway platform fee. Some gateways bill a flat platform fee on debit transactions regardless of network — that fee is not MDR and is not subject to the zero-MDR mandate. It is a contracted commercial line. The reconciliation must keep the two separate. Confusing platform fee with network MDR is the most common cause of audit disputes that end with the merchant being wrong.
Why do most merchants under-use the zero-MDR debit rail?
Three reasons, in roughly descending order of impact.
First, BIN routing. Many issuer banks now issue dual-badged cards — a card that carries both a RuPay logo and a Visa or Mastercard logo, with two BINs, and the gateway can route the transaction through either network. The choice is a configuration in the acquirer’s processing rules. If the default is Visa or Mastercard, the merchant pays cap-bound MDR even though a zero-MDR rail was available on the same card.
Second, visibility. Default gateway dashboards do not break out debit MDR by network. The finance team sees “debit fees: Rs X” and rarely interrogates the network split. The leakage is invisible unless the reconciliation file is sliced by network.
Third, mix drift. The RuPay-versus-non-RuPay mix changes month over month with customer base, geography (RuPay penetration is higher in tier-2 and tier-3 cities and on PSU bank-issued cards), and category (RuPay penetration is higher on lower-ticket transactions). A merchant who optimised their routing in Q1 may have drifted in Q3 without anyone noticing.
What is BIN-tier steering and how does a merchant implement it?
BIN-tier steering is the practice of using the card’s Bank Identification Number — the first six digits — to determine the optimal routing network, and configuring the payment stack to route accordingly. For debit cards, the steering is straightforward: if the BIN belongs to a RuPay-issued card, route through RuPay (zero MDR); if it belongs to a Visa or Mastercard exclusive card, route through that network (cap-bound MDR); if it is a co-badged card, prefer RuPay where the issuer and acquirer both support it.
Implementation is at the acquirer or payment-aggregator level, not the merchant’s checkout. The merchant’s role is two-fold: insist that the acquirer’s routing rules default to RuPay on co-badged cards, and audit the per-network split each month to confirm the policy is being honoured. Gateway sales teams will rarely volunteer this configuration — it lowers their MDR revenue. The merchant has to ask.
A merchant that processes meaningful debit volume should request, in writing, the acquirer’s routing policy for dual-badged cards, and re-confirm it at every contract renewal. The Reserve Bank of India publishes the underlying MDR cap circulars and NPCI publishes the RuPay routing guidance; both are the regulatory foundations the merchant can cite when negotiating.
Worked example: quick-commerce D2C brand re-routing debit volume
A quick-commerce D2C brand processes Rs 1.8 crore per month in debit-card GMV through its payment gateway. Initial network mix: 30 percent RuPay, 70 percent Visa/Mastercard. The merchant is in the “other merchant” tier (annual turnover above Rs 20 lakh), so the applicable Visa/Mastercard cap is 0.90 percent; the gateway’s contracted rate is 0.85 percent.
Baseline monthly debit MDR:
- RuPay bucket: 30% of Rs 1.8 Cr = Rs 540,000 × 0% = Rs 0
- Visa/Mastercard bucket: 70% of Rs 1.8 Cr = Rs 1,260,000 × 0.85% = Rs 10,710
- Total monthly debit MDR: Rs 10,710
The merchant audits per-network effective rates, discovers the issue, and works with the acquirer to enable BIN-tier steering — routing RuPay-issued cards through the RuPay rail rather than co-badging them through Visa or Mastercard. After three months the mix shifts to 55 percent RuPay, 45 percent Visa/Mastercard. New monthly debit MDR:
- RuPay bucket: 55% of Rs 1.8 Cr = Rs 990,000 × 0% = Rs 0
- Visa/Mastercard bucket: 45% of Rs 1.8 Cr = Rs 810,000 × 0.85% = Rs 6,885
- Total monthly debit MDR: Rs 6,885
Monthly saving: Rs 10,710 minus Rs 6,885 = Rs 3,825. Annualised: Rs 45,900. GST at 18 percent applies on the MDR line only (not on the transaction value), as a separate reconciliation line, and follows the savings symmetrically — Rs 45,900 of saved MDR also means roughly Rs 8,262 of avoided GST outflow (claimable as ITC against GSTR-3B in either scenario, but a smaller fee base is still a smaller working-capital drag).
The saving scales linearly with debit volume and with the RuPay mix shift. A merchant doing Rs 18 crore monthly debit GMV with the same shift recovers Rs 38,250 per month, or Rs 459,000 annually, before GST optimisation. None of this requires the customer to do anything differently — it is purely a routing decision inside the payment stack.
Reconciliation discipline: how to make this stick
The discipline that converts a one-time configuration win into a durable reduction in debit MDR is monthly per-network effective-rate audit, fed by clean settlement data.
The minimum monthly check has three steps. First, group every debit transaction by card network. Second, compute the per-network effective rate as total MDR divided by network volume — RuPay should be zero, Visa/Mastercard should be at or below the contracted rate with the per-transaction cap respected. Third, flag two exceptions: any non-zero MDR on RuPay (a billing error, recoverable), and any per-network effective rate above the contracted rate on Visa/Mastercard (a billing error, recoverable). Both feed a fee-adjustment request to the gateway, with the per-transaction exception list as the documented basis.
The structural check, run quarterly, is the RuPay-eligible BIN audit. Pull the BIN of every Visa/Mastercard debit transaction; cross-reference against the public RuPay BIN list (issuer-bank disclosed); compute what proportion of the Visa/Mastercard volume was on RuPay-eligible BINs that could have been routed through RuPay. That proportion, multiplied by the contracted Visa/Mastercard rate, is the monthly savings opportunity on the table. If it is material, raise it with the acquirer; if it is small, the routing is working.
This is the same discipline that catches the rest of the merchant-fee leakage stack — premium and commercial cards billed at the wrong slab, domestic BINs billed at international rates, refunds where MDR was not reversed. None of these are detectable without per-transaction settlement data sliced by network and instrument.
What is your blended debit MDR really costing you?
Model your current RuPay vs Visa/Mastercard debit mix, set a realistic routing shift, and see the monthly and annual savings — broken out per network with GST and platform-fee lines kept separate.
Open the MDR Effective-Rate Calculator →Continue reading in this cluster
- MDR fee reconciliation guide — the broader workflow for verifying gateway charges against contracted rates by instrument
- Platform settlement reconciliation — multi-rail settlement matching across payment gateways and marketplaces
- What is payment gateway settlement — primer on T+1 / T+2 settlement cycles, MDR deduction, and rolling reserves
- Cluster hub: Merchant fees and MDR leakage
- Money page: Payment gateway reconciliation