A Razorpay dashboard shows Rs 1,00,000 of captured sales for the day. Two working days later the bank statement shows a NEFT credit from Razorpay's nodal account for Rs 97,640 — Rs 2,360 short. The finance analyst has been asked to explain the gap by end of day and does not know whether the shortfall is MDR, GST on MDR, a refund netted in the same batch, a chargeback freeze, a rolling reserve, or a mis-classification of the payout that has some other statutory deduction applied. The absence of a standing decomposition against the settlement file turns every payout into a fresh forensic exercise, and the recurring uncertainty erodes trust in the payment gateway relationship even when the deduction is exactly what the contract specifies.
The gap between a Razorpay dashboard gross sale total and the bank credit that arrives two days later decomposes into five buckets for a pure payment aggregator payout. Bucket 1 is the merchant discount rate applied per instrument at approximately 2 per cent on standard credit and debit cards, up to 3 per cent on Amex and Diners, zero on bank-account UPI P2M and RuPay debit P2M under the Section 269SU mandate, and by contract on subscription and international lines. Bucket 2 is 18 per cent GST on the MDR, itself ITC-eligible in the merchant's GSTR-2B where Razorpay has issued a Rule 46-compliant tax invoice. Bucket 3 is refunds initiated within the settlement window, netted against the batch gross. Bucket 4 is chargebacks under dispute — the disputed transaction value is frozen out of the payout until the dispute closes, plus a chargeback fee is typically deducted at the time the chargeback is raised. Bucket 5 is a rolling reserve of typically 5 to 10 per cent held for a rolling 180-day window for high-risk merchant categories under the RBI Master Direction on Digital Payment Security Controls. A separate scenario applies to marketplace payouts from Amazon, Flipkart, Meesho, Zomato, or Swiggy — these are e-commerce operators under Section 194O and additionally deduct 0.1 per cent income-tax TDS and 0.5 per cent Section 52 CGST TCS on top of their category commission and its 18 per cent GST.
A one-page payout decomposition template held at the AR analyst's desk with the five bucket labels down the left and one column per payout received. A payment-source master keyed by settlement narration prefix that distinguishes RAZORPAY SETTLEMENT from AMAZON PAYMENTS from ZOMATO PAYOUT — so the classification test between payment aggregator and e-commerce operator runs automatically on ingestion. A rate table for the contracted per-instrument MDR (base, premium, subscription add-on, international) that the effective-rate check runs against. A chargeback ledger tracking each disputed transaction from the freeze date to the resolution date, so the frozen amount reappears in the payout on resolution. A rolling-reserve schedule per merchant category with the T+180 release calendar. A monthly cross-check of the Razorpay Rule 46 tax invoice against the GSTR-2B ITC extraction so the 18 per cent GST on MDR is claimed as input tax credit rather than absorbed as a cost.
Every Razorpay payout that lands in the current account carries a five-bucket decomposition tag, an effective-rate calculation against the contracted rate card, and a variance flag when the effective rate exceeds the contracted rate by more than 0.15 percentage points across a settled month. The 18 per cent GST on MDR is extracted as ITC-eligible in the merchant's Day 12 GSTR-2B window rather than absorbed as a cost. Chargebacks under freeze are visible in a standing ledger with their resolution dates so the reappearing payout amount does not surprise the AR analyst. Rolling reserve releases are anticipated on the 181st day and posted against the receivable-from-aggregator balance. Any marketplace payout that carries Section 194O TDS or Section 52 CGST TCS is separated from Razorpay payouts at the source-tag level and reconciled against the operator's Form 168 for TDS and GSTR-8 for TCS, not against the Razorpay Rule 46 invoice.
You closed the day with Rs 1,00,000 of captured sales on the Razorpay dashboard. Two working days later, the HDFC current account shows a NEFT credit from Razorpay’s nodal account for Rs 97,640. Rs 2,360 is missing. The finance manager wants the answer before Friday’s standup, and the analyst has been rotating between the Razorpay dashboard, the bank statement, and the settlement file for the last forty minutes without a clean number to point at.
This is the moment before the payment gateway relationship starts to feel opaque. The deduction is almost certainly exactly what the merchant contract says it will be — but without a standing decomposition against the settlement file, the arithmetic has to be rebuilt every settlement day, and the recurring uncertainty erodes trust in the gateway even when nothing has actually gone wrong.
The quick answer
For a standard Razorpay merchant on the published 2 per cent card MDR, a Rs 1,00,000 gross sale carries a Rs 2,000 MDR plus 18 per cent GST on that MDR of Rs 360 — total deduction Rs 2,360, net settlement Rs 97,640. That is the base case: no refunds, no chargebacks, no rolling reserve, no marketplace deductions. If the gap you see is close to 2.4 per cent of gross, it is almost certainly the base case. If the gap is materially wider than 2.4 per cent, one of four other buckets is in play — refunds netted from the batch, chargebacks under dispute, a rolling reserve on a high-risk merchant category, or (most commonly) the payout is not from Razorpay at all but from a marketplace operator that deducts additional statutory levies.
Bucket 1 — MDR by instrument
The merchant discount rate is not a single number. Razorpay’s published rate card is 2 per cent for standard credit and debit cards, but the actual arithmetic runs per instrument. Bank-account UPI P2M and RuPay debit P2M carry zero network MDR under Section 269SU of the Income-tax Act 1961 read with Section 10A of the Payment and Settlement Systems Act — a mandate enforced with a Rs 5,000 per day penalty under Section 271DB on merchants above Rs 50 crore turnover who fail to offer these modes. Amex and Diners are billed at the premium slab of approximately 3 per cent across every aggregator we have tracked. EMI, international, and commercial-corporate cards carry their own contracted rates.
Enterprise merchants processing above Rs 1 crore per month commonly negotiate the base MDR down to 1.4 to 1.6 per cent from the published 2 per cent — this changes the Rs 1,00,000 arithmetic to a Rs 98,102 to Rs 98,288 net credit. If you have a negotiated rate card, reconciling against the published 2 per cent will over-report leakage and reconciling against a stale schedule will under-report. Ask the account manager for the current pricing annexure; the Razorpay MDR reconciliation guide walks the instrument-by-instrument audit.
Bucket 2 — 18 per cent GST on MDR
Razorpay’s MDR is a taxable service under GST. The 18 per cent GST on the MDR — Rs 360 on the Rs 2,000 MDR above — is billed to the merchant monthly via a Rule 46-compliant tax invoice under the CGST Rules 2017. This GST is input-tax-credit-eligible in the merchant’s GSTR-2B for the Day 12 window of the monthly close, provided the invoice appears correctly and the merchant’s GSTR-3B claims it. In effective terms, the merchant’s true cost of the payment is 2 per cent of gross after the ITC recovery, not 2.36 per cent — the ITC on the GST-on-MDR bucket is what the finance team is protecting when it insists on receiving the Rule 46 invoice on time every month.
Bucket 3 — refunds netted in the batch
Refunds initiated by the merchant in the same settlement cycle are netted against the gross of that batch before the MDR-and-GST arithmetic runs. A Rs 5,000 refund on a prior transaction against Rs 1,00,000 of new captures produces a net-of-refund batch gross of Rs 95,000, an MDR of Rs 1,900, GST on MDR of Rs 342, and a bank credit of Rs 92,758 — which reads as a “Rs 7,242 gap on Rs 1,00,000” if the refund is not surfaced. Razorpay’s settlement report carries the refund entries as negative lines against the original Order ID; the MDR-not-reversed-on-refunds treatment covers the separate leakage where the MDR on the original transaction is not reversed when the refund is processed.
Bucket 4 — chargebacks under freeze
A chargeback raised by a cardholder freezes the disputed transaction value out of the payout until the dispute closes — typically 45 to 120 days depending on the card network’s chargeback code (Visa reason 13.1, Mastercard reason 4863, Amex reason F30, and so on). During the freeze, the disputed amount is a receivable-from-aggregator on the merchant’s books, not an expense. Razorpay additionally deducts a chargeback fee — commonly Rs 500 to Rs 1,000 per dispute — at the time the chargeback is raised. If the dispute is won, the frozen amount reappears in a later payout, minus the chargeback fee; if lost, the frozen amount is written off against sales and the fee stays absorbed. The chargeback reconciliation reference covers the standing ledger discipline.
Bucket 5 — rolling reserve on high-risk categories
For merchants in high-risk categories — travel, gaming, ticketing, subscription — Razorpay withholds a rolling reserve of typically 5 to 10 per cent under the RBI Master Direction on Digital Payment Security Controls. A 10 per cent rolling reserve on Rs 1,00,000 of gross withholds Rs 10,000 for a rolling 180-day window; on Day 181 that Rs 10,000 releases into the payout if no chargeback dispute has been raised against the reserved batch. The reserve is not an expense — it is a receivable-from-aggregator that has to sit on the merchant’s balance sheet against a “Reserve with Razorpay” ledger, released 180 days later. Merchants that book the reserve as an MDR expense structurally over-state their payment cost and under-state their current assets.
The trap — you are not on Razorpay, you are on a marketplace
The most common source of a “why is my payout less” question is that the payout is not from Razorpay at all. Amazon, Flipkart, Meesho, Myntra, Ajio, Zomato, and Swiggy are e-commerce operators under Section 194O of the Income-tax Act — they deduct 0.1 per cent income-tax TDS on gross (reduced from 1 per cent with effect from 1 October 2024 by Finance (No. 2) Act 2024) and 0.5 per cent Section 52 CGST TCS (reduced from 1 per cent by Notification 15/2024-CT dated 10 July 2024, split as 0.25 per cent CGST plus 0.25 per cent SGST for intra-state or 0.5 per cent IGST for inter-state) on the net taxable supply. They also deduct their category commission — 8 to 25 per cent depending on SKU category — plus 18 per cent GST on that commission. A Rs 1,00,000 marketplace payout at a 10 per cent category commission looks more like this: Rs 1,00,000 gross minus Rs 10,000 commission minus Rs 1,800 GST on commission minus Rs 100 Section 194O TDS minus Rs 500 Section 52 CGST TCS gives Rs 87,600 net credit — a 12.4 per cent gap, not a 2.4 per cent gap. Razorpay itself, licensed under the RBI Payment Aggregator and Payment Gateway Guidelines of 17 March 2020, is a payment aggregator and not an e-commerce operator, so Section 194O and Section 52 do not apply to a pure Razorpay settlement. See the e-commerce operator vs participant classification for the statutory test.
The one to escalate first — zero-MDR leakage
If the Razorpay settlement file shows any non-zero MDR line against a bank-account UPI P2M or a RuPay debit P2M transaction, the leakage is either a mis-classification (a RuPay-credit-on-UPI transaction being grouped under UPI, which does carry an approximately 2 per cent MDR above Rs 2,000 and is not covered by the zero-mandate) or a genuine over-charge. The zero-MDR mandate under Section 269SU is enforced law, and a merchant above Rs 50 crore turnover carries a Rs 5,000 per day penalty under Section 271DB for not offering the mode — the mirror position is that any non-zero MDR being extracted on the mode is straight leakage. Sample 100 to 200 UPI and RuPay debit transactions per month and cross-check each row’s underlying rail against the MDR effective-rate calculator. This is the leakage that recovers fastest when caught, because Razorpay’s own merchant support has a clean escalation path against it.
When the weekly gap-check outgrows itself
One or two payouts a week on a single gateway is a manageable weekly reconciliation for one AR analyst. Above Rs 5 crore monthly on Razorpay, the 2 per cent MDR bucket alone is Rs 10 lakh per month, so a 0.15 percentage-point leakage against the contracted rate is Rs 15,000 per month of fee bleed — enough to fund the ongoing check. Above two active gateways in parallel, or above four active settlement sources including marketplaces, the Day 4 platform-settlement window in the monthly close playbook fragments and the manual per-payout decomposition consumes the analyst’s whole day. This is the threshold where the recovery moves off the spreadsheet and onto continuous detection — Terra Insight’s payment gateway reconciliation surface treats every payout as a scheduled feed rather than a manual copy-paste, with the five-bucket decomposition and the effective-rate audit running against every settlement as it lands, and the weekly manual check keeps its role as the discipline the system runs against.
Go deeper
- Platform settlement decomposition in Google Sheets — the working recipe
- Razorpay MDR reconciliation — published 2 per cent versus negotiated 1.4 to 1.6 per cent
- Razorpay settlement reconciliation — order-level unpacking of the net payout
- Section 194O TDS at 0.1 per cent — the rate history and the operator-participant test
- MDR effective-rate calculator — the per-network leakage audit tool
- ▸ RBI Payment Aggregator and Payment Gateway Guidelines, 17 March 2020 (updated 2022) — Payment aggregators are entities that facilitate merchants to accept various payment instruments from customers without the merchants creating a separate payment integration of their own. Aggregators receive payments from customers, pool them into a nodal account, and transfer them to the merchant after a time period. Razorpay, PayU, Cashfree, BillDesk, and Instamojo are licensed under this framework. The framework classifies these entities as payment aggregators — not e-commerce operators — and this classification is what determines that the settlement to the merchant is net of the merchant discount rate and GST on that MDR only, and does not carry Section 194O or Section 52 TCS deductions. Any merchant confused by the presence of Section 194O or Section 52 on their bank credit is either on a marketplace payout (Amazon, Flipkart, Zomato, Swiggy) that is separately mis-tagged in the ledger as a Razorpay payout, or on a hybrid payment aggregator plus e-commerce arrangement that should be separated in the payment master.
- ▸ Section 194O, Income-tax Act 1961 — as amended by Finance (No. 2) Act 2024 — An e-commerce operator paying an e-commerce participant for the sale of goods or provision of services must deduct tax at 0.1 per cent (reduced from 1 per cent with effect from 1 October 2024 by Finance (No. 2) Act 2024) of the gross amount of such sales or services at the time of credit to the participant or at the time of payment, whichever is earlier. The deduction applies where the aggregate value of sales or services exceeds Rs 5 lakh during the previous year for a resident individual or HUF participant, and without threshold for other participants. Under the Income-tax Act 2025 the same obligation carries forward as Section 393(1) Sl. 8(v) payment code 1035 at the same 0.1 per cent. Applies to Amazon, Flipkart, Meesho, Myntra, Ajio, Zomato, and Swiggy payouts to their participant merchants — does not apply to a Razorpay settlement to a merchant running its own website.
- ▸ Section 52, Central Goods and Services Tax Act 2017 — as amended by Notification 15/2024-CT (10 July 2024) — Every electronic commerce operator shall collect an amount calculated at 0.5 per cent (reduced from 1 per cent by Notification 15/2024-Central Tax dated 10 July 2024) of the net value of taxable supplies made through it by other suppliers where the consideration is to be collected by the operator. The rate is split as 0.25 per cent CGST plus 0.25 per cent SGST for intra-state supplies or charged as 0.5 per cent IGST for inter-state supplies. The credit flows to the merchant's GST electronic cash ledger via the operator's GSTR-8 (filed by the 10th of the following month) and is claimed against the merchant's own output GST liability in the same period's GSTR-3B.
- ▸ Section 269SU and Section 271DB, Income-tax Act 1961 — zero-MDR mandate — Every person carrying on business whose total sales, gross receipts, or turnover during the immediately preceding previous year exceeds Rs 50 crore shall provide the facility for accepting payment through prescribed electronic modes in addition to any facility already provided. The prescribed modes are bank-account UPI P2M and RuPay debit P2M. Section 271DB imposes a penalty of Rs 5,000 for every day of default. The wider Payment and Settlement Systems Act Section 10A prohibits the levy of a charge, whether directly or indirectly, on the payer or the beneficiary on these prescribed modes — which is the statutory basis for zero MDR on bank-account UPI P2M and RuPay debit P2M. Any non-zero MDR line on these instruments on a Razorpay or PayU settlement file is a leakage indicator.
- ▸ Rule 46, Central Goods and Services Tax Rules 2017 — tax invoice on aggregator commission — A tax invoice issued by a registered person shall contain the supplier GSTIN, the recipient GSTIN, a consecutive serial number, the description of the service, the taxable value, the rate of GST at 18 per cent, and the amount of GST charged. Razorpay's monthly GST-compliant tax invoice on MDR is what makes the 18 per cent GST on MDR ITC-eligible in the merchant's GSTR-2B for the Day 12 window — without a compliant invoice under Rule 46, the GST-on-MDR bucket cannot be recovered as input tax credit and the effective payment cost to the merchant is 2.36 per cent of gross rather than the recoverable 2 per cent.