B2B SaaS companies, enterprise services merchants, and hotel chains with a high share of commercial or corporate cards in the customer mix absorb material leakage because gateways route the entire card volume to the 3% premium slab regardless of BIN tier. A consumer card billed at the corporate 3% slab costs the merchant 0.5 to 1 percentage point per affected transaction, and the gap is invisible at the blended fee column. The reverse direction — commercial card billed at the consumer slab — erodes gateway margin and triggers retroactive reclassification, which arrives as an unexplained fee true-up in a later settlement cycle.
For every card transaction on the settlement file, derive card tier (consumer, commercial, premium-rewards) from the BIN against the acquirer's BIN-tier table, not from the gateway's classification field alone. Compute expected fee as contracted slab for that BIN tier and network times gross. Compare to actual fee column. Aggregate effective rate per network per card tier monthly. Flag consumer-tier effective rate above the contracted consumer slab and commercial-tier effective rate below the contracted commercial slab. Cross-reference any retroactive fee true-up against the same BIN-tier classification.
Acquirer BIN-tier reference table refreshed quarterly with first-six-digit ranges marked consumer, commercial, premium-rewards. Per-network contracted slab table for consumer, commercial, premium, international. BIN-tier rule in the MDR rule set per gateway and network. Per-transaction expected-fee column versus actual-fee column. Monthly effective-rate-by-tier report by gateway. Retroactive fee true-up detector that joins later-cycle adjustments back to the originating BIN classification. Recovery register feeding the merchant-fee leakage class.
A monthly effective-rate matrix by network by card tier showing where the consumer tier is reading above contracted consumer slab and where the commercial tier is reading below the contracted commercial slab. A per-gateway BIN-classification variance log showing transactions where the gateway tier differs from the acquirer tier. A quarterly fee true-up reconciliation aligning retroactive adjustments to BIN classification. A standing dispute register tracking BIN-tier claims filed and accepted.
A Bangalore-based B2B SaaS company sells enterprise plans to mid-market customers across India. About 85% of its monthly card volume comes in on corporate or commercial Visa and Mastercard cards issued to the buying organisations; the remaining 15% is consumer credit cards from individual founders and one-person buyers expensing the subscription. Monthly card gross is ₹1.5 crore. The controller pulls the gateway settlement file, computes the blended fee rate, and reads 3% across the board — exactly the rate Amex and Diners would carry. Something is off. The contracted consumer slab is 2%. The contracted commercial slab is 3%. The blended fee column applies 3% to every card transaction regardless of tier. The 15% consumer volume is being billed at the corporate slab.
That is leakage pattern number four of the eight high-cost merchant-fee patterns: commercial card billed at the consumer rate, or — in the direction that actually drains merchant P&L — consumer card billed at the commercial rate. This guide is the BIN-tier audit path that surfaces both directions, quantifies the recoverable, and lays the reconciliation discipline that catches it on day one of the next settlement cycle.
Quick reference: commercial-versus-consumer card MDR map
| Aspect | Detail |
|---|---|
| Instrument | Credit card (Visa, Mastercard, RuPay credit) |
| Card tiers | Consumer (standard credit), Commercial (corporate, business, purchasing), Premium (signature, infinite, rewards) |
| Network MDR — consumer credit | 1.4% to 2.5% domestic, negotiated; published gateway rate around 2% |
| Network MDR — commercial credit | 2.5% to 3% domestic, billed at the premium 3% slab across Razorpay, PayU, Cashfree |
| Network MDR — Amex, Diners | 2.95% to 3% domestic premium slab |
| Regulatory cap | None — credit card MDR is uncapped and negotiated (RBI caps apply only to non-RuPay debit) |
| Tier carrier | BIN — first six to eight digits of the card number, mapped against acquirer BIN-tier schedule |
| Operative reference | Acquirer interchange schedule (HDFC Acquiring, Axis Acquiring, ICICI Acquiring, RBL Bank, Worldline); the gateway classification field is derivative |
| GST overlay | 18% on the MDR or platform fee only, separate line — never folded into the MDR percentage |
| TDS overlay | Income-tax Act 2025 §393(1) Sl. 8(v) payment code 1035 at 0.1% applies to e-commerce operator payouts where relevant; not to the MDR itself |
The carrier of the tier attribute is the BIN. The carrier of the contracted slab is the merchant agreement. The audit is the join between the two.
Why does this leakage pattern hit B2B merchants hardest?
A consumer D2C brand selling apparel or beauty has a card mix that is overwhelmingly consumer credit and debit, with a long tail of UPI and netbanking. The commercial-card share is structurally below 5%. Misrouting in either direction is a small line.
A B2B SaaS company, an enterprise consulting firm, a hotel chain with a corporate-stay segment, or a travel OTA selling business-class fares to corporate buyers has the opposite mix: 40% to 90% of card volume comes in on commercial or corporate Visa and Mastercard cards. The misrouting line is the dominant fee line. A single percentage point on 85% of ₹1.5 crore is ₹12.75 lakh annually before the audit even begins.
The leakage is concentrated where the merchant agreement and the gateway billing engine diverge from the acquirer’s BIN-tier classification. The merchant signs an agreement specifying “consumer credit 2%, commercial 3%, Amex and Diners 3%”. The gateway billing engine, faced with an ambiguous BIN that could be tagged either way, defaults to the higher slab. The acquirer’s interchange schedule — which is the underlying network truth — agrees with the merchant agreement, not the gateway billing engine. The merchant sees a 3% effective rate and does not look further because 3% looks like the commercial-tier headline.
The Reserve Bank of India’s Payment Aggregator framework specifies disclosure expectations on merchant statements that make this audit feasible per transaction; the per-transaction BIN-tier and contracted-slab join is the operative reconciliation discipline that converts the disclosure expectation into a recoverable.
How does the BIN tier actually identify a commercial card?
The first six digits of the card number — the BIN, now formally the IIN under ISO 7812 but still universally called BIN in payments — identify the issuing bank and product. The seventh and eighth digits in many issuer ranges refine the product tier. A Visa BIN starting 4XXXXX may be a consumer Visa, a Visa Business, a Visa Signature, or a Visa Infinite — the disambiguation lives in the issuer’s BIN allocation table, which the acquirer aggregates into a network-level BIN-tier schedule.
For the audit, the relevant join is: per-transaction settlement file row carries a card-number prefix (typically masked to first six and last four); the acquirer BIN-tier table maps that prefix to a tier label (consumer-credit, commercial, premium-rewards, premium-corporate, debit, prepaid); the merchant agreement names a contracted slab for each tier label.
The gateway-exposed classification field is useful as a cross-check but is not the audit reference. Razorpay surfaces a card-subtype field on its settlement file; PayU exposes a card-category attribute; Cashfree exposes a card-type-detail attribute. Where the gateway classification disagrees with the acquirer BIN-tier classification on the same BIN, the acquirer reference wins and the variance is logged for dispute.
For commercial-card identification specifically, the BIN markers to watch are: Visa Business and Visa Corporate ranges, Mastercard Business and World Business ranges, Mastercard Corporate ranges, and the small but growing RuPay Corporate credit ranges. Diners Club and Amex carry their own commercial ranges but are already at the 3% premium slab regardless of tier, so the audit interlock there is on the contracted slab itself rather than on the tier classification.
Where does the leakage hide on the settlement file?
Three patterns recur. The first is the consumer-billed-as-commercial direction: a consumer-credit BIN is tagged commercial by the gateway billing engine and routed to the 3% slab, costing the merchant a full percentage point per affected transaction. The second is the commercial-billed-as-consumer direction: a commercial BIN is tagged consumer, billed at the consumer slab, and later trued up retroactively when the gateway’s reconciliation engine catches the gap — appearing as an unexplained fee adjustment in a later settlement cycle. The third is the arbitrary uplift: commercial volume is contracted at one rate (say 2.75%) but billed at a higher rate (3%) with no BIN-tier change at all, just a slab application that ignores the contracted commercial number.
All three are surfaced by the same per-network per-tier effective-rate matrix. Effective rate equals fee divided by gross for the segment. A clean monthly file shows: consumer-credit effective rate within ±5 basis points of the contracted consumer slab; commercial effective rate within ±5 basis points of the contracted commercial slab; Amex and Diners structurally pinned at the 3% premium slab. A drift outside that band on any segment is the audit trigger.
What does a clean B2B SaaS audit look like — worked example?
A B2B SaaS company selling enterprise plans, ₹1.5 crore monthly card GMV. The card mix breaks 85% commercial and 15% consumer based on the BIN-tier join against the acquirer schedule. The merchant agreement names a contracted commercial slab of 3% and a contracted consumer slab of 2%. The gateway settlement file applies a single 3% MDR rate to every card transaction in the period.
The consumer leakage line: consumer volume is 15% of ₹1.5 crore, which is ₹22.5 lakh per month. Applying the 3% billed rate gives ₹67,500 in fees. Applying the contracted 2% consumer slab gives ₹45,000 in fees. The gap is ₹22,500 per month, ₹2.7 lakh annually, of consumer-billed-as-commercial leakage that the audit recovers.
The commercial volume — 85% of ₹1.5 crore, or ₹1.275 crore per month — needs a separate verification. Is the 3% billed rate equal to the contracted commercial slab? Yes — both are 3%. The commercial line is correctly priced and there is no leakage in that direction. But the audit does not stop there: the team verifies that the commercial slab itself was not arbitrarily uplifted from a previously-contracted 2.75% or 2.5%, and that no premium-rewards Visa Signature or Visa Infinite subtype within the commercial mix is being routed to a hidden higher slab. Each of those is a separate per-BIN check against the acquirer schedule.
Two flags emerge for the next cycle. First, the consumer slab is contractually 2% but the operational achievable on negotiated enterprise pricing for a ₹1.5 crore monthly card volume is closer to 1.6%; raising that on the next contract review takes another ₹4,500 a month off the consumer line. Second, the commercial slab at 3% is contractually correct but is structurally at the network ceiling; an aggressive renegotiation can target 2.75% or 2.6% on a multi-year commit, taking ₹31,875 per month off the commercial line at the negotiated 2.75% scenario.
The recovered ₹22,500 monthly is the floor. The renegotiation upside is the lift.
What is the reconciliation discipline that catches this on day one?
Wire the BIN-tier check into the per-transaction settlement file ingestion. For every card row, derive the tier from the acquirer BIN-tier table, compute the expected fee as contracted slab times gross, compare to the actual fee column, log the variance with BIN, gateway tier, acquirer tier, contracted slab, billed slab.
Surface three reports monthly. The effective-rate-by-tier matrix tells the controller where each network and tier is reading against the contracted slab. The BIN-classification variance log lists transactions where the gateway tier disagrees with the acquirer tier — these are the dispute candidates. The retroactive-true-up reconciliation joins later-cycle adjustments back to the originating BIN-tier classification so a delayed correction is recognised as the recovery it is, not absorbed as fee variance.
Refresh the acquirer BIN-tier table quarterly. New issuer ranges open monthly and the gateway billing engine lags the acquirer schedule by weeks. Stale BIN-tier tables generate false positives in one direction and miss leakage in the other.
For payment aggregator framework context on disclosure expectations and merchant statement standards, see the Reserve Bank of India’s Payment Aggregator and Payment Gateway guidelines, which set the operative framework under which Razorpay, PayU, Cashfree, and other PAs bill Indian merchants.
Quantify the consumer-billed-as-commercial leakage on your card mix
Enter your monthly card gross, your commercial-versus-consumer split, your contracted slabs, and your billed effective rate. The MDR Effective-Rate Calculator returns the per-tier expected fee, the actual fee, the rupee gap by direction of misrouting, and the annualised recovery — the same arithmetic that converted ₹22,500 a month into a structured BIN-tier dispute on the worked example above.
Open the MDR Effective-Rate Calculator →Continue reading in this cluster
This is pattern four of the eight merchant-fee leakage patterns covered in the cluster. Continue with the cornerstone reference for the full audit framework, then the adjacent long-tail patterns:
- MDR fee reconciliation across networks and instruments — the cornerstone audit framework for the full eight-pattern set
- RuPay credit card on UPI: the 2% interchange that looks like UPI — pattern three of the cluster, a different flavour of network-versus-tier misrouting
- Platform fee leakage on Razorpay, PayU, Cashfree: a D2C audit playbook — the per-transaction fee-column audit that wraps every pattern in this cluster
- Cluster hub: Merchant fees and MDR reconciliation
- Money page: Payment gateway reconciliation