Juspay Orchestration Fees: Why It's Not an MDR Layer (and How to Reconcile)

A direct-to-consumer OTT business processing ₹3 crore of monthly GMV across UPI, cards and net-banking adds Juspay in front of two underlying payment aggregators. The CFO sees three different invoices arrive each month — settlement statements from Razorpay and Cashfree, plus a separate Juspay invoice for per-transaction routing fees and AMC. The finance controller tries to reconcile them as a single payment-gateway cost line and the per-instrument effective-rate calculation falls apart. The error is structural: Juspay is not an MDR layer. It is a per-transaction SaaS fee that sits alongside, not inside, the underlying gateway’s MDR. This article unpacks how to reconcile Juspay fees correctly and where the real savings from orchestration actually originate.

Quick Reference

What Is Juspay and Why It Is Not an MDR Layer

Juspay is a payment orchestration platform headquartered in Bangalore. It provides an SDK and routing layer that sits between a merchant’s checkout and one or more underlying payment aggregators. When a customer initiates a payment, Juspay’s logic chooses which acquirer or rail to send the transaction to — for example, routing UPI to one PA and credit cards to another, retrying failed transactions on a fallback gateway, or splitting volume across two acquirers for redundancy.

What Juspay does not do is collect the actual money or hold the RBI payment aggregator licence. The money still flows through the underlying PA. The underlying PA still deducts its MDR. Juspay’s revenue model is a per-transaction SaaS fee — industry-reported in the ₹0.50 to ₹1.50 per transaction range — plus an enterprise annual maintenance contract. There is no published percentage MDR on Juspay’s pricing page; the rate card is custom and quote-only.

This distinction matters operationally. If a merchant treats Juspay’s invoice as an MDR replacement, the per-instrument effective-rate calculation breaks. If a merchant nets the Juspay fee against the underlying gateway’s MDR in a single ledger line, the effective rate becomes uninterpretable and the controller cannot tell whether the gateway is overcharging on a per-instrument basis or whether the orchestration fee is justified by the routing savings.

The correct mental model is two parallel costs on the same transaction: the underlying gateway’s percentage MDR plus GST on that MDR, and Juspay’s fixed per-transaction routing fee plus GST on that routing fee. Both must be booked, reconciled and analysed separately.

What Does Juspay’s Invoice Actually Contain?

Juspay does not publish a public rate card. Industry references and merchant reports describe the structure as follows. None of these are corroborated by an official Juspay pricing document, which states pricing is custom and quote-only.

Typical invoice line items reported by enterprise merchants:

• A per-transaction routing fee, applied to all attempted transactions or all successful transactions (the basis is contract-specific). Reported range is approximately ₹0.50 to ₹1.50 per transaction at enterprise scale.
• An annual maintenance contract, billed monthly or quarterly. Quantum is enterprise-specific.
• GST at 18% on the routing fee plus AMC. This is the GST on the SaaS service, separate from the GST on MDR billed by the underlying gateway.
• Optional add-ons for specific orchestration features — fraud-routing decisions, retry-on-failure logic, custom acquirer integrations — typically rolled into the AMC rather than per-transaction.

Crucially, the invoice does not contain a percentage MDR row. There is no “MDR on UPI”, “MDR on Visa/Mastercard credit”, “MDR on Amex” line. Those rows live entirely on the underlying gateway’s settlement file.

A reconciliation pipeline that ingests the Juspay invoice as if it were a settlement file will fail; it has neither settlement IDs nor per-instrument MDR rows. It is a SaaS invoice with a transaction-count basis, and must be reconciled by matching the invoiced transaction count against the routing log and the sum of successful payments across all underlying gateways for the same period.

Where Does Each Underlying Gateway’s MDR Still Show Up?

The underlying gateway’s MDR shows up exactly where it always has — in that gateway’s settlement file. If Juspay routed a credit card transaction to Razorpay, Razorpay’s settlement file deducts Razorpay’s published 2% MDR plus 18% GST on MDR, and credits the net to the merchant’s nodal account. If Juspay routed a UPI transaction to Cashfree under the current 1.6% promo (subject to the UPI ≥ 40% mix condition) or the 1.95% standard rate, Cashfree’s settlement file deducts that platform fee and credits the net. Juspay does not appear in either gateway’s settlement file at all.

Per-instrument MDR for the gateways Juspay typically routes to (published rates only; enterprise-negotiated rates are not the published number):

These are published rates as of June 2026. Enterprise-negotiated rates at ₹1 crore plus monthly volume typically achieve 1.4 to 1.6 percent on cards. Negotiated rates should never be stated as if quoted publicly — they are contractually individual. Always reconcile against the merchant’s own contracted rate, not the headline published rate.

For the regulated zero-MDR rails — bank-account UPI P2M and RuPay debit — the network MDR is mandated zero by NPCI and RBI, but each gateway still charges a platform fee that may be displayed under a UPI label. Keep “network MDR” and “gateway platform fee” as distinct columns; conflating them is one of the most common audit findings in payment-gateway reconciliation.

How Do You Reconcile Juspay’s Invoice Against the Routing Log?

The reconciliation is count-based, not amount-based. Juspay’s per-transaction fee is invoiced against a transaction count for the billing period. The merchant’s controller verifies that count against the routing log — Juspay’s own transaction-attempt records — and against the sum of successful transactions in each underlying gateway’s settlement file.

The reconciliation joins are:

1. Juspay invoice transaction count for the period → routing-log transaction count for the same period. These should match exactly. A gap means Juspay billed for routing decisions that the merchant’s own log does not corroborate, or vice versa.
2. Routing-log transaction count, decomposed by destination gateway → sum of successful transactions on that gateway’s settlement file for the same period. Each gateway’s count must reconcile separately. A gap means transactions Juspay routed to a gateway never appeared in that gateway’s settlement — either failed without retry, were dropped, or were settled in a different period.
3. Juspay invoice fee per transaction × transaction count → invoice line total before GST. Verify the per-transaction rate matches the contract.
4. GST at 18% on the Juspay fee plus AMC → ITC-eligible input GST. This is booked separately from the GST on MDR billed by each underlying gateway, even though both end up in the same monthly GSTR-2B reconciliation.

A reconciliation tool configured for this workflow ingests the Juspay invoice, the Juspay routing log and each underlying gateway’s settlement file as separate inputs and joins them on payment ID and date. The output is a per-period exception ledger that flags any of: Juspay-billed transactions missing from the routing log, routing-log transactions missing from the destination gateway’s settlement, gateway settlements with no upstream routing decision, and per-transaction fee variances against contract.

What Does a Worked Example Look Like?

A D2C OTT business — ₹2,499 annual subscription with monthly and quarterly tiers — processes ₹3 crore of monthly GMV across approximately 60,000 transactions. The mix is roughly 50 percent UPI, 35 percent cards (mostly domestic Visa and Mastercard credit), and 15 percent net-banking and other.

Single-gateway baseline (Razorpay, blended 2 percent):

• GMV: ₹3,00,00,000
• Blended MDR: 2.00% × ₹3,00,00,000 = ₹6,00,000
• GST on MDR (18%): ₹1,08,000
• Total payment cost: ₹7,08,000 per month

Juspay-orchestrated multi-gateway baseline (Razorpay + Cashfree):

The merchant negotiates an enterprise card rate with Razorpay at 1.80 percent for the card share and routes UPI through Cashfree on the 1.60 percent promotional rate (conditional on UPI ≥ 40 percent of monthly GTV; the OTT mix meets this). Net banking stays on Razorpay at its standard rate.

• Cards via Razorpay at 1.80%: 35% × ₹3,00,00,000 = ₹1,05,00,000 × 1.80% = ₹1,89,000
• UPI via Cashfree at 1.60%: 50% × ₹3,00,00,000 = ₹1,50,00,000 × 1.60% = ₹2,40,000
• Net-banking via Razorpay at approximately 1.80%: 15% × ₹3,00,00,000 = ₹45,00,000 × 1.80% = ₹81,000
• Subtotal gateway MDR: ₹4,95,000 (effective 1.65% of GMV)
• GST on gateway MDR (18%): ₹89,100

Juspay routing fee:

• 60,000 transactions × ₹0.80 per transaction (illustrative; contract-specific) = ₹48,000
• GST on routing fee (18%): ₹8,640

Combined Juspay-orchestrated cost:

• Total payment cost (excluding GST): ₹4,95,000 + ₹48,000 = ₹5,43,000
• Total GST on fees: ₹89,100 + ₹8,640 = ₹97,740 (fully ITC-eligible for GST-registered merchant)
• Net saving versus single-gateway baseline (excluding GST, which is recovered as ITC): ₹6,00,000 − ₹5,43,000 = ₹57,000 per month

The ₹57,000 monthly saving is what the CFO sees on the bottom line. But the saving is not because Juspay is cheaper. Juspay added ₹48,000 of monthly cost. The saving comes from routing — specifically, two routing decisions: cards moved to a negotiated 1.80 percent on Razorpay (an enterprise rate negotiation), and UPI moved to a 1.60 percent promotional rate on Cashfree (a rail selection). The orchestration fee is a cost layer that buys the flexibility to make those routing decisions; it is not the saving itself.

If the merchant reconciles all three invoices into one blended payment-gateway expense line, the controller can tell management “we saved ₹57,000 by switching to Juspay” — which is true but misleading. The true attribution is: ₹60,000 of negotiation saving on cards, ₹60,000 of mix saving on UPI, partially offset by ₹48,000 of orchestration cost, net ₹57,000. Each lever is independently controllable in next quarter’s planning. A blended line hides that.

Where Does Juspay’s Fee Get Misclassified in a Typical Ledger?

Three common misclassifications, in descending order of frequency observed in finance-team audits:

Folded into MDR percentage. The controller computes a “blended Juspay MDR” by dividing Juspay’s monthly invoice plus all underlying gateway MDR by total GMV and reporting that as a single percentage. This produces an effective-rate number that is mathematically correct as a total cost but operationally meaningless. The number cannot be used to negotiate with any specific gateway, cannot be compared against any other gateway’s published rate, and cannot detect per-instrument leakage on individual rails. The fix is to separate the lines.

Treated as MDR savings. Management sees that the merchant moved from a 2.00 percent blended cost to a 1.81 percent total cost (the worked example above) and credits Juspay with “0.19 percentage points of MDR reduction”. Juspay did not reduce MDR. The merchant negotiated card rates and switched UPI rail; the orchestration fee added cost. The attribution is incorrect and breaks the conversation about whether to renew the orchestration contract or take the routing logic in-house.

Booked against the wrong cost centre. Gateway MDR is typically expensed against the revenue-recognition cost centre (payment-processing cost of revenue). Juspay’s SaaS fee is sometimes booked there too, sometimes booked under technology / software-as-a-service. The classification choice has audit implications (cost-of-revenue treatment versus operating expense) and ITC implications. The choice should be deliberate and documented in the chart-of-accounts mapping, not defaulted by whoever processes the invoice.

How Does Automated Reconciliation Handle Juspay Specifically?

A reconciliation pipeline configured for a Juspay-orchestrated stack runs five parallel ingestion streams and one reconciliation join.

The five ingestion streams:

1. Razorpay settlement file — keyed on settlement_id, joined to bank UTR on settlement date and net amount, exploded to per-payment_id rows with MDR, GST on MDR and refund deductions.
2. Cashfree settlement file — keyed on Cashfree settlement reference, joined to bank credit, exploded similarly.
3. Any other underlying gateway settlement file — same pattern.
4. Juspay routing log — per-payment-attempt record with destination gateway, success/failure flag and timestamp.
5. Juspay invoice — per-period transaction count, fee per transaction, AMC line, GST line.

The reconciliation join links each payment_id from the routing log to the corresponding row in the destination gateway’s settlement file. Exceptions flagged include:

• Routing-log payment_id absent from destination gateway’s settlement (failed at gateway, dropped before settlement, or settled in a different period).
• Gateway settlement row with no routing-log entry (direct gateway integration bypass, or a routing-log gap).
• Juspay invoice transaction count exceeding the sum of routing-log entries for the period.
• Juspay invoice transaction count under the sum of routing-log entries (under-billing — rare but possible).
• Per-instrument MDR variance against contracted rate on each gateway settlement.
• GST on MDR variance, GST on Juspay fee variance.

The output is a per-period management dashboard showing total payment cost decomposed into gateway-level MDR by instrument, GST on MDR, Juspay routing fee, AMC, and GST on the orchestration line. Each line is independently auditable and the per-instrument leakage view is preserved.

How Does Juspay Routing Interact With Other Per-Gateway Leakage Patterns?

The leakage patterns documented elsewhere in this cluster do not go away under Juspay; they redistribute. A few examples:

• A flat-rate MDR concealing per-network cost differences becomes a Juspay-blended-rate problem if the controller folds Juspay fees into the gateway percentage. The remedy is the same — separate the lines and compute per-network effective rate.
• MDR not reversed on refunds applies to every underlying gateway Juspay routes to. The MDR retention happens at the PA level; Juspay’s per-transaction fee is also typically non-refundable, so a refunded transaction now retains two layers of fee, not one.
• Amex and Diners hidden in a blended MDR is unchanged at the gateway level. If Juspay routes Amex to a gateway charging 3 percent on Amex, that 3 percent still applies; orchestration does not lower it.
• Premium-card BIN audit is more important under orchestration, not less. With multi-gateway routing, the BIN-tier discipline must apply per-gateway, and discrepancies in how each PA classifies premium tiers can produce per-gateway leakage that a single-gateway view would not surface.

The orchestration layer is a routing decision-maker; the underlying economics of each rail are unchanged. Reconciliation discipline that ignored leakage on a single-gateway stack will ignore leakage on a Juspay-orchestrated stack — and the multi-gateway surface area gives leakage more places to hide.

How Does TDS and GST Overlay Affect This?

GST law applies unchanged. The 18 percent GST is charged on the MDR/platform fee only — not on the transaction value — and applies twice: once on the underlying gateway’s MDR (billed by the gateway, claimed as ITC against the gateway’s GSTIN) and once on Juspay’s routing fee and AMC (billed by Juspay, claimed as ITC against Juspay’s GSTIN). Both ITC claims reconcile through GSTR-2B against the respective vendor invoices.

For e-commerce TDS, the relevant Income-tax Act 2025 reference for an e-commerce operator deducting on payments to participants is Section 393(1) Sl. 8(v), payment code 1035, at 0.1 percent (this replaced the legacy 194O regime; the rate moved from 1 percent to 0.1 percent effective 1 October 2024 and is unchanged under the 2025 Act recoding). This TDS, where applicable, is a separate line from gateway MDR and from Juspay’s routing fee; reconcile each against Form 26AS independently. None of these three layers may be folded into another.

How Does Juspay’s Pricing Differ From a Direct PA Relationship?

In a direct PA relationship, the merchant has one settlement file, one MDR rate card (per instrument), one GST on MDR line. The economics are visible per transaction.

Under Juspay orchestration, the merchant has N settlement files (one per underlying PA Juspay routes to), N MDR rate cards, N GST on MDR lines, plus Juspay’s separate invoice for routing fee, AMC and GST on the orchestration service. The total cost is split across more invoices and more vendors. The trade-off is routing flexibility (the ability to pick the cheapest viable rail per transaction) and resilience (fallback gateways on PA outage).

For a merchant whose volume justifies two or more PA relationships and whose method mix has material rail-by-rail cost differences (UPI versus international cards versus Amex, for example), the orchestration layer pays for itself through routing savings. For a merchant on a single gateway with no method-mix lever, Juspay is an added cost layer with no routing surface to recover it.

The decision is a business one. The reconciliation discipline is the same in either case: keep MDR, platform fee, GST on MDR, orchestration fee, AMC and GST on orchestration as separate lines. Never blend them into a single percentage.

Continue Reading in This Cluster

• Razorpay settlement reconciliation — per-gateway settlement file structure for the most common underlying PA under Juspay
• Cashfree settlement reconciliation — Cashfree’s settlement structure, now also routable on the Juspay network
• PayU settlement reconciliation — PayU per-gateway settlement file structure
• Flat-rate MDR concealing per-network cost differences — why a single blended rate hides per-rail leakage
• Amex and Diners hidden in a blended MDR — premium-card cost concealed inside a flat rate
• MDR not reversed on refunds — refund leakage applies under orchestration too
• Platform-fee leakage on Razorpay and PayU — distinguishing platform fee from network MDR
• Cluster hub: Merchant fees and MDR leakage
• Money page: Payment gateway reconciliation

External authority: Juspay’s own pricing page describes the orchestration positioning and the quote-only nature of its commercial terms — juspay.io/in/pricing.