RBI Debit-Card MDR Cap (RBI/2017-18/105): What It Caps and What It Doesn't

A finance team reconciling a payment-gateway settlement sees a single line item — “MDR” — debited against a blended debit-card volume. The contract speaks of “0.90% on debit cards.” The blended volume includes Visa, Mastercard and RuPay. RBI/2017-18/105 caps non-RuPay debit MDR at 0.90% for merchants above the ₹20 lakh turnover threshold; a separate 2020 mandate puts RuPay debit at zero MDR. If the gateway applies one rate to the blended volume, the RuPay slice is being charged for something the regulator has zero-rated, and the merchant has no contractual liability to pay it. The leakage is silent because the settlement netting line never breaks the cost out by network. This article walks through what the 2017 circular actually caps, what it explicitly does not, the prohibition on customer pass-through, and the reconciliation discipline that surfaces the gap.

Quick reference

What did RBI/2017-18/105 actually rationalise?

Before December 2017, debit-card MDR in India was a patchwork of network-by-network and acquirer-by-acquirer rates that sometimes exceeded 1%. The circular replaced that patchwork with a two-slab regime tied to the merchant’s annual turnover in the previous financial year. The smaller slab — for merchants up to ₹20 lakh annual turnover — was set at 0.40% on physical POS and online card-not-present transactions, 0.30% on QR-code acceptance, and capped at ₹200 per transaction. The larger slab — everyone above ₹20 lakh — was set at 0.90% POS-and-online, 0.80% on QR, and capped at ₹1,000 per transaction.

Two structural features matter for reconciliation. First, the percentages are ceilings, not floors — acquirers may contract below them. Most enterprise gateway contracts on non-RuPay debit settle visibly under the 0.90% cap once volume is meaningful. Second, the per-transaction cap is not a percentage rebate; it is an absolute ₹ ceiling that bites whenever the implied percentage on a high-ticket transaction would exceed it. For a large-slab merchant accepting a ₹1.5 lakh hotel bill on a Visa debit card, 0.90% would be ₹1,350; the cap clamps it to ₹1,000. If the settlement shows ₹1,350, the cap has been breached.

The circular is published by RBI’s Department of Payment and Settlement Systems and remains accessible on the Reserve Bank of India website. As of June 2026 it has not been superseded; later RBI and government interventions on payments (PA-PG framework, UPI zero-MDR mandate, RuPay debit zero-MDR) operate alongside it without displacing the debit-card slabs.

What it does not cap

RBI/2017-18/105 is a debit-card circular. Three things sit outside its scope and routinely cause confusion when finance teams try to map a gateway invoice to “the cap.”

It does not cap credit cards. Credit-card MDR remains uncapped in India and is negotiated commercially. Published rate cards from Razorpay and PayU cluster around 2% for domestic Visa and Mastercard credit; American Express and Diners credit run at the premium 3% slab; enterprise-negotiated rates at ₹1 crore-plus monthly volumes typically settle materially lower than the published card.

It does not cap UPI. UPI P2M (bank-account to merchant) is zero-MDR by government mandate effective 1 January 2020 — a different legal basis (Section 10A of the Payment and Settlement Systems Act 2007 plus Section 269SU of the Income-tax Act 1961) and a different instrument. Bank-account UPI is genuinely zero; RuPay-credit-on-UPI and PPI-wallet-on-UPI carry interchange that the merchant bears.

It does not cap the gateway platform fee. RBI regulates the network MDR — the cost of the card rail itself. Payment aggregators charge a platform fee on top, which often equals or exceeds the network MDR but is contracted commercially, not regulated. A finance team that conflates the regulated network MDR with the gateway platform fee will mis-attribute over-billing. The reconciliation discipline must keep these as separate lines.

Where does the leakage actually hide?

Three patterns recur in debit-card MDR reconciliation, each invisible from the settlement netting line but auditable per-transaction.

The first is non-zero MDR on RuPay debit. Since 1 January 2020 RuPay debit P2M has been zero MDR. Yet many gateway settlement files list a non-zero MDR component against transactions whose BIN identifies them as RuPay debit. Sometimes this is a misconfiguration in the gateway’s rate engine; sometimes it is bundled platform-fee that the gateway has mislabelled as MDR. Either way, the merchant is not contractually liable, and the per-transaction recovery is the entire MDR amount charged on the RuPay slice.

The second is non-binding application of the per-transaction cap. The ₹1,000 large-merchant ceiling and ₹200 small-merchant ceiling are absolute. On high-ticket debit transactions — a hospital bill, a hotel folio, a B2B equipment purchase — 0.90% will exceed the cap and the settlement should clamp to ₹1,000. If the gateway applies the flat 0.90% without clamping, every such transaction is over-charged by the gap.

The third is wrong-slab classification. A small subsidiary or franchise outlet onboarded under the small-merchant slab should see 0.40%/0.30%/₹200, not 0.90%/0.80%/₹1,000. Acquiring-bank misclassification — common when an MID is opened against a parent-company PAN — silently doubles the rate. Conversely, a merchant on the large slab will see the lower percentage if the acquirer misclassifies, but the contractually correct cap is whatever the merchant’s turnover actually warrants.

Worked example — a hotel chain’s RuPay split

Consider a mid-size hotel chain processing ₹2.5 Cr of debit-card volume in a month across its properties. The card-network split, after BIN attribution, is 65% Visa and Mastercard and 35% RuPay. The chain is on the large-merchant slab, with a contracted 0.90% on non-RuPay debit and the regulatory zero on RuPay.

The Visa and Mastercard bucket is ₹1,625,000. At 0.90% the expected MDR is ₹1,625,000 × 0.90% = ₹14,625. Average ticket size is well below the level at which the ₹1,000 per-transaction cap bites, so the cap does not change the bucket total.

The RuPay bucket is ₹875,000. Expected MDR is ₹875,000 × 0% = ₹0.

Effective debit-card rate across both networks: ₹14,625 ÷ ₹25,00,000 = 0.585%.

Now suppose the gateway is billing 0.90% against the entire ₹2.5 Cr of debit volume — applying the non-RuPay rate to the RuPay slice. The RuPay bucket would carry an extra ₹875,000 × 0.90% = ₹7,875 of MDR per month. That is ₹94,500 of leakage per year. None of it is visible from the settlement netting line; the chain would only ever see “MDR — 0.90% on debit volume” and the contracted rate appears intact. The leakage surfaces only when the reconciliation pivots actual MDR against per-network expected MDR.

Three details to layer on top of the worked example. GST at 18% applies on the MDR fee itself, not on the transaction value, and should always sit as a separate line. The GST is recoverable as Input Tax Credit if the gateway issues a valid tax invoice and it flows through to GSTR-2B. If the gateway charges the chain’s e-commerce arm under Section 393 Sl. 8(v) (code 1035, the current 0.1% TDS on e-commerce participant payments — the rate reduced from 1% effective 1 October 2024), that is a third independent line, distinct from MDR and from GST. Three reconciliation lines, three legal bases, three recovery mechanics — never folded together.

Detection technique — the four checks

A reconciliation engine that surfaces RBI/2017-18/105 leakage runs four deterministic checks against each debit-card settlement row.

Network classification from BIN. The card BIN identifies issuer and network. The check separates RuPay debit from non-RuPay debit and tags the row accordingly. A BIN database refresh quarterly is sufficient; the major network ranges are stable.

Zero-MDR enforcement on RuPay debit. For every row tagged RuPay debit, expected MDR is zero. Any positive MDR charged is a flag — the variance is the entire fee. Roll up to a monthly schedule with gateway, MID, transaction count, total over-charge, and gateway-invoice reference.

Per-transaction cap clamp on non-RuPay debit. For every row tagged non-RuPay debit, expected MDR is min(contracted_rate × transaction_value, per_transaction_cap), where the cap is ₹200 on the small slab or ₹1,000 on the large slab. Compare to actual MDR; flag any breach. The high-ticket transactions are where this bites — concentrate the audit on the top decile of transaction values.

Refund-MDR retention. MDR is industry-non-refundable: when an order is refunded, the original MDR is not returned. Track refund-side MDR retention as a separate cost line. It is not over-billing in itself, but for businesses with significant refund or chargeback volume the cumulative drag on the contracted rate is material and must be visible.

The output of these four checks is a per-MID monthly variance schedule. The disputed amount becomes a credit-note request to the gateway support team. The non-disputable amounts — refund retention, GST on legitimate fees — become reconciled cost lines for the management P&L.

What about customer pass-through?

A separate compliance point. RBI/2017-18/105 explicitly prohibits merchants from passing debit-card MDR through to customers as a surcharge. Earlier RBI guidance from 2013 already barred surcharging on debit; the 2017 circular reinforced it as part of the rationalisation. A “card-handling fee” added at checkout on a debit transaction is in breach, exposes the merchant to acquirer-level action and potential reputational complaint, and is a control finding for any internal or statutory audit that reviews payment flows.

This matters for reconciliation in two ways. The MDR cost is a non-recoverable line — it must be budgeted as merchant cost, not as a customer pass-through. And the absence of surcharge means the entire economics of the leakage compound on the merchant balance sheet; there is no recovery mechanism other than the gateway dispute.

Continue reading in this cluster

• MDR fee reconciliation — verifying gateway charges against contracted rates — the broader workflow that the RBI cap sits inside
• Platform-fee leakage on Razorpay and PayU — separating network MDR from gateway platform fee
• Marketplace fee audit reconciliation — the equivalent discipline for marketplace settlements
• Merchant-fees cluster hub — every leakage pattern in this cluster
• Payment gateway reconciliation — pillar page — the money page that ties it all together