Mid-Month MDR Rate Renegotiation: Two Rates Both Correct

An MDR renegotiation that takes effect on the 15th of a month creates a specific reconciliation problem: for that month, and only that month, the settlement file legitimately contains two different MDR rates. Transactions captured 1–14 July settle at the old rate. Transactions captured 15 July onward settle at the new rate. Both are contractually correct. A reconciliation process that applies a single flat rate — either the old one or the new one — across the whole month will produce a variance that does not exist in economic reality but does exist in the reconciliation report, and finance teams will spend days investigating it.

The reconciliation in one paragraph

An MDR renegotiation between a streaming subscription business and its payment aggregator takes effect on 15 July 2026, moving the rate from 2.4% to 2.0%. The gateway applies the new rate to every transaction captured on or after 15 July at 00:00:00 IST, and continues to apply the old rate to transactions captured up to 14 July at 23:59:59 IST — regardless of when those transactions actually settle in the merchant’s bank account. The July settlement file therefore contains a mix. Correct reconciliation requires a rate-schedule table keyed by effective-from date, a per-transaction lookup that picks the rate applicable at capture, and a tolerance-based match that accepts both rates as valid within their windows.

What the scenario looks like in India

Payment aggregator agreements in India are commercial contracts between the merchant and the PA. RBI’s Payment Aggregator framework of 17 March 2020 sets the governance perimeter — capital adequacy, T+1 settlement, escrow, KYC of merchants — but leaves MDR itself as a commercial term. The merchant renegotiates the rate as volume grows, product mix shifts, or a competing aggregator makes an offer worth switching for.

Renegotiations in the streaming sector are common. A Netflix India–style monthly subscription business processing several lakh recurring debits per month has scale leverage that improves each quarter; a Sony LIV or ZEE5 with mixed one-time and subscription revenue negotiates blended rates that reflect the new mix; an Amazon Prime Video India–style yearly subscription plan renegotiates when the annual renewal cycle produces a large spike. Streaming audio businesses such as JioSaavn face the same dynamic on the music-subscription side.

The renegotiated rate almost never takes effect on the first of a calendar month. Two commercial realities push it into the middle:

1. Notice periods. Merchant agreements typically require 15 to 30 days written notice from either side for a rate change. Notice served on 15 June, with a 30-day period, lands the effective date at 15 July.
2. PA billing cycles. Payment aggregators run their own operational cadence for rate-card updates. Changes queued in one cycle apply from the start of the next cycle, and cycles are rarely aligned with merchant calendar months.

The result is a settlement file for the month of change that legitimately contains two rates. This is not an error. It is the correct outcome of a dated contractual amendment.

The regulatory and PG-rules overlay

Three points anchor the compliance treatment:

Zero-MDR rails are unaffected. The MeitY / DFS notification of 30 December 2019 prescribes RuPay Debit and UPI as payment modes on which no MDR may be charged. Regardless of how the credit-card MDR is renegotiated, transactions on UPI and RuPay Debit continue to attract zero MDR. The rate-schedule table must have separate branches for zero-MDR instruments so no rate is applied to them at all — a common bug is a rate change that inadvertently pushes a non-zero rate onto UPI rows because the code path was not conditioned on instrument type.

MDR is not commission for TDS purposes. Section 194H TDS at 5% applies to commission and brokerage; the CBDT has clarified in the context of e-commerce and payment intermediation that MDR paid by a merchant to an authorised payment aggregator is not commission for 194H. So the change in MDR does not change the merchant’s 194H exposure — that exposure remains zero on this line. Where the payment aggregator is also acting as an e-commerce operator in a marketplace sense, Section 194-O (code 1042 in the 2026 TDS payment code schema) may apply on the underlying transaction, but 194-O is computed on gross transaction value and is independent of the MDR rate.

GST TCS under Section 52 CGST is unaffected. The 0.5% e-commerce operator TCS applies on the net value of taxable supplies made through the platform. MDR is a deduction inside the settlement chain and does not change the value of the underlying supply. A rate change from 2.4% to 2.0% leaves the Section 52 TCS position untouched, but it does change the net settlement credited to the merchant’s bank — which is what the reconciliation is trying to match.

The Reserve Bank of India publishes the master PA framework that sets the T+1 settlement obligation, and the commercial MDR terms sit inside the merchant agreement referenced by that framework.

A worked example — illustrative numbers

Consider an illustrative streaming subscription business — pick a Netflix India–scale or ZEE5-scale subscriber base for concreteness — that renegotiates its credit-card MDR with a Razorpay or PayU aggregator, moving the rate from 2.4% to 2.0% effective 15 July 2026 at 00:00:00 IST.

Assume the following July capture profile (rounded, illustrative):

Assume input GST on MDR at 18% (9% CGST + 9% SGST for intra-state, or 18% IGST for inter-state — depending on PA and merchant registrations). GST on MDR: ₹15,69,600. Total credit-card MDR cost including input GST: ₹1,02,89,600.

Now consider three ways the reconciliation could go:

Wrong approach 1 — single flat 2.4% applied across July. Expected MDR = ₹40,00,00,000 × 2.4% = ₹96,00,000. Actual on settlement file = ₹87,20,000. Reconciliation shows a ₹8,80,000 “under-deduction” that finance investigates as a possible gateway error. The gateway is right and the reconciliation is wrong.

Wrong approach 2 — single flat 2.0% applied across July. Expected MDR = ₹40,00,00,000 × 2.0% = ₹80,00,000. Actual on settlement file = ₹87,20,000. Reconciliation shows a ₹7,20,000 “over-deduction” that finance treats as a recoverable claim against the aggregator. The claim is invalid because the old rate on pre-15 July transactions is contractually correct.

Correct approach — rate-schedule lookup per transaction. Expected MDR on pre-15 July captures = ₹18,00,00,000 × 2.4% = ₹43,20,000. Expected MDR on 15 July onward captures = ₹22,00,00,000 × 2.0% = ₹44,00,000. Total expected = ₹87,20,000, matching the settlement file within paisa-level tolerance. Zero variance.

The rate-schedule table for this reconciliation:

Now overlay a cross-window edge case. A subscription auto-debit for a monthly plan captures at 23:58:22 on 14 July but settles into the merchant’s bank on 16 July. Which rate applies? The old 2.4%. MDR is fixed at capture, not at settlement. If the reconciliation keys off settlement date instead of capture date, this transaction would incorrectly get the new rate applied and produce a paisa-level variance that quietly poisons the report.

A second edge case: a chargeback dispute won on a transaction originally captured on 10 July. The recovery lands as a positive entry in the August settlement file. When MDR is refunded on the recovery, which rate is refunded? Again, the old 2.4% — because that was the rate deducted at original capture. The rate-schedule lookup on a refund or reversal must use the capture date of the original transaction, not the date of the reversal.

Common reconciliation breakages

• Single monthly rate. Finance teams that store MDR as a per-month constant in a config file rather than as a rate-schedule table keyed by effective date create a phantom variance every time a rate changes.
• Settlement-date lookup instead of capture-date lookup. MDR is computed at capture; a reconciliation that reads settlement date and applies the current rate to old-capture transactions will double-count the variance in either direction.
• Zero-MDR bypass missed. A rate-change code path that increments the rate on all rows without checking instrument type will apply a non-zero rate to UPI and RuPay Debit rows. The settlement file will show zero MDR for these; the reconciliation will show an expected non-zero MDR; every UPI transaction will appear as a variance for the day the code shipped.
• Refund and chargeback recovery rate mismatch. A refund on a July-captured transaction that lands in an August settlement file must reverse MDR at the July rate, not the current rate. A rate-lookup that keys off the refund date produces small persistent variances that finance can never chase down.
• Cross-window capture-to-settlement transactions. A transaction captured at 23:59 on 14 July that settles on 16 July belongs in the old-rate bucket. A reconciliation that partitions the month by settlement date rather than capture date will misclassify this row.
• Input GST on MDR not scoped by rate. The GST on MDR moves with the MDR base. A rate change from 2.4% to 2.0% also shifts the GST amount. A reconciliation that computes expected GST on the old MDR total will overstate the GST expected on the new-rate transactions.
• Rate change on the same day as a public holiday. A rate that takes effect on 15 July which happens to fall on a weekend or holiday can create a mismatch between the merchant’s expectation of the effective moment and the aggregator’s application timestamp. The rate-schedule table should store the timestamp at IST midnight precision, not just the date.

How a reconciliation platform handles this

A structured reconciliation platform treats MDR rates as a first-class time-varying data object, not as a static config value.

Rate schedule stored as an effective-dated table. Every historical and current MDR rate has an effective-from timestamp at IST midnight precision, an optional effective-to (open for the current rate), an instrument-scope filter, and a payment-aggregator scope. A merchant with two aggregators (say Razorpay and Cashfree) that renegotiate at different times has two independent schedules.

Per-transaction rate lookup at reconciliation time. For every row on the settlement file, the platform pulls the capture timestamp from the transaction detail (not the settlement date), matches the instrument type, and selects the rate whose effective-from is the greatest date less than or equal to the capture timestamp. This is a deterministic lookup — same input, same output every time — which is what makes the reconciliation auditable.

Tolerance-based match. Expected MDR from the schedule is compared to the deduction on the settlement file within a tolerance that absorbs paisa-level rounding differences (gateways sometimes round MDR to the nearest paisa; the reconciliation should not fail on rounding). The tolerance is expressed both as an absolute amount and as a percentage of the transaction value, so small transactions do not trip the percentage check and large transactions do not trip the absolute check.

Split reporting. The MDR variance report is split by rate window. For a rate-change month, the report shows: total captures at old rate, expected MDR at old rate, deducted MDR at old rate, variance at old rate; then the same four fields for the new rate; then a summary row. This structure lets finance see immediately whether any variance sits in one window (a targeted issue, e.g., a specific card network reclassification) versus both windows (a broader misconfiguration).

Audit evidence pack. For each rate-change month, the platform emits a static evidence pack: the rate schedule as it stood, the count and value of transactions in each window, the total expected MDR, the total deducted MDR, and any variance with reasoned classification. This pack sits alongside the standard settlement audit trail and answers the auditor’s likely question — “how did you know both rates were correct?” — without a re-computation.

Structured payment gateway reconciliation treats MDR as time-varying data, not as a per-month constant. Reconciliation software India automates the effective-dated lookup, the tolerance match, and the split-window reporting so a rate-change month closes with the same throughput as any other month.

The Reserve Bank of India publishes the Payment Aggregator framework that governs the commercial context; the effective-date logic on MDR is a merchant-agreement construction, not a regulatory prescription. The 30 December 2019 zero-MDR notification sets the same effective-dated pattern for a different reason and is the template the industry has followed for every subsequent MDR adjustment.

The five FAQs below cover the questions finance and audit teams ask most often when a mid-month MDR change is inside a monthly close.

Frequently Asked Questions

Terra Insight Editorial Team Reconciliation Infrastructure

Content authored by practitioners with experience at Amazon India, Intuit QuickBooks, and the Tata Group. Meet the team →

Published 1 July 2026

Domain expertise

TDS Reconciliation GST Input Credit Platform Settlements NACH Batch Matching Bank Reconciliation Form 26AS Matching ERP Integrations Enterprise Finance Ops

Reviewed by

NK

Navin Krishnan

Managing Director & Founder — Terra Insight

Ex Amazon India · Intuit QuickBooks · Tata nexarc

ISO 27001:2022 Patent Pending Incorporated 2024