PhonePe Payment Gateway MDR Reconciliation: The "Free" Promo and the Standard Plan

PhonePe Payment Gateway is the only major Indian payment aggregator that, as of June 2026, has no published per-instrument rate card. Everything beyond a single blended Standard Plan headline — 1.95%, currently struck-through and shown as “Free*” under a limited-time launch offer — runs through a Business Dashboard quote. For a CFO closing books or a controller signing off the monthly MDR accrual, that absence is operationally meaningful: there is no public slab table to verify the settlement file against, and there is no public document defining the day the promo ends. This article describes how to reconcile PhonePe PG settlements in that environment, what the two distinct PhonePe rails look like in the GL, and where the reconciliation discipline must do the work that the rate card does not.

Quick-Reference

What does “Free*” on PhonePe’s pricing page actually mean?

The PhonePe Payment Gateway pricing page presents two cards side by side: a Standard Plan and an Enterprise Plan. The Standard Plan headline number — 1.95% — appears struck through, replaced visually by the word “Free” followed by an asterisk. The asterisk leads to a footnote describing the offer as time-bound. Below the headline, the page lists “zero setup”, “zero AMC” and “no hidden charges”, and routes everything else — per-instrument rates, premium card slabs, international card pricing, EMI — to a single instruction: log in to the Business Dashboard for a quote. The Enterprise Plan card is marked “custom”.

For a finance team, the operational read is that PhonePe publishes exactly two facts: a blended Standard Plan rate (1.95%) and a current promotional override (“Free*”, limited-time). Every other number lives behind the dashboard. That makes the merchant’s signed pricing schedule — the document the merchant accepts during onboarding and stores against the contract — the only reconciliation reference. A reconciliation tool cannot verify a settlement line against a public rate card because there is none.

Two consequences follow. First, the contracted revert-to-standard rate — what the merchant pays the day the promo ends — must be in writing in the signed schedule. If it is silent or open-ended, the merchant has accepted unpriced rate risk. Second, the working per-instrument slab table — the slab actually applied to a credit card, a debit card, a UPI bank-account transaction, a wallet, a net banking transaction, an international card, an EMI — should be requested from PhonePe through the Business Dashboard quote and saved as a contract annex. Without it, the settlement file is unauditable: there is no published reference to compare each row against.

How does PhonePe PG’s settlement file work, and what columns does it expose?

PhonePe PG’s merchant dashboard provides a settlement section from which the merchant can export a settlement report for a date range. The file is keyed on PhonePe’s internal transaction identifier and includes, for each settled transaction: the merchant’s order reference, the gross amount, the deducted fee (MDR or platform fee depending on contract wording), the GST on the fee, and the net settlement amount. The dashboard also exposes a settlement batch identifier that ties a group of transactions to a single NEFT credit into the merchant’s bank account.

The disciplined reconciliation join is therefore three-sided:

1. Order side — the merchant’s order management system or ERP, keyed on the order reference passed to PhonePe at checkout time.
2. Settlement side — the PhonePe PG settlement file, keyed on the PhonePe transaction identifier and the order reference.
3. Bank side — the merchant’s bank statement, where the NEFT credit narration carries a PhonePe 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, or a timing artefact. Both classes of variance accumulate quietly without a per-row check.

Real column names beyond the public categories above are not reliably documented in public sources for PhonePe PG specifically; the disciplined approach is to take the column header row from your own first exported settlement file and lock the parser schema to that, rather than to a published spec.

Where is the PhonePe consumer app the wrong place to look in PG reconciliation?

PhonePe is two products under one brand and they must be kept separate in the ledger.

The PhonePe consumer UPI app is, in the merchant context, a way for the customer to pay the merchant directly using the merchant’s UPI ID or QR code. The funds move on the NPCI UPI rail from the customer’s bank account to the merchant’s bank account, with zero network MDR for the bank-account UPI P2M case (the Section 269SU/PSS Act zero-MDR regime applies regardless of which UPI app initiates the payment). For the merchant, the inflow looks like any other UPI direct credit: a UPI line in the bank statement, no PhonePe PG settlement file, no MDR deduction, no GST on MDR.

The PhonePe Payment Gateway is an aggregator product. The customer interacts with the PhonePe PG checkout, choosing a card, a UPI handle, a wallet or net banking; PhonePe collects, deducts the contracted fee, and settles a net amount via NEFT after the settlement cycle. The merchant sees a PhonePe PG settlement file, a deducted fee, a GST line, and a periodic NEFT credit — exactly the structure of any other aggregator.

If both rails are active for the same merchant, the GL treatment must isolate them. Direct-collect PhonePe UPI inflows go to a UPI collections ledger code at gross value with zero MDR. PhonePe PG net settlements go to a payment-gateway settlements ledger code at gross-minus-MDR, with the MDR and GST-on-MDR posted as expenses and recoverable input tax credit respectively. Mixing the two — for example, posting a direct-collect UPI receipt against the PhonePe PG settlement ledger because the customer-facing brand was the same — produces a persistent unexplained variance every cycle.

What rates should you assume for each instrument under the Standard Plan?

PhonePe does not officially publish per-instrument percentages. The only PhonePe-side numbers that can be cited confidently are the blended 1.95% Standard Plan and the wallet/PPI-on-UPI 1.1% NPCI interchange above ₹2,000. Everything else is contract-side, recovered from the Business Dashboard quote.

The table below shows the category structure a finance team should request from the Business Dashboard quote, alongside the regulatory or NPCI rates that bind irrespective of which gateway is processing. The PhonePe-specific column is left as “Business Dashboard quote required” wherever PhonePe does not publish the rate — this is the honest reconciliation posture.

The published 1.95% Standard Plan is a blended rate. Under the “Free*” promo it is overridden by zero for the duration of the promotional window. Once the promo lapses, every cell in the table above resolves to either the regulatory rate (where one binds) or the per-instrument slab from the Business Dashboard quote (where one exists in the merchant’s signed schedule). The reconciliation tool needs both layers to verify a settlement line.

Negotiated enterprise rates — the kind a crore-scale merchant might secure on cards across the broader Indian gateway market — are typically achievable at scale but are not the published rate. They should never be stated as if quoted; they enter the reconciliation model only as a documented contract annex.

What does a “Free* promo” lapse look like in numbers? A D2C worked example

A D2C nutraceutical brand processes ₹1.2 Cr monthly GMV through PhonePe PG. The “Free*” launch promo currently applies, so the headline MDR billed in the settlement file is zero. The brand’s finance team treats this as the working unit-economic baseline and builds the monthly MDR accrual at zero.

The reconciliation audit confirms two things in writing with PhonePe via the Business Dashboard:

1. The promo end date — the specific calendar date on which the “Free*” override is contracted to lapse.
2. The revert-to-standard trigger — the rate the merchant pays from that date forward, and whether the Standard Plan 1.95% applies as the floor or whether a negotiated revert slab has been agreed.

The risk being audited is straightforward. On the day the promo lapses, if no renegotiation has been documented, the rate reverts to the Standard Plan 1.95%. At ₹1.2 Cr monthly GMV that is:

• ₹1.2 Cr × 1.95% = ₹2,34,000 per month of additional MDR cost, appearing in the first settlement file after the promo end date with no advance posting in the management accounts.
• ₹2,34,000 × 18% GST = ₹42,120 per month of additional GST on MDR, recoverable as ITC only against the matched monthly invoice in GSTR-2B.
• An annualised cost step of approximately ₹28 lakh absorbed into operating expenses without renegotiation.

The cost of not doing the work is the same ₹2.34 lakh per month, billed silently. Establishing settlement-file reconciliation discipline early — three-rate verification (promo rate in effect, Standard Plan 1.95% revert baseline, per-instrument slab from the Business Dashboard quote) and a promo-end-date alert — protects against this in the only way that survives the promo lapse: the finance team sees the rate jump in the first settlement file and can either accept it, renegotiate it, or rebalance method mix the same week.

For comparative context — and only as comparative context, not as a recommendation of one gateway over another — Razorpay and PayU publish blended Standard Plan rates of approximately 2.00% for domestic transactions, and Cashfree publishes 1.95% (with a separate 10-year-anniversary promo at 1.6% for new merchants signing up between 18 September 2025 and 30 April 2026, locked for 12 months up to ₹1 Cr/month GTV and requiring UPI ≥ 40% of monthly GTV). At a typical enterprise-negotiated 1.5% (which the broader Indian market suggests is achievable at the ₹1.2 Cr monthly GMV the brand processes, but is not a PhonePe-published rate and must not be assumed without a written quote), the monthly MDR would be ₹1.8 lakh — versus ₹2.34 lakh at the PhonePe Standard Plan 1.95%. The point is not which gateway is cheaper; it is that the reconciliation discipline that protects the brand against an unrenegotiated PhonePe promo lapse is the same discipline that lets the brand benchmark and renegotiate across any aggregator.

How does GST and TDS overlay PhonePe PG settlements?

GST is straightforward and unchanged across the gateway market. PhonePe 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 GST-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 PhonePe 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. Folding them into a single “fees” bucket is a recurring source of variance.

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

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

1. Promo-end-date alert. The signed pricing schedule’s promo end date is loaded as a hard date; the tool raises a warning 30, 14 and 1 day(s) before, and flags the first settlement file after the date for forensic comparison against the contracted revert rate.
2. Three-rate row verification. Each settlement row is tested against three reference rates — the promo rate currently in effect, the Standard Plan 1.95% revert baseline, and the per-instrument slab supplied by the Business Dashboard quote. Any row that diverges from all three by more than a configurable tolerance is flagged for review.
3. Dual-rail isolation. Direct-collect PhonePe UPI inflows (no PhonePe PG settlement file, zero network MDR) are tagged at the bank-statement parse stage and routed to a separate UPI collections ledger. PhonePe PG net settlements are routed to the payment-gateway settlements ledger. The two never mix.
4. Wallet/PPI-on-UPI 1.1% above-₹2,000 rule. Any wallet/PPI line in the settlement file is tested against the NPCI 1.1% interchange above ₹2,000 / nil at or below ₹2,000 structure. A line outside that band is flagged.
5. MDR-on-refund non-reversal check. MDR is non-refundable industry-wide; the tool tracks the original MDR retained on each refunded transaction so the finance team can see compounded MDR cost on a high-refund product line. (See the related leakage pattern in MDR not reversed on refunds for the full mechanics.)

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, to isolate Amex/Diners volume from a flat blended slab) and the zero-MDR UPI / RuPay debit check (any non-zero network MDR flagged on a zero-MDR instrument). Both apply to PhonePe PG settlements with the same logic they apply to Razorpay or PayU settlements.

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

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

• Settlement cadence. Cashfree publishes T+1 as standard for eligible merchants; Razorpay and PayU default closer to T+2 with T+1 negotiated. PhonePe PG’s settlement cadence sits in the signed schedule.
• Per-instrument visibility. Razorpay and PayU publish per-instrument footnotes (premium cards, Amex/Diners, international cards at ~3%); Cashfree publishes a detailed per-instrument table with a 10-yr-anniversary promo set; PhonePe publishes only the blended Standard Plan and the “Free*” promo, with everything else behind the Business Dashboard quote.
• Promo structure. Cashfree’s promo is rules-bound (UPI ≥ 40% of GTV, ≤ ₹1 Cr/month, 12-month lock, ends 30 April 2026 for new sign-ups); PhonePe’s “Free*” promo is positioned as time-bound without the same publicly stated mix gates.

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. That is the structure on which any honest method-mix or gateway-mix optimisation conversation depends.

Continue reading in this cluster

The PhonePe PG promo lapse 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 often gets crossed in flat-rate billing.
• 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.
• Razorpay settlement reconciliation and Cashfree settlement 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.

PhonePe’s published pricing is documented on the PhonePe Payment Gateway pricing page, which shows the Standard Plan headline of 1.95% currently struck-through under the limited-time “Free*” launch offer and flags the Enterprise tier as custom-quote.

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