MID cascading is the mechanic that lets a platform with multiple acquirers behave like a platform with one - but with the resilience of all of them. Done well, it lifts approval ratios, manages risk concentration, and protects against acquirer-specific outages. Done badly, it creates a maintenance nightmare.
The basic setup: each merchant has multiple MIDs across different acquirers. The routing engine decides which MID a transaction goes to first; on decline, it cascades to the next. The cascade order is a configuration, not a code change.
Choosing the next MID
The cascade order should reflect three things. First, acquirer fit - which acquirer is strongest on the transaction's BIN range, currency and method. Second, cost - interchange-aware routing minimises per-transaction cost where approval rates are equal. Third, capacity - distributing volume across acquirers prevents any single MID from breaching scheme thresholds (chargeback ratio, approval ratio).
The decline-handling logic deserves more thought than most platforms give it. Not every decline should retry. Hard declines (lost card, stolen card, fraud) should not retry on any acquirer. Soft declines should retry intelligently - same network on a different acquirer for soft auth issues; different network entirely for issuer-network issues.
Measuring whether a cascade works
Monitoring is the discipline that keeps cascading working. Without per-MID approval-ratio tracking and per-BIN performance views, the cascade order becomes ossified. The leading platforms re-evaluate the cascade weekly based on the data; the rest leave it set up at go-live and never touch it again.
