Razorpay MDR Reconciliation: Published 2% vs Negotiated 1.4-1.6% for Indian Merchants

A Bengaluru-based OTT subscription business processes ₹4.5 crore of monthly gross merchandise value through Razorpay across UPI, cards, EMI, and net banking. The published Razorpay rate card says 2% plus GST on domestic standard. The CFO multiplies 2% by ₹4.5 crore and books ₹9 lakh of expected MDR. The actual fee column on the settlement file lands at ₹9.04 lakh and the team writes the ₹4,000 gap off as rounding. What the team has missed is that the true method-mix-weighted cost should have been closer to ₹2.4 lakh, the gateway’s platform-fee economics on UPI account for a legitimate slice of the gap, and the rest, roughly ₹4 lakh per month, is renegotiable against an enterprise tier that begins at ₹1 crore plus monthly throughput. Razorpay MDR reconciliation India is the discipline of finding that delta before the next contract renewal, not after.

Quick reference

Why the published rate is the wrong reconciliation baseline for a serious merchant

A finance team that takes the published 2% as the contracted truth is reconciling against a rate card designed for a sub-₹5-lakh-month merchant who never negotiated. The published page is a discoverability artefact; the contractual rate sits in the merchant agreement schedule and, for a crore-scale OTT, SaaS, NBFC, hotel chain, or restaurant aggregator, it is materially lower on cards. Reconciliation that anchors to the headline number under-detects leakage because it accepts a rate the contract no longer requires. The reconciliation baseline must be whatever the merchant signed in the most recent rate schedule, instrument by instrument, plus any add-on Razorpay activated when a product (Subscriptions, Recurring, EMI, Instant Settlement) was enabled.

The second misreading is treating Razorpay’s gateway platform fee as a network MDR. Bank-account UPI carries zero network MDR by law. Razorpay does, however, charge a platform fee for processing UPI bank-account transactions through its rails. That fee is legitimate, contractual, and separate from network MDR. Most settlement files surface it inside the same fee column, which is how a UPI-heavy merchant ends up paying around 2% on UPI without ever seeing a line that says MDR. Reconciliation must distinguish the two: network MDR is the regulated or negotiated cost the network and issuer take, the platform fee is what the gateway charges for service. Conflating them inflates the perceived MDR and corrupts every downstream renegotiation calculation.

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 Razorpay’s settlement file actually contain?

The Razorpay Dashboard exports a settlement report keyed on settlement_id, the batch identifier for one T+1 or T+2 NEFT credit to the merchant bank account. Each row is one captured transaction, joined to a payment_id and an order_id. The columns the finance team needs to reconcile against the contracted rate sheet are the gross transaction amount, the MDR or fee component, the GST on that fee, any refund or chargeback adjustment netted against the same batch, the net per-transaction credit, and the instrument and method metadata that lets the team classify the transaction into a slab. For Subscriptions and Recurring payments there is a flag that distinguishes a recurring debit from a one-time payment; for international transactions there is a scope marker; for EMI there is a tenure and an EMI provider field; for chargebacks there is a dispute_id reference.

The artefact that frequently confuses a first audit is the difference between gross merchandise value and gross batch value. GMV is the total ticket value across all captured transactions in a period. Gross batch value is the sum of gross on the transactions that settled into a particular bank credit, which is GMV less refunds and chargebacks netted in the same batch. Reconciliation must match the settlement_id to the bank UTR using net amount and settlement date as confirming keys, then explode the batch to per-transaction rows, then compute expected fee per row against the contracted slab. Anything else compresses the audit into an aggregate that hides the per-instrument story.

Where does Razorpay hide premium-card MDR?

The premium-card slab is the single most common source of unrecorded leakage on a Razorpay account. Amex, Diners, corporate, commercial, signature-infinite, and other premium credit cards are billed at the published 3% plus GST, but the fee column does not segregate them. They flow through the same column as standard Visa and Mastercard consumer credit. A merchant whose method mix has drifted from 4% Amex to 8% Amex over six months has structurally added cost without seeing a contract change. The detection move is mechanical: map each transaction’s BIN to its network and product tier using an acquirer-supplied BIN range table, then compute fee divided by gross for each tier. The expected differential per the published card is 100 to 150 basis points between standard consumer credit and premium; if the differential observed in the file is materially larger or smaller the reconciliation engine must flag the cell.

The corollary leakage is consumer cards billed into the 3% slab. This happens at three places. First, when the issuing bank reclassifies a consumer card into a corporate-cardholder programme without updating its BIN range in the gateway tables, the transaction silently moves to premium. Second, when the network applies a non-qualified surcharge on premium rewards cards above a threshold, the surcharge surfaces in the fee column as if it were the base rate. Third, when a domestic card is misclassified as international by the gateway’s BIN logic, the entire transaction is billed at 3% plus the international scope assessment. Each of these is a deterministic check against a BIN-to-tier table the merchant should source from its acquirer at onboarding and refresh quarterly.

How does the subscription add-on stack, and how is it billed on UPI AutoPay?

The subscription add-on is the most consequential Razorpay-specific fee structure for any recurring business. It is 0.99% per transaction added to the base MDR for any payment captured through the Subscriptions or Recurring product. A 2% domestic standard card becomes 2.99% plus GST when settled as a recurring debit. A 1.6% negotiated enterprise card becomes 2.59% plus GST. The add-on is contractually separate from base MDR, and at scale it is the single largest fee line on a subscription book.

The non-obvious case is UPI AutoPay. UPI bank-account transactions carry zero network MDR by law, so a UPI AutoPay recurring debit pays nothing on the rail. But the subscription add-on is a Razorpay-side product fee, not a network fee, so it applies on top of any platform fee the gateway charges for the UPI rail. A subscription business that has been told UPI AutoPay is free needs to read the settlement file carefully: zero network MDR on the UPI rail, plus the Razorpay UPI platform fee, plus the 0.99% subscription add-on if the transaction was captured through Subscriptions. The right reconciliation discipline is to flag every Subscriptions-product transaction in the settlement file, sum the 0.99% add-on across the month, and reconcile it against an explicit subscription line item in the contract. If the line item is missing the merchant has standing to question the billing.

Per-instrument MDR table for Razorpay

Source: Razorpay published pricing page and Razorpay UPI pricing footnotes, as of June 2026. Enterprise rate sheets contracted above ₹1 crore monthly throughput typically land at 1.4% to 1.6% on consumer credit cards; this is not a published rate and must be verified against the merchant’s own signed schedule.

Worked example: OTT subscription business, ₹4.5 crore monthly GMV

Consider a Bengaluru-based OTT subscription business with 18,000 active subscribers on a ₹2,499 monthly plan, for ₹4.5 crore of monthly gross processed through Razorpay. The method mix from twelve months of settlement files looks like this: 55% UPI bank account, 8% RuPay credit on UPI, 22% Visa and Mastercard consumer credit, 6% Amex and Diners, 5% RuPay debit, 4% other (net banking, wallets, EMI).

If the team reads only the published 2% and multiplies, the expected MDR is ₹9 lakh per month and the GST on it is ₹1.62 lakh, for a total fee burden of ₹10.62 lakh. That is the number that goes into the budget if no one rebuilds the calculation.

The method-mix-weighted true cost, assuming the merchant is on an enterprise tier of 1.5% on consumer credit cards, 3% on Amex and Diners, zero network MDR on UPI bank account, the Razorpay UPI platform fee for the rail, 2.15% platform fee on RuPay credit on UPI, and zero on RuPay debit, looks materially different.

The apparent gap between the published-rate calculation (₹9 lakh) and the method-mix-weighted enterprise calculation (₹2.42 lakh) is ₹6.58 lakh per month. That is not all leakage. The Razorpay UPI platform fee on 55% of GMV is a legitimate, contractual line that funds the gateway’s processing service for a method that carries zero network MDR. The 0.99% subscription add-on, if it is in the merchant’s contract and tied to the Subscriptions product, is also legitimate.

Decomposing the ₹6.58 lakh gap on a real audit, the team typically finds: ₹1.8 lakh of legitimate UPI platform fee that was being read as MDR, ₹1.5 lakh of contractual subscription add-on, ₹4,000 of justified chargeback dispute fees, and roughly ₹3.3 lakh of pure recoverable leakage. Of that, ₹1.1 lakh is Amex and corporate volume that should have been negotiated at a lower premium tier given the merchant’s scale, ₹0.9 lakh is refund MDR retention on cancellations that, for an OTT with a 6% monthly churn, accumulates every cycle, ₹0.7 lakh is RuPay credit on UPI billed at the 2.15% platform fee on transactions that could be steered to bank-account UPI through checkout UX, and ₹0.6 lakh is the subscription add-on stacked on UPI AutoPay debits where the rail itself costs nothing.

After the audit, with a renegotiated enterprise rate against the ₹1 crore plus tier (1.45% on consumer credit, 2.85% on premium, subscription add-on capped, instant-settlement product priced separately rather than bundled), and a checkout-UX change that steers RuPay credit on UPI users to bank-account UPI by default, the merchant lands a sustained saving of ₹4.2 lakh per month. Over a year that is ₹50.4 lakh of recovered cash with no change to the product, pricing, or customer experience.

What does an automated reconciliation tool check for a Razorpay account?

A reconciliation engine configured for a Razorpay account runs a fixed set of per-settlement checks. First, it ingests the settlement export keyed on settlement_id and joins each batch to a bank credit using settlement date and net amount, isolating any batch that fails to match. Second, it explodes each batch to per-transaction rows and computes an expected fee per row using the contracted slab matrix, comparing actual fee to expected and surfacing the variance per cell, per instrument, per network, per scope. Third, it flags every Subscriptions and Recurring product transaction and computes the 0.99% subscription add-on separately, comparing the total to a contract-derived expectation. Fourth, it maintains a refund register that tracks original MDR retained on every refunded transaction and compares the running total to monthly contracted refund processing assumptions. Fifth, it maintains a chargeback dispute fee register keyed on dispute_id with network, fee tier, and outcome columns.

Beyond the deterministic per-transaction checks, the engine surfaces three monthly views: a per-instrument effective rate (fee divided by gross per cell) that exposes when Amex, Diners, corporate, or RuPay credit on UPI volume is drifting; a method-mix drift report that catches when a UPI-heavy merchant is silently being settled with more credit-on-UPI than bank-account UPI; and a GST-on-MDR reconciliation that aligns Razorpay’s monthly tax invoice against the per-transaction GST totals from the settlement file so the ITC claim does not drift out of GSTR-3B.

For merchants where the OTT or SaaS or aggregator parent acts as an e-commerce participant on a third-party platform, a separate TDS overlay is required. Tax deducted by an e-commerce operator under Section 393(1) Sl. 8(v) payment code 1035 at 0.1% (the current rate after the Finance Act 2024 reduction; pre-1 October 2024 rate was 1%) reconciles back to Form 26AS and is distinct from MDR, from GST on MDR, and from any TDS the merchant itself deducts elsewhere. The reconciliation discipline is to keep all three as separate lines in the books and trace each to its primary regulatory authority.

Related Razorpay-specific leakage patterns

Two leakage patterns concentrate most of the renegotiable cost on a Razorpay account at scale. The first is Amex and Diners hidden inside the blended rate. A merchant on a single 2% headline rate often does not realise that 6% to 10% of its consumer credit volume is on Amex or Diners cards billed at 3% with the cost cross-subsidised by the gateway’s margin on UPI and net banking. When the gateway later reclassifies or the merchant’s mix shifts toward Amex, the cross-subsidy ends and the published premium slab applies. The audit move is to isolate per-network effective rates and validate that Amex and Diners volumes are separately and correctly priced in the contract, not folded into a blended quote. For the full pattern and recovery playbook, see Amex and Diners hidden inside blended MDR.

The second is MDR retained on refunds and chargebacks. Razorpay does not reverse MDR on refunded transactions, which means an OTT business with even modest monthly churn structurally funds the gateway’s fee on revenue it never kept. Chargeback dispute fees of ₹200 to ₹750 per case accumulate even on disputes the merchant wins. For a subscription book at scale this is the second largest recoverable cell after premium-card mispricing, and the recovery is contractual rather than operational. The standing register, dispute window discipline, and contract clauses to negotiate are covered in MDR not reversed on refunds and chargebacks.

For the broader unpacking of a Razorpay settlement file into per-order revenue postings, refund adjustments, and ITC-claimable GST on MDR, the companion guide is Razorpay settlement reconciliation: unpacking net payouts to individual orders.

Continue reading in this cluster

This article is part of the merchant-fees cluster on the Terra Insight insights hub. Companion per-gateway deep-dives in the same cluster cover Cashfree settlement reconciliation, PayU settlement reconciliation, the RBI debit card MDR cap 2017 circular, and the UPI zero-MDR regime under Section 269SU and the PSS Act. For the consolidated reconciliation engine across all gateways see the payment gateway reconciliation money page; for the underlying software stack see reconciliation software India. Finally, the canonical source for Razorpay’s headline rate cells and the contractual reference against which every settlement deduction must be checked remains the Razorpay published pricing page.