RBI/2017-18/105 sets two Visa/Mastercard debit MDR slabs — 0.40%/0.30%/₹200-cap for merchants up to ₹20 lakh turnover, 0.90%/0.80%/₹1,000-cap for everyone above — but acquirer settlements often mis-apply the slab at outlet level, ignore the per-transaction cap on big-ticket transactions, or carry a rate above the regulatory ceiling. The merchant cannot pass the cost to the customer, so every basis point of error is a permanent margin leak.
For every non-RuPay debit settlement row, classify the channel (POS-and-online vs QR), look up the contracted slab rate for the merchant turnover tier, compute expected MDR as minimum of (rate times transaction value) and the slab cap (₹200 small / ₹1,000 large), then compare to the actual MDR deducted on the settlement file. Any positive variance is a recoverable overcharge. Roll up monthly per MID to produce an effective-rate-by-outlet view that exposes slab-classification drift across outlets.
Merchant turnover tier (small ≤ ₹20 lakh / large above), channel classifier (POS-and-online vs QR-code), contracted rate per slab, per-transaction cap clamp (₹200 / ₹1,000), MID-to-entity map so consolidated turnover drives slab assignment across all outlets, refund-MDR retention tracker since debit MDR is non-refundable industry-wide.
Per-transaction variance report flagging cap breaches and slab misclassifications, per-MID effective debit rate vs contracted rate, recoverable overcharge schedule with settlement IDs for acquirer dispute, and a monthly trend line that catches slab drift before it compounds into a multi-quarter leak.
Two Visa/Mastercard debit card transactions, both for ₹3,000, both on the same gateway, settled by the same acquirer — and the merchant pays a different MDR on each. Not because the contract is different, but because one MID was onboarded under the small-merchant slab and the other under the large-merchant slab, and neither rate was refreshed when the parent entity’s turnover crossed ₹20 lakh five years ago. The settlement netting line shows a clean number; the per-outlet effective rate hides a 50 basis point drift across the chain. RBI/2017-18/105 sets the rule — two slabs, two channels, two per-transaction caps — and the rule has not moved since 1 January 2018. The leakage is in how acquirers apply it.
Quick reference
| Aspect | Small merchant (turnover up to ₹20 lakh) | Large merchant (turnover above ₹20 lakh) |
|---|---|---|
| POS and online (card-present and card-not-present) | 0.40% of transaction value | 0.90% of transaction value |
| QR-code acceptance | 0.30% of transaction value | 0.80% of transaction value |
| Per-transaction cap | ₹200 flat ceiling | ₹1,000 flat ceiling |
| Breakeven ticket (cap bites above) | ₹50,000 at 0.40% — ₹66,667 at 0.30% | ₹1,11,111 at 0.90% — ₹1,25,000 at 0.80% |
| Applies to | Non-RuPay debit only — Visa, Mastercard, Diners debit | Non-RuPay debit only — Visa, Mastercard, Diners debit |
| Does NOT apply to | RuPay debit — zero MDR since 1 January 2020 | RuPay debit — zero MDR since 1 January 2020 |
| Customer pass-through | Prohibited — merchant cannot surcharge | Prohibited — merchant cannot surcharge |
| GST on the MDR | 18% on the fee only — separate line, never folded into MDR % | 18% on the fee only — separate line, never folded into MDR % |
| Regulator | RBI Department of Payment and Settlement Systems | RBI Department of Payment and Settlement Systems |
| Circular | RBI/2017-18/105 (DPSS.CO.PD No.1633/02.14.003/2017-18) | RBI/2017-18/105 (DPSS.CO.PD No.1633/02.14.003/2017-18) |
How does the ₹20 lakh turnover threshold split merchants between the two slabs?
RBI/2017-18/105 defines a single dividing line — annual turnover in the immediately preceding financial year. A merchant whose turnover in that year does not exceed ₹20 lakh is in the small-merchant tier. Anyone above is in the large-merchant tier. Turnover is read at the legal-entity level: one PAN, one set of audited financials, one slab. A multi-outlet hospital chain, a hotel group with twenty properties, a CA-firm-led franchise — these are all single legal entities with one turnover number, and the slab applies uniformly to every MID the entity opens with every acquiring bank.
The acquiring bank carries the operational responsibility. When an MID is created the acquirer asks the merchant for a turnover declaration, supports it with audited financials or GST returns, and tags the MID with the slab. The classification is not static — it must be re-validated annually because turnover crosses the ₹20 lakh line in only one direction for most growing businesses, and once crossed the merchant is permanently on the large slab from the next financial year. Re-validation drift is the single most common source of slab error: an outlet onboarded as small in 2019 stays tagged small in 2026 because no one refreshed the MID.
The merchant’s own discipline is to keep the turnover declaration and supporting documentation in a single place, share it consistently across acquirers, and re-issue it every April. A single legal entity should not have outlets on different slabs unless the entity itself crossed the threshold mid-period and only some MIDs have been refreshed.
What does the per-transaction cap mean in practice for big-ticket sectors?
The slab rates are not pure percentages — they are percentages capped at a flat per-transaction ceiling. For the large-merchant tier the cap is ₹1,000 on POS-and-online and ₹1,000 on QR (the rate moves from 0.90% to 0.80% but the cap stays at ₹1,000 because the cap is on the MDR amount, not the rate). The cap bites the moment 0.90% of the transaction value exceeds ₹1,000 — at exactly ₹1,11,111. Above that, the merchant pays ₹1,000 regardless of ticket size. On QR the cap bites at ₹1,25,000 because the rate is lower.
For consumer-services businesses with average tickets under ₹10,000 the cap is irrelevant — every transaction sits well below the breakeven and pays the full percentage. For hotel chains, hospital networks, jewellery retail, luxury fashion, education fees, and B2B card payments, a meaningful slice of transactions sits above the breakeven. The effective debit rate for these sectors is materially below 0.90% — and that gap is exactly what acquirer settlements need to reflect.
The leakage pattern is symmetric: an acquirer that does not apply the cap charges the full 0.90% on a ₹2 lakh hotel bill, billing ₹1,800 MDR where the regulated maximum is ₹1,000. ₹800 per transaction times tens of thousands of high-ticket transactions a year is real money.
Why is the small-merchant slab operationally rarer than it looks?
Most enterprise finance teams reading this article are on the large-merchant slab. The small-merchant slab matters in three scenarios. First, a genuinely small business — a sole-proprietor shop, a single-doctor clinic, a small CA practice billing under ₹20 lakh a year. Second, a subsidiary or special-purpose vehicle that is legally distinct from the parent and has not crossed ₹20 lakh on its own books. Third, the wrong scenario — an outlet of a larger entity that the acquirer mis-tagged as small at onboarding, where the merchant is now overpaying because the acquirer is applying the small-merchant ₹200 cap on tickets where the large-merchant ₹1,000 cap should apply, OR the merchant has been quietly moved to the large slab without contract update and is paying 0.90% where 0.40% was agreed.
The third scenario is what the audit catches. A row-level reconciliation that joins transaction value, MID, slab and actual MDR will surface the misclassification within one settlement cycle. Most merchants discover the issue only when a quarterly review notices the per-MID effective rate is anomalous.
How does the merchant-pass-through prohibition affect pricing and finance treatment?
The merchant cannot recover debit-card MDR from the customer. This is non-negotiable — RBI/2017-18/105 prohibits surcharging, Ministry of Finance directions reinforce it, and the 2013 RBI debit-card pricing guidance had already barred customer pass-through. A “card-handling fee” or “payment processing charge” added to a debit transaction at checkout is a regulatory breach.
The finance consequence: debit MDR is a permanent margin cost. It cannot be passed through, it cannot be netted against a customer line, and it is not refundable on refunds or chargebacks. Every basis point of slab misclassification or cap breach is therefore a permanent leak — recoverable only through acquirer dispute within the settlement window. Treat the MDR-on-debit line as cost of payment acceptance in the P&L, sitting under cost of goods sold or distribution cost depending on accounting policy, and track it as a per-channel metric the same way an OTA tracks gateway cost or an NBFC tracks collections cost.
Worked example — hotel chain ₹2.5 Cr monthly Visa/Mastercard debit volume
A mid-tier hotel chain with twenty properties across India processes ₹2.5 crore a month in Visa and Mastercard debit card payments at the front desk and on its online booking engine. The chain is a single legal entity, well above the ₹20 lakh threshold, contracted at the large-merchant slab — 0.90% on POS and online, 0.80% on QR, ₹1,000 per-transaction cap. The headline calculation is straightforward: 0.90% of ₹2.5 crore is ₹22,500 a month in debit MDR.
The audit gets interesting at row level. Average ticket size at the front desk is ₹35,000 — well below the ₹1,11,111 breakeven. But the chain runs corporate accounts, destination weddings and conference bookings, and 12% of transactions are above ₹1,11,111. Those transactions hit the ₹1,000 cap. Computing the effective rate: the 88% of volume below the breakeven pays the full 0.90%; the 12% of volume above pays a capped rate that on average works out to about 0.55% of transaction value for that slice. The blended effective rate lands at roughly 0.86% — below the 0.90% headline. Expected MDR is therefore closer to ₹21,500 a month, not ₹22,500. A merchant that does not model the cap is leaving ₹1,000 a month on the table by under-claiming what they should be paying.
The bigger leak is on the other side. The chain’s twenty properties were onboarded with the acquirer over six years, by different banking relationship managers, on different paper. Eight of the twenty MIDs are misclassified — three are on a 0.95% rate that exceeds the RBI cap entirely (the acquirer’s pricing engine never applied the 0.90% ceiling), and five carry the correct headline 0.90% but do not apply the ₹1,000 per-transaction cap, so high-ticket transactions are being billed at 0.90% all the way up. The average overcharge across the eight misclassified outlets is about ₹250 per outlet per month — ₹2,000 a month at the chain level, ₹24,000 a year. None of it is visible from the consolidated settlement netting line; all of it is recoverable.
The recovery process is mechanical. Pull six months of row-level settlement files for the eight outlets. For each transaction, compute expected MDR as minimum of (0.90% times value) and ₹1,000. Sum the variance. Present the acquirer with the settlement IDs, the contracted rate, the regulatory ceiling, and the cumulative overcharge per MID. A clean documented claim under ₹2 lakh typically settles within the 90-to-180-day dispute window without escalation. Going forward, the finance team adds an effective-rate-per-MID dashboard to the monthly close so the next slab drift is caught in week one, not year three.
Model your effective debit-card rate before disputing
Plug in your monthly Visa and Mastercard debit volume, average ticket size and the share of transactions above ₹1.11 lakh. The calculator returns the expected MDR under the correct slab — with cap applied — so you can compare against what your acquirer actually billed and size the recovery before raising the dispute.
Open the tool →How do I detect slab misclassification and cap breaches in the settlement file?
The detection pattern is row-level, not summary-level. A monthly settlement netting line is too aggregated — it hides the slab error inside a blended number that looks reasonable in the consolidated. Three checks, applied per transaction, surface every variance the regulator permits the merchant to recover.
The first check is the slab rate. For every non-RuPay debit transaction, divide MDR deducted by transaction value (ignoring rows where the cap clearly bit). Filter to transactions below the breakeven ticket. The implied rate should equal the contracted rate, which for a large merchant should be at most 0.90% on POS-and-online or 0.80% on QR. Any row with an implied rate above the contracted rate is a slab error; any row with an implied rate above the regulatory ceiling is a cap breach the merchant can recover unconditionally.
The second check is the per-transaction cap. For every non-RuPay debit transaction above the breakeven ticket (₹1,11,111 for large-merchant POS-and-online), expected MDR equals ₹1,000 flat. Filter to transactions where MDR deducted exceeds the ₹1,000 cap — these are unambiguous cap breaches.
The third check is the per-MID effective rate. Group by MID, sum MDR deducted divided by sum of transaction value, get the monthly effective rate per outlet. Plot against the contracted slab rate. Outlets where the effective rate exceeds the contracted rate by more than 5 basis points are candidates for slab investigation. Outlets where the effective rate is unexpectedly low across multiple months are candidates for the cap-effect check — the math should show that.
The reconciliation discipline beats reactive complaints every time. A merchant that audits monthly catches a misclassification in the first cycle; a merchant that audits annually catches it after a year of leak. The compounding cost of late detection is exactly the leakage the cap was designed to prevent.
How does this fit with RuPay debit and the rest of the debit-card cost picture?
RBI/2017-18/105 binds only on non-RuPay debit. RuPay debit P2M moved to zero network MDR on 1 January 2020 under Section 10A of the Payment and Settlement Systems Act 2007 read with Section 269SU of the Income-tax Act 1961. The 2017 caps therefore apply only to Visa, Mastercard, Diners debit and other non-RuPay debit networks. RuPay debit MDR is structurally zero — any non-zero charge on a RuPay debit transaction is a leakage flag in its own right.
The practical merchant view: blended debit volume is a mix of RuPay (zero) and non-RuPay (capped). The contracted rate the merchant signs with the acquirer is typically a single blended debit rate, which conceals the per-network reality. A hospital or hotel chain with 35–45% RuPay debit share has a true expected debit rate materially below the contracted blended number. The Visa/Mastercard slice still respects the 0.90% or ₹1,000 cap; the RuPay slice should pay zero. Reconcile per network, not per blended.
See the sibling articles on RBI/2017-18/105 — what the cap covers and what it does not, RuPay debit vs Visa/Mastercard debit MDR and MDR fee reconciliation — verifying gateway charges for the full debit-card reconciliation picture. The merchant-fees cluster hub at /insights/merchant-fees/ and the payment gateway reconciliation money page collect every relevant article and tool in one place.
What is the GST treatment of debit-card MDR for the merchant?
GST at 18% applies on the MDR fee itself, not on the transaction value. The acquirer issues a tax invoice for the MDR plus GST, the merchant pays the gross amount, and the merchant claims input tax credit on the GST line through GSTR-2B reconciliation in the normal course. The reconciliation discipline is to keep the MDR line and the GST line strictly separate on every settlement row — never fold GST into the MDR percentage, never present the gateway fee net of GST in the cost ledger without breaking out the ITC eligibility, and always tie the GST line on the settlement file to the acquirer’s tax invoice and GSTR-2B for the period.
For a hotel chain processing ₹22,500 of debit MDR a month, the GST line is ₹4,050 (₹22,500 at 18%) — fully creditable input tax. A finance team that runs the reconciliation correctly recovers the GST through ITC every month; a team that does not will leave the credit on the table and write the gross fee off as expense.
Continue reading
The merchant-fees cluster covers every slab, network, gateway and leakage pattern in Indian payment acceptance. The most relevant next stops:
- RBI/2017-18/105 — what the cap covers and what it does not for the full reading of the circular.
- RuPay debit vs Visa/Mastercard debit MDR for the network differentiation and the zero-MDR mandate.
- MDR fee reconciliation — verifying gateway charges for the end-to-end reconciliation discipline.
- Domestic BIN charged at international rate and Amex/Diners hidden in blended MDR for the high-leakage card-mix patterns.
- The merchant-fees cluster hub at /insights/merchant-fees/ for every article in one place.
The regulatory anchor is the Reserve Bank of India — Department of Payment and Settlement Systems page hosting RBI/2017-18/105. The circular has not been superseded; both slabs, both channels and both per-transaction caps remain the regulated ceiling on Visa and Mastercard debit MDR in India as of June 2026.