Paytm Payment Gateway MDR Reconciliation for Indian Merchants

Paytm Payment Gateway is one of the older payment aggregators in the Indian market and one of the few whose parent group is simultaneously a UPI app, a Prepaid Payment Instrument (PPI) issuer and a payment gateway. That triple role is what makes Paytm PG reconciliation distinctive: the same brand appears on three rails with three different pricing structures, and the settlement file groups them in a way that is rail-correct but instrument-misleading. For a CFO closing books or a controller signing off the monthly MDR accrual, the reconciliation discipline has to do work that the rate card does not — separating bank-account UPI from wallet-on-UPI from credit-on-UPI inside the same “UPI” line, isolating Amex and Diners from the blended slab, and tracking chargeback dispute fees and refund-retained MDR that never reverse out of the fee bucket on their own.

Quick-Reference

What does Paytm Payment Gateway’s pricing structure actually look like?

Paytm Payment Gateway, like its closest peers in the Indian market, publishes a two-slab structure: a standard slab in the ~1.99–2% band that applies to domestic credit and debit cards, net banking, UPI and wallet acceptance, and a premium slab at 3% that applies to American Express, Diners Club, international card acceptance and EMI. Custom rates are typically available for higher-volume merchants, but those are negotiated rather than published — the standard published slab is the right reconciliation baseline only for merchants who have not signed a custom schedule.

Two things sit underneath the published slab and matter operationally. First, the network MDR on UPI bank-account payment-to-merchant transactions is zero by regulatory mandate (Section 269SU of the Income-tax Act 1961 read with Section 10A of the Payment and Settlement Systems Act 2007, in effect since 1 January 2020), and on RuPay debit P2M transactions is also zero by NPCI mandate since the same date. Any fee billed against these instruments in the settlement file is therefore a platform fee of the gateway, not a network MDR — the two are distinct rails and should be reconciled as separate lines. Second, the published ~1.99–2% slab covers the bank-account UPI case; the wallet-on-UPI and RuPay credit-on-UPI cases — both of which can be initiated through the same UPI rail and the same UPI handle — carry NPCI interchange that is separate from the gateway’s blended slab.

For a finance team, the operational read is that the Paytm settlement file’s “UPI” line is a rail label, not an instrument label. Inside it sit three economic sub-instruments — bank-account UPI (zero network MDR), wallet-on-UPI (1.1% above ₹2,000, nil at or below), and where applicable RuPay credit-on-UPI (~2% above ₹2,000, nil at or below) — each with its own reconciliation cell.

What does the Paytm PG settlement file actually contain?

Paytm PG’s merchant dashboard exposes a settlement section from which the merchant can export a settlement report for a date range. The publicly described field set for the file covers, for each settled transaction: the merchant’s order ID, Paytm’s internal transaction ID, the payment method, the gross amount, the MDR or platform fee deducted, the GST on the fee, and the net settlement amount. A settlement batch identifier ties a group of transactions to a single NEFT credit into the merchant’s bank account.

The disciplined reconciliation join is three-sided:

1. Order side — the merchant’s order management system or ERP, keyed on the order ID passed to Paytm at checkout time.
2. Settlement side — the Paytm PG settlement file, keyed on the Paytm transaction ID and the order ID.
3. Bank side — the merchant’s bank statement, where the NEFT credit narration carries a Paytm nodal-account reference and a UTR.

Where the gross-to-net bridge in the settlement file does not match the gross-to-net expected by the order-side rate model, the row is an MDR variance. Where the settlement batch total does not match the bank credit, the variance is either an unposted refund, a chargeback adjustment, or a timing artefact across the cutover. Both classes of variance accumulate quietly without a per-row check.

Real column header strings beyond the publicly described field categories above are not reliably documented in public sources for Paytm PG specifically; the disciplined approach is to take the column header row from the merchant’s own first exported settlement file and lock the parser schema to that, rather than to a published spec.

What rates apply per instrument on Paytm Payment Gateway?

The table below maps each instrument to the binding regulatory or NPCI rate (where one exists) and the Paytm-side published slab. For instruments where Paytm’s published slab is the relevant rate, the cell is filled; for instruments where a regulatory cap or NPCI interchange binds irrespective of which gateway is processing, that is shown explicitly.

The published ~1.99–2% standard slab and the 3% premium slab are the right baselines for a merchant on the published schedule. Custom rates are typically achievable at scale on higher-volume merchant accounts across the Indian market — and many crore-scale merchants are on negotiated enterprise pricing on cards — but those rates are a contract annex, never a published number, and must not be modelled into reconciliation without a written quote.

Where does Paytm hide the cost the blended slab does not show? A hotel chain worked example

A mid-size hotel chain processes ₹2.8 Cr monthly GMV through Paytm Payment Gateway. The method mix from the settlement file looks like:

• UPI (rail line): 35% of GMV = ₹98 lakh per month. Inside the rail line, the chain’s per-instrument tagging audit finds that 8% of the UPI volume is in fact wallet-on-UPI (predominantly Paytm wallet users tapping the wallet as the funding source on the UPI handle), 2% is RuPay credit-on-UPI, and 90% is genuine bank-account UPI.
• Credit card: 50% of GMV = ₹1.4 Cr per month. Inside, Visa and Mastercard standard credit cards dominate.
• Debit card: 12% of GMV = ₹33.6 lakh per month. Mix of Visa, Mastercard and RuPay.
• American Express: 3% of GMV = ₹8.4 lakh per month. A meaningful share for a hotel chain whose corporate-travel guests carry Amex cards.

Under the published slab structure the visible MDR cost is ~1.99–2% on standard volume and 3% on the Amex slice. The two lines the blended view misses are the wallet-on-UPI cell and the per-network isolation of Amex.

The audit calculations:

• Wallet-on-UPI line inside the “UPI” rail. The 8% wallet-on-UPI subset of the UPI rail line is ₹98 lakh × 8% = ₹7.84 lakh per month of wallet-on-UPI volume. At 1.1% NPCI interchange above ₹2,000 — which captures most hotel-room transactions, given typical room rates — the merchant cost on this slice is ₹7.84 lakh × 1.1% = ₹8,624 per month that the blended “UPI” view shows as zero or near-zero. Annualised, that is roughly ₹1.03 lakh of cost sitting inside the wrong reconciliation cell.
• RuPay credit-on-UPI line. The 2% RuPay credit-on-UPI subset is ₹98 lakh × 2% = ₹1.96 lakh per month at ~2% NPCI interchange above ₹2,000 = ₹3,920 per month of cost in the same “UPI” cell.
• Amex isolation. The 3% Amex slice at 3% MDR is ₹8.4 lakh × 3% = ₹25,200 per month. On a blended view, this gets folded into a single “credit card” or single “MDR” cost and the Amex-specific intensity (an order of magnitude per-rupee versus standard credit) is not visible. Even at a worked-example figure of ₹2.52 lakh of Amex volume on a smaller property — for instance, ₹2.52 lakh × 3% = ₹7,560 in one location — the per-network reconciliation lifts the Amex slice out of the blended view and into a line the corporate-rate negotiation team can actually point to.

The point is not that any of these rates is wrong or hidden by Paytm. The published slab is what it says it is. The point is that per-network and per-instrument reconciliation turns the blended fee bucket into individually addressable cells. The wallet-on-UPI ₹8,624 per month becomes either a method-mix steering decision (push customers to bank-account UPI through checkout UX) or a negotiation point with Paytm. The Amex ₹25,200 per month becomes either an enterprise-rate renegotiation conversation or a method-mix decision at the corporate-booking level. The blended view absorbs both into a single MDR number and the operational levers stay invisible.

How do GST, TDS and the chargeback dispute fee overlay Paytm PG settlements?

GST is straightforward and unchanged across the gateway market. Paytm charges 18% GST on the MDR/platform fee only (not on the transaction value). The GST appears as a separate line in the settlement file and rolls up to a monthly tax invoice issued to the merchant’s registered GSTIN. The merchant claims input tax credit on this amount in GSTR-3B once the corresponding entry appears in GSTR-2B. Folding GST into the MDR percentage in the reconciliation model — a common shortcut — breaks the GSTR-2B match and creates an ITC compliance risk under Rule 36(4).

TDS overlay is contextual. Where the merchant is an e-commerce participant selling through an e-commerce operator that is required to deduct, the deduction is at 0.1% under Section 393(1) Sl. 8(v), payment code 1035 of the Income-tax Act 2025 — the migrated successor to legacy Section 194O, which was at 1% from 1 October 2020 to 30 September 2024 and was reduced to 0.1% effective 1 October 2024. The deduction is by the operator, reconciles to the participant’s Form 26AS, and is distinct from Paytm PG’s MDR and from GST on MDR. Where the merchant is itself the operator paying participants, the deduction obligation runs the other way. Either way, the three lines — MDR, GST on MDR, TDS where applicable — must be kept separate in the reconciliation model.

The chargeback dispute fee is its own line. When a customer’s issuing bank initiates a chargeback against a disputed transaction, the card network imposes a dispute-adjudication fee on the merchant. On Paytm PG, as on every Indian aggregator, this dispute fee is recovered from the merchant’s nodal account through an adjustment posting that is visible in the merchant dashboard but does not appear inline against the original settlement row. If the bank-statement reconciliation does not parse the dispute-fee adjustment as a distinct event, it lands as an unexplained debit and gets absorbed into a fee variance — exactly the same disappearance mechanism that the wallet-on-UPI line uses, but at a different point in the cycle.

Combined with the broader industry rule that MDR is non-refundable on refunds — the original MDR billed on a successful transaction is not reversed when the transaction is refunded to the customer, so the merchant absorbs the MDR with no offset — the two together compound on any product line with material refund or chargeback activity. A subscription business or a hotel chain with cancellation flexibility carries this cost every cycle. The detection logic is covered in detail in MDR not reversed on refunds.

What does an automated reconciliation tool check for, specifically on Paytm PG?

The disciplined controls a reconciliation tool runs against Paytm PG settlements are six, ordered by how silently each one leaks:

1. “UPI” rail-line subdivision. Each row tagged “UPI” in the settlement file is subdivided into bank-account UPI, wallet-on-UPI and RuPay credit-on-UPI sub-instruments using the rail attributes available in the row. The wallet-on-UPI subset is tested against the NPCI 1.1% interchange above ₹2,000 / nil at or below ₹2,000 structure; the RuPay credit-on-UPI subset is tested against the ~2% above ₹2,000 / nil at or below structure; the bank-account UPI subset is verified at zero network MDR.
2. Per-network effective-rate report. Fees are divided by network volume for each network — UPI sub-instruments, Visa, Mastercard, RuPay, American Express, Diners, international — and reported against the published slab band for that network. Amex and Diners volume is lifted out of the blended view so the premium slab can be priced separately.
3. Standard-slab versus premium-slab reconciliation. Each row’s deducted fee is tested against the contracted slab for its instrument: ~1.99–2% standard or 3% premium. Rows outside the contracted band are flagged for review.
4. Chargeback dispute-fee tracker. Dispute-fee adjustments posted to the merchant’s nodal account are parsed at the bank-statement level, tied to the originating disputed transaction where possible, and posted to a dedicated dispute-fee ledger so they no longer absorb into a fee variance.
5. MDR-on-refund non-reversal tracker. The original MDR retained on each refunded transaction is tracked to a dedicated refund-MDR ledger so the finance team can see compounded MDR cost on a high-refund product line. See MDR not reversed on refunds for the full mechanics.
6. GST-on-fee separate-line tracker. The 18% GST on the MDR/platform fee is parsed as its own line at row level, rolled up to the monthly tax invoice, and matched against the corresponding entry in GSTR-2B for ITC claim integrity.

Two further pattern-level checks are inherited from the broader merchant-fees cluster controls: the Amex/Diners hidden in blended MDR check (per-network effective-rate computation against the blended quote) and the zero-MDR UPI / RuPay debit check (any non-zero network MDR flagged on a zero-MDR instrument). Both apply to Paytm PG settlements with the same logic they apply to Razorpay or PayU settlements.

How does Paytm PG sit alongside Razorpay, PhonePe and Cashfree in a multi-gateway stack?

Many merchants run more than one aggregator for redundancy or rate optimisation. Paytm PG’s reconciliation logic shares the settlement-file → bank-credit → ERP-order join structure with PhonePe Payment Gateway MDR reconciliation and Cashfree MDR reconciliation, and so the same three-sided reconciliation engine can ingest all three. What differs by gateway is:

• Published rate-card depth. Paytm publishes a two-slab structure (~1.99–2% standard, 3% premium) and offers custom rates for higher-volume merchants. Razorpay and PayU publish similar two-slab structures at ~2% standard / 3% premium with explicit per-instrument footnotes. Cashfree publishes a detailed per-instrument table at 1.95% standard with promo windows. PhonePe publishes only a single blended Standard Plan and routes everything else through a Business Dashboard quote.
• Wallet-on-UPI structural exposure. Paytm is itself a PPI issuer, so a merchant on Paytm PG with a customer base that uses the Paytm wallet has structural wallet-on-UPI exposure above ₹2,000 that the rail line will report as “UPI”. A merchant on a gateway that does not also issue a wallet has the same NPCI 1.1% interchange exposure on any wallet-on-UPI volume but typically less of it, because the brand-affinity routing is weaker.
• Premium-slab boundary. The 3% premium slab covering Amex, Diners, international and EMI is consistent across Paytm, Razorpay and PayU; Cashfree publishes finer EMI sub-rates (debit EMI 1.5%, cardless 1.9%, Pay Later 2.2%) but the Amex/Diners/international band is similar.

In a multi-gateway stack, the reconciliation tool must run a separate ingestion track per gateway (each settlement file has its own schema and its own bank-credit narration pattern) and roll up to a single per-merchant MDR waterfall that compares effective rate by gateway across the same method mix. That is the structure on which any honest method-mix or gateway-mix optimisation conversation depends.

Continue reading in this cluster

The Paytm wallet-on-UPI line hidden inside the “UPI” rail line is one of several silent MDR-leakage mechanics that compound on a fast-growing merchant’s settlement file:

• MDR charged on zero-MDR UPI and RuPay debit — the regulatory boundary that wallet-on-UPI sits exactly on top of.
• Amex/Diners hidden in blended MDR — why a single blended quote concentrates real cost in a non-isolated card mix.
• MDR not reversed on refunds — the compounding cost on a high-refund product line.
• Flat-rate MDR concealing network cost — the structural argument for per-network effective-rate reporting.
• PhonePe Payment Gateway MDR reconciliation and Cashfree MDR reconciliation — sibling per-gateway reconciliation guides.

For the gateway-agnostic end-to-end reconciliation pattern, see payment gateway reconciliation. For the broader software context, see reconciliation software India.

The interchange structure that drives both the wallet-on-UPI 1.1% line and the RuPay credit-on-UPI ~2% line is published by NPCI; the relevant circulars are listed on the NPCI UPI circulars page, including the 24 March 2023 interoperable-PPI interchange circular that introduced the 1.1% above ₹2,000 interchange on wallet-on-UPI merchant transactions.

Frequently asked questions about Paytm Payment Gateway MDR reconciliation are answered below.