Skip to main content
How-To · 10 min read

Commercial / Corporate Card MDR: The Hidden 3% Premium Slab

Commercial cards (corporate Visa, Visa Business, Mastercard World Business, Mastercard Corporate, plus the small RuPay Corporate footprint) are a structurally premium-slab instrument across every gateway rate card published in India. Razorpay, PayU, and Cashfree all bill them at 3% — the same rate they apply to Amex and Diners — because the underlying network interchange is genuinely higher. The leakage hot-cell is the consumer-card-as-commercial mis-classification, where the gateway's BIN classifier auto-routes a standard consumer credit transaction into the 3% bucket. A B2B SaaS merchant with ₹1.5 crore monthly card GMV at an 85% commercial / 15% consumer mix recovers ₹22,500 per month — ₹2.7 lakh annually — once the BIN-tier check separates the two cleanly.

Terra Insight
Terra Insight Reconciliation Infrastructure

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

Published 23 June 2026
Domain expertise
TDS Reconciliation GST Input Credit Platform Settlements NACH Batch Matching Bank Reconciliation Form 26AS Matching ERP Integrations Enterprise Finance Ops
Knowledge Card
Problem

Commercial and corporate Visa and Mastercard products carry a higher network interchange than consumer credit, and gateways route them to a 3% premium slab in every published rate card. The audit problem is that the gateway's BIN classifier silently auto-routes any BIN it tags as commercial into the 3% bucket, and the merchant settlement file rarely exposes the BIN or the tier evidence per transaction. Consumer volume routed to the commercial bucket leaks at 100 basis points per affected transaction; commercial volume routed to the consumer bucket creates a delayed retroactive fee true-up that is impossible to contest without the BIN-tier reconciliation.

How It's Resolved

Per-transaction BIN-tier reconciliation joins each settlement-file row to an acquirer-provided BIN-tier schedule mapping the first six digits of the card number to one of consumer credit, commercial, corporate, premium signature, premium infinite, rewards, debit, or prepaid. The merchant's contracted slab is keyed on network plus tier and read into an expected-fee column. Actual fee is the gateway-deducted MDR. Variance equals actual minus expected with a 5 basis-point tolerance to suppress rounding. Per-network per-tier effective-rate matrix surfaces both over-charge (consumer-as-commercial) and under-charge (commercial-as-consumer) drifts on the same monthly dashboard.

Configuration

Acquirer BIN-tier reference table refreshed quarterly. Contracted rate card object keyed on network and product tier per gateway. CARD_TIER_VARIANCE rule with directional flag (over-charge versus under-charge) and 5 basis-point slab-delta tolerance. Retroactive fee true-up detector that joins later-cycle adjustments back to originating BIN classification. GST credit-note matcher to GSTR-2B for the 18% reversal line on any recovered MDR. 90-day rolling dispute window aligned to gateway retrospective-adjustment cut-offs.

Output

A per-gateway per-network per-tier effective-rate matrix updated monthly. A bidirectional variance log separating consumer-billed-as-commercial leakage from commercial-billed-as-consumer pending true-up exposure. A dispute pack export per BIN with transaction-ID-level evidence and the contracted-slab versus actual-slab calculation. A GST credit-note reconciliation schedule against GSTR-2B. A recoverable-amount running total fed into the broader merchant-fee leakage register.

A B2B SaaS controller closes the month-end settlement reconciliation and reads a single line on the gateway statement: total credit card MDR ₹4.5 lakh on ₹1.5 crore of card GMV — a flat 3% effective rate. The contracted rate card says standard consumer credit is 2% and commercial cards are 3%. The card mix on the customer base is heavily commercial — enterprise buyers paying for seats on corporate Visa Business and Mastercard Corporate plastic — and the controller’s mental model is that 3% across the board roughly matches the mix. Sign off, file the workpaper, move on.

The customer base is not 100% commercial. About 15% of the monthly volume comes in on consumer credit — founders expensing the subscription on a personal card, one-person buyers paying out of pocket and reclaiming. That 15% is being billed at 3% when the contracted consumer slab is 2%. The annualised leakage runs to ₹2.7 lakh, and the only reason it is invisible is that the gateway settlement file does not expose the BIN or the per-transaction card tier. This is the structural pattern that defines the commercial / corporate card MDR audit.

Quick reference: commercial card MDR in the Indian gateway landscape

AspectDetail
InstrumentCredit card — commercial / corporate / business product tier
Networks in scopeVisa Business, Visa Corporate; Mastercard World Business, Mastercard Corporate; RuPay Corporate (small footprint); Amex and Diners corporate ranges (already at 3%)
Regulatory capNone — credit card MDR is uncapped and contractually negotiated (RBI 2017 circular caps non-RuPay debit only)
Razorpay published slab3% plus GST on commercial cards (pricing-page footnote)
PayU published slab3% plus GST on commercial cards (pricing FAQ)
Cashfree published slabBucketed with premium and Amex / Diners at the 3% tier
Consumer credit slab (Visa / Mastercard) for contrast1.4% to 2.5% domestic, gateways list around 2%; enterprise-negotiated 1.4% to 1.6% above ₹1 crore monthly GMV
Tier carrierBIN — first six to eight digits of the card number, mapped against the acquirer BIN-tier schedule
GST on MDR18% on the fee only, separate line — never folded into the MDR percentage
Retrospective dispute windowTypically 90 days, gateway-dependent
Variance classCARD_TIER_VARIANCE — directional (over-charge / under-charge) per BIN per cycle

The commercial slab is not a hidden rate. It is published on every gateway’s pricing page. The audit problem is not that 3% exists — it is that the classifier decides which transactions belong there, without showing the merchant the BIN evidence.

What does the network interchange actually say about commercial cards?

Card-network interchange — the fee the acquiring bank pays the issuing bank on each transaction — is published by Visa and Mastercard as a schedule by product. The schedule has a small number of axes: card type (debit, credit, prepaid), product tier (standard, world, world elite, business, corporate, government), scope (domestic or international), MCC category (the merchant’s industry classification), and transaction type (card-present, card-not-present, recurring, refund). Commercial and corporate products consistently sit at a materially higher interchange than standard consumer credit because the issuer carries higher revolving-credit risk on a corporate balance sheet, ticket sizes are larger, and the network levies a commercial product fee.

Indian gateways do not negotiate the interchange — they pay it on behalf of the merchant and pass it through with a margin. The published gateway rate card converts the interchange schedule into a small number of slabs (typically four to six) that the merchant can read on a single page: standard consumer credit, premium / signature / infinite, commercial / corporate, Amex / Diners, international, EMI. The 3% slab is the published cost basis on commercial cards across Razorpay, PayU, and Cashfree because the underlying interchange supports it. The flat 3% across all premium and commercial categories is a simplification — Amex and Diners sit at a 2.95% to 3.5% cost basis while domestic commercial Visa and Mastercard sit at a 2.5% to 3% cost basis — and the simplification works in the gateway’s favour by an average of 25 to 50 basis points.

The merchant’s contract picks one of two postures. The simple posture is to accept the 3% slab on the commercial side as published and on the Amex / Diners side as published, with the consumer slab carved out separately. The negotiated posture, available at meaningful monthly GMV (typically above ₹1 crore), unbundles the commercial slab from the Amex / Diners slab and negotiates each separately — and unbundles the consumer slab from the premium slab inside the consumer-card category so a Visa Infinite or Mastercard World Elite rewards card does not get auto-routed to 3% on the strength of its product code alone.

How does the BIN classifier auto-route to the 3% slab?

The mechanics are simple, deterministic, and opaque to the merchant. A card transaction arrives at the gateway. The gateway captures the full PAN, extracts the first six digits, and looks the BIN up against an internal mapping. The mapping is itself sourced from the acquirer (which sources it from the network) and updated on a periodic basis — quarterly is typical, monthly is best practice. The mapping returns a product attribute: standard consumer credit, premium signature, premium infinite, rewards co-branded, commercial, corporate, business, debit, prepaid, or unknown.

The gateway’s billing engine then reads the merchant’s contracted rate card and matches the product attribute to a slab. Standard consumer credit maps to the consumer slab (usually around 2% or the negotiated enterprise rate). Premium / signature / infinite maps to the premium slab (3% in most rate cards). Commercial / corporate / business maps to the commercial slab (also 3% in most rate cards). Amex and Diners are routed via their own network channel and pinned at the 3% slab regardless of product tier. International transactions are flagged on the BIN’s issuer-country attribute and routed to the international slab.

The merchant’s view of this process is a single fee line on the settlement file. Unless the merchant has negotiated a settlement export that surfaces the BIN and the gateway’s classification, the routing decision is invisible. Razorpay surfaces a card subtype attribute on its settlement file (card.iin and a tier label in the order-payment object), PayU exposes a card category on the settlement webhook, and Cashfree exposes a card-type-detail attribute on its order-payments API. Each of these is a useful cross-check but not the audit reference — the acquirer’s BIN-tier schedule is the operative truth, and the gateway’s classification can drift from it when the acquirer mapping has been refreshed but the gateway mapping has not.

Detection: a per-BIN per-tier audit workflow

The detection workflow has six steps that a controller can run with the gateway settlement export, the acquirer-provided BIN-tier CSV, and a spreadsheet or reconciliation engine.

  1. Pull the settlement file with per-transaction BIN. Most Indian gateways will provide BIN on written request even when the default settlement export truncates the card number. The BIN is the first six digits of the PAN — it does not identify a cardholder and is not card-data-vault scope.
  2. Source the BIN-tier reference from the acquirer. HDFC Acquiring, Axis Acquiring, ICICI Acquiring, RBL Bank, and Worldline (the major Indian acquirers) all provide BIN-tier mappings to their merchants on request. The mapping is keyed on the first six digits and returns network, issuer, product tier, and scope (domestic / international).
  3. Join the settlement file to the BIN-tier reference. Every settlement row gets a tier label drawn from the acquirer reference, not from the gateway classification field.
  4. Apply the contracted rate card. The rate card is a structured object keyed on network plus product tier per gateway. Each transaction gets an expected fee from the rate card and the gateway-deducted MDR is the actual fee.
  5. Compute the variance and classify the direction. Where actual exceeds expected by more than a 5-basis-point tolerance, raise a CARD_TIER_VARIANCE flagged “over-charge” (the leakage direction). Where expected exceeds actual by more than the tolerance, raise it flagged “under-charge” (the latent true-up direction).
  6. Build the dispute and exposure packs. The over-charge pack groups variances by BIN, ranks by recoverable amount, and exports a dispute file per gateway. The under-charge pack tracks pending true-up exposure so the next unexplained fee adjustment on the settlement statement has a documented basis.

The discipline that converts this from a one-off into a monthly control is automating steps one through five inside the reconciliation engine. A BIN-tier reference loaded as a table, a contracted rate card stored as a structured object, a CARD_TIER_VARIANCE rule with directional output, and a per-network per-tier effective-rate matrix that the CFO reads at month-end. The dispute pack and the exposure pack are downstream artefacts that the controller reviews and acts on — they are not where the engineering effort lives.

Interactive Tool

Quantify your commercial-card mis-slab exposure

Enter your monthly card GMV, the commercial-versus-consumer mix from your acquirer BIN-tier export, and the contracted slabs from your merchant agreement. The calculator returns the monthly leakage on consumer-billed-as-commercial volume, the 90-day recoverable target, and the annualised effective-rate impact so you can scope the BIN audit before commissioning it.

Open the MDR Effective-Rate Calculator →

Worked example: a B2B SaaS commercial card recovery

A Bengaluru-headquartered B2B SaaS company sells enterprise-tier annual subscriptions to mid-market and large-enterprise buyers across India. Card payments come in across both buyer organisations (corporate cards) and individual buyers (consumer cards), with a small share of UPI on the smaller-ticket renewals. Monthly card GMV runs at ₹1.5 crore. The merchant agreement with the gateway specifies:

  • Standard consumer credit (Visa / Mastercard domestic) — 2%
  • Premium signature / infinite — 3%
  • Commercial / corporate / business — 3%
  • Amex / Diners domestic — 3%

The CFO commissions a BIN-tier audit on a 90-day settlement file (₹4.5 crore of credit GMV). The audit pulls the per-transaction BIN, joins to the acquirer schedule, and produces the following tier breakdown by BIN-evidenced classification.

Tier (BIN-evidenced)Volume shareContracted slabActual slab appliedDirection
Standard consumer credit15%2%3%Over-charge
Premium signature / infinitenegligible3%3%Correct
Commercial / corporate85%3%3%Correct

The 85% commercial share is correctly priced — the 3% billed rate matches the contracted commercial slab. The leakage is concentrated in the 15% consumer share that the gateway has routed to the 3% bucket rather than the contracted 2% bucket.

The arithmetic that follows is the recovery calculation.

Monthly consumer-card volume: ₹1.5 crore × 15% = ₹22.5 lakh.

Slab delta on the consumer share: 3% billed minus 2% contracted = 1 percentage point.

Monthly MDR over-billed: ₹22.5 lakh × 1% = ₹22,500.

Monthly GST over-recovered (claimed as ITC, refunded via credit note): ₹22,500 × 18% = ₹4,050.

90-day recoverable MDR: ₹22,500 × 3 = ₹67,500.

Annualised recovery target on a clean go-forward run: ₹22,500 × 12 = ₹2,70,000.

When the gateway processes the retrospective adjustment, the credit note covers ₹67,500 MDR plus ₹12,150 GST on the 90-day window. The GST credit note reduces the merchant’s ITC in the period it is issued and is a standard GSTR-2B reconciliation event — the finance team matches the credit note to the original gateway tax invoice and reflects the reduction in ITC accordingly. The net economic recovery to the SaaS company is the gross MDR delta (₹67,500 for the 90-day window) because GST is ITC-recoverable in either direction.

The forward-looking number is more material than the recovery. The BIN-tier audit, once wired into the monthly reconciliation, locks in ₹2.7 lakh of annual savings at the current GMV. As the business scales — and B2B SaaS card volume tends to scale with enterprise customer count — the consumer-card share may shift but the commercial-card share will stay dominant, and any consumer volume routed to the 3% bucket continues to be a per-transaction leakage. The reciprocal commercial-billed-as-consumer case, where the inverse 15% gap were to flip the other way, would manifest as an unexplained “fee adjustment” line on a later settlement cycle and is the latent exposure the same BIN-tier reconciliation surfaces in the under-charge column.

The reverse direction: when the gateway under-charges commercial volume

The reverse direction — commercial-tier BIN billed at the consumer 2% slab — is less common but real, and it matters to the merchant even though it appears to be a temporary saving. The mechanism is the same as the over-charge direction: the gateway’s BIN classifier maps a BIN to a tier, and where the classifier mapping is stale (because the acquirer schedule has been refreshed but the gateway mapping has not) a recently re-categorised commercial BIN can still be sitting in the consumer bucket. The merchant sees a lower MDR rate that month — there is no audit alarm because the rate is below the contracted commercial slab, which the merchant naively reads as a favourable variance.

What happens next is the gateway’s own reconciliation engine catches the gap on a subsequent cycle. Two outcomes follow. The first is a retroactive fee true-up — an unexplained line on a later settlement statement labelled “fee adjustment” or “MDR true-up” that reflects the gap between billed-at-consumer and contracted-at-commercial across the affected transactions. The second is a quieter re-pricing of future cycles where the same BIN range is now routed correctly and the consumer-slab discount disappears. Either outcome lands in a period the merchant has not budgeted for and is impossible to contest without the BIN-tier reconciliation.

The under-charge column on the variance dashboard exists to make this exposure visible at the moment it accrues, not at the moment the gateway claims it back. A controller who sees that ₹X of commercial volume has been billed at the consumer slab this month and accrues an exposure for the gap in the management accounts is not surprised by the true-up when it lands. The bigger lesson — and the reason the same audit catches both directions — is that the structural pattern is the same: the gateway billing engine is making a classification decision on the BIN, and the merchant is bound by the outcome until the BIN-tier reconciliation forces the conversation.

Reconciliation discipline: making this a standing monthly control

The conversion from one-off recovery exercise to standing control takes three elements.

Acquirer BIN-tier reference refreshed quarterly, ideally monthly. Card issuers launch new commercial products on a rolling basis — a corporate variant of an existing consumer card line, a new business card range targeted at mid-market — and the BIN allocations expand. A stale BIN-tier reference will mis-classify any BIN issued after the last refresh, and the direction of the mis-classification (commercial mis-tagged consumer or vice versa) depends on what the default bucket is for unknown BINs. The discipline is to pull the acquirer BIN export on a fixed cadence — at minimum quarterly, ideally monthly — and load it into the reconciliation engine.

Contracted rate card stored as a structured object, not a PDF clause. The reconciliation engine needs to read the contracted slab as data, not as text. A structured rate card object keyed on gateway, network, product tier, and scope, with the slab as a numeric field, lets the per-transaction expected-fee column be computed deterministically. When the contract changes — annual renegotiation, gateway switch, promo-rate expiry — the rate card object changes once and every subsequent month’s reconciliation picks up the new baseline automatically.

Bidirectional variance class with a non-zero tolerance. The CARD_TIER_VARIANCE rule should support both directions and a 5-basis-point tolerance to suppress rounding noise. The over-charge column feeds the dispute pack. The under-charge column feeds the exposure pack. The CFO dashboard reads the per-network per-tier effective-rate matrix monthly and sees both columns side by side, which is the only way to manage the bilateral economics of a slab-routed billing engine.

The output the CFO actually wants is one number per gateway per month: the gross variance against the contracted rate card, separated into recoverable (over-charge) and at-risk (under-charge). Everything else is engine plumbing.

Continue reading in this cluster

For the underlying regulatory and network references, the Reserve Bank of India MDR rationalisation framework sets the perimeter inside which commercial-card MDR is contractually negotiated.

Primary reference: Reserve Bank of India — MDR rationalisation framework — The 2017 RBI MDR rationalisation circular caps non-RuPay debit card MDR at 0.40% / 0.90% but leaves all credit card MDR — including the commercial and corporate slabs that drive this article — uncapped and contractually negotiated. The defence against mis-slab routing is therefore contract discipline and BIN-tier audit, not regulatory recourse..

Frequently Asked Questions

Why do payment gateways treat commercial and corporate cards as a 3% premium slab?
The 3% slab is not arbitrary — it follows the underlying network interchange. Visa and Mastercard publish higher interchange on commercial products (Visa Business, Visa Corporate, Mastercard World Business, Mastercard Corporate) than on standard consumer credit because the issuer carries more risk on revolving corporate spend, the average ticket is larger, and the network adds a commercial product surcharge. Indian gateways pass through that cost basis at 3% across the board. Razorpay's pricing footnote, PayU's pricing FAQ, and Cashfree's rate card all converge on the same 3% bucket for commercial cards alongside Amex, Diners, EMI, and international cards. The interchange-driven economics are public; the contractual permission to bill the slab without per-transaction itemisation is the audit problem.
How does the gateway decide a card is commercial in the first place?
The decision is mechanical and BIN-driven. The first six to eight digits of the card number (the Bank Identification Number, formally the Issuer Identification Number under ISO 7812) are looked up against the network's published product schedule. A Visa BIN beginning 4XXXXX may be a consumer Visa, a Visa Business, a Visa Signature, or a Visa Infinite — the product attribute is carried in the BIN range and the issuer's BIN allocation table. The acquirer aggregates these into a BIN-tier schedule. The gateway's classifier reads the schedule, matches the BIN, and routes to whichever slab in the merchant's rate card applies. The classifier is deterministic per BIN — once a BIN is in the commercial bucket, every transaction on that BIN goes to the 3% slab until the bucket changes.
Where does the merchant agreement actually need to be tight on this?
The rate card needs to enumerate every card tier the merchant agreement contemplates and assign a specific slab to each. Sloppy contract language — for instance, a rate card that says only 'standard credit 2%, premium 3%' without defining premium — gives the gateway billing engine wide latitude to fold rewards, signature, infinite, and commercial all into the 3% bucket. A tight rate card specifies: standard consumer credit (Visa, Mastercard, RuPay) at the negotiated slab; commercial / corporate / business at a separate explicit slab; premium signature / infinite / rewards at a third slab if the merchant wants to keep them distinct; Amex and Diners domestic at the 3% premium slab; international cards on a separate scope clause. Without the enumeration the slab application is contractually indefensible to dispute.
Can the gateway under-charge commercial volume — and if so, does it matter to the merchant?
Yes, the inverse case happens, and it matters more than it appears at first glance. A commercial-tier BIN that is mis-tagged consumer by the gateway billing engine gets billed at the consumer 2% slab. The merchant sees a lower fee that month and no audit signal fires. Two or three settlement cycles later, the gateway's own reconciliation engine catches the gap and processes a retroactive fee true-up — appearing as an unexplained 'fee adjustment' line on a later settlement. Without the BIN-tier reconciliation, the merchant cannot tie the true-up back to the originating transactions or contest its basis. The merchant cash-flow impact is real even when the contractual position is correct. The audit hygiene is to flag both directions of mis-tier so the true-up never arrives unaccounted for.
Is the 18% GST on the commercial-card MDR fully recoverable as ITC?
Yes — GST at 18% applies on the MDR or platform fee only, never on the transaction value, and the gateway raises a tax invoice naming the GSTIN of the merchant. The ITC is claimable in the normal GSTR-2B reconciliation cycle, provided the merchant's GSTIN on file with the gateway matches the GSTIN under which the input services are being consumed. The audit-trail point is to keep the GST line separately reconciled — never fold it into the MDR percentage — and to match every gateway invoice and credit note to GSTR-2B. When a BIN-tier dispute is resolved and the gateway issues a credit note for the over-billed MDR, the 18% GST on that credit note reduces ITC in the period the credit note is issued, which is a standard GSTR-2B reconciliation event.

See how TransactIG handles reconciliation for your industry

Configuration takes 2–4 weeks. No code development required. ISO 27001:2022 certified.