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.
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.
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.
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
| Aspect | Detail |
|---|---|
| Instrument | Credit card — commercial / corporate / business product tier |
| Networks in scope | Visa Business, Visa Corporate; Mastercard World Business, Mastercard Corporate; RuPay Corporate (small footprint); Amex and Diners corporate ranges (already at 3%) |
| Regulatory cap | None — credit card MDR is uncapped and contractually negotiated (RBI 2017 circular caps non-RuPay debit only) |
| Razorpay published slab | 3% plus GST on commercial cards (pricing-page footnote) |
| PayU published slab | 3% plus GST on commercial cards (pricing FAQ) |
| Cashfree published slab | Bucketed with premium and Amex / Diners at the 3% tier |
| Consumer credit slab (Visa / Mastercard) for contrast | 1.4% to 2.5% domestic, gateways list around 2%; enterprise-negotiated 1.4% to 1.6% above ₹1 crore monthly GMV |
| Tier carrier | BIN — first six to eight digits of the card number, mapped against the acquirer BIN-tier schedule |
| GST on MDR | 18% on the fee only, separate line — never folded into the MDR percentage |
| Retrospective dispute window | Typically 90 days, gateway-dependent |
| Variance class | CARD_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.
- 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.
- 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).
- 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.
- 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.
- 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).
- 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.
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 share | Contracted slab | Actual slab applied | Direction |
|---|---|---|---|---|
| Standard consumer credit | 15% | 2% | 3% | Over-charge |
| Premium signature / infinite | negligible | 3% | 3% | Correct |
| Commercial / corporate | 85% | 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
- Premium card misrouting to the 3% slab: a BIN-tier audit — the consumer-rewards angle on the same routing pattern, with a luxury hospitality worked example.
- Commercial card billed at consumer rate (or vice versa): MDR audit path — the sibling piece focused specifically on the audit-path mechanics.
- Amex and Diners hidden inside a blended MDR rate — the same 3% bucket viewed from the network-pricing-opacity angle.
- MDR fee reconciliation against contracted gateway rates — the parent reconciliation workflow this BIN-tier audit sits inside.
- Merchant fees cluster hub — the eight-pattern leakage framework for Indian payment gateways.
- Payment gateway reconciliation money page — TransactIG’s gateway reconciliation surface.
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.