A MID, or merchant identification number, is the ID an acquiring bank or processor gives to one merchant account. Every card transaction carries it, so the bank knows which business took the payment, which fees apply and whose limits it counts against.
One MID is one merchant account. Sellers with real volume usually hold several, and a checkout that can route payments across MIDs decides which account takes each order. I wouldn't run a funnel with real volume on fewer than two.
I spent nine years as CTO of a direct-response company, and a good part of that time went into the checkout that decided which merchant account took each order. A single MID is a single point of failure, and you usually find that out on the day the account behind it gets reviewed.
Below is what a MID actually is, why the words around it get muddled, and how I'd run several without getting into trouble.
What a MID is
When you are approved for a merchant account, the acquirer (the bank that settles card payments into your bank account) sets the account up with a MID. From then on, every authorization your checkout sends is stamped with it. The MID is how the acquirer finds your account's pricing, your descriptor, your merchant category code and your processing limits.
Think of it as an account number for accepting cards. Your gateway login can change. Your checkout can change too, and probably will, more than once. The MID stays tied to the underwriting decision the bank made about your business, which is why losing one hurts far more than losing a login.
MID vs merchant account vs gateway vs processor
These words get used loosely, sometimes by the people selling them to you, and the muddle gets expensive when you're comparing offers side by side. Here is what each one is.
| Term | What it is | What it decides |
|---|---|---|
| Merchant account | Your agreement with an acquiring bank to accept card payments | Fees, reserve, monthly cap, allowed products |
| MID | The ID of one merchant account, sent with every transaction | Which account the sale counts against |
| Acquirer | The bank that underwrites you and settles card funds to you | Whether you are approved, and on what terms |
| Processor | The company that moves the authorization between acquirer and card networks | Technical routing, often bundled with the acquirer |
| Gateway | The software your checkout talks to, which passes the card to the processor | How your site connects, not who pays you |
| MCC | The merchant category code on the account, set by the acquirer | How the networks classify and price your business |
One gateway account can hold several MIDs. NMI is a common example: one gateway, with a separate MID behind it from each acquiring bank you are approved with. That is why the NMI integration treats each MID as its own route.
When I compare payment offers, the row I read first is the merchant account. A gateway is software you can replace. The account and its underwriting terms are what you are really signing, and they decide what happens on a bad week.
Why sellers run more than one MID
A single merchant account is fine until the business outgrows it, and it tends to outgrow it quietly. The reasons to hold several are practical, and every one of them comes back to keeping any single account from deciding whether you can sell today.
- Processing caps. Underwriting sets a monthly volume limit on each account. When a funnel scales past it, the next account takes the overflow.
- Redundancy. Accounts get paused for reviews, often with little warning. If all your revenue runs through that one MID, your whole business is paused with it.
- Approval rates. Issuers approve differently for different acquirers, regions and card types. A second account can approve cards the first one declines.
- Brands and descriptors. Separate products often need their own descriptor, so the buyer recognises the charge on the statement.
- Currencies and regions. A local acquirer for local cards can mean fewer cross-border declines.
Extra MIDs won't hide a chargeback problem. Spreading sales so each account stays under a monitoring threshold is what acquirers treat as evading the program, they look for it, and it tends to end with every account closed at once. If someone sells you MIDs as a way to manage your ratio, walk away.
How MID routing works
Once you have more than one MID, something has to pick the account for each order. That is MID routing, sometimes called load balancing. The checkout applies a rule, sends the authorization to the chosen MID, and records which one took the sale.
When we built routing into the ElasticFunnels checkout, we gave it 6 algorithms, because "which MID takes this order?" has a different best answer for a main-plus-backup setup, a capped account and a cross-border one:
| Rule | How it picks the MID | Good for |
|---|---|---|
| Priority | Always the first MID in your order, then the next if it cannot take the sale | A main account plus backups |
| Weighted | A share of orders per MID, such as 60/40 | Spreading volume by plan |
| Least-used | The MID with the most room left this period | Staying under monthly caps |
| Lowest-decline | The MID that is approving best right now | Approval rate |
| Geo | By the buyer's country | Local acquirers for local cards |
| BIN | By the card's issuing bank or card type | Card types one acquirer approves better |
You can also split test MIDs against each other, the same way you split test a page, and let the approval data decide the weights. Routing and MID split tests run on NMI merchant accounts; the checkout itself runs on Stripe, NMI, PayPal, Klarna and Authorize.net.
If you're starting out, use priority. A main account and a backup covers most of what routing is for, and the cleverer rules only pay once you have approval data to feed them. Every rule you add is also is one more thing to explain when an order lands somewhere you didn't expect. Weighted and lowest-decline need data and someone watching them; priority needs neither.
Soft declines and the cascade
Not every decline means no. A soft decline, such as insufficient funds or a temporary issuer problem, may be approved on another attempt. A hard decline, such as a stolen or closed card, will never be approved.
A cascade takes a soft-declined order and tries it on the next MID in line, while the buyer is still on the checkout. The buyer sees one payment. You keep a sale that one account would have lost. ElasticFunnels cascades on soft declines only; a hard decline stops.
The card networks set limits here, and they are worth knowing. Visa groups some decline codes as "issuer will never approve" and does not allow them to be retried at all. For other declines it allows no more than 15 reattempts in 30 days, and charges a fee beyond that (Visa). A cascade that retries everything, everywhere, turns a lost sale into fees. I'd set it to one retry, on the next MID, for soft declines only, and push back on every request to widen it.
Keeping each MID healthy
An acquirer watches every account it underwrites, and it watches them one at a time. The number that matters most is the dispute and fraud ratio. Visa's monitoring program, VAMP, counts fraud reports plus disputes and divides by settled transactions. From 1 April 2026 a merchant in the U.S., Canada, Europe or Asia Pacific counts as excessive at a ratio of 1.5%, down from 2.2% (Visa VAMP fact sheet).
Picture three accounts at 0.6%, 0.7% and 1.4%. The average is 0.9%, and a blended dashboard would tell you everything is fine. The acquirer behind the third account does not care about your average. That account is a tenth of a point from the line.
- Watch the ratio per MID, not in total. The acquirer judges one account at a time.
- Make the descriptor recognisable. A buyer who does not recognise the charge files a dispute instead of a refund request.
- State rebill terms on the checkout. Surprise subscriptions are a steady source of disputes.
- Answer refund requests fast. A refund costs less than a chargeback and does not count against the ratio.
Setting up MIDs in a funnel
- Get approved. Apply with an acquirer or through a payment facilitator, with your offer, pages, terms and refund policy ready. Each extra MID is its own application.
- Connect the gateway. Add each MID to your checkout through its gateway, such as NMI or Stripe.
- Pick a routing rule. Start with priority (a main account and a backup), then move to weighted or lowest-decline once you have approval data.
- Turn on the cascade for soft declines only.
- Read the numbers per MID: approval rate, refunds and disputes, week by week.
Everything above happens on the custom checkout, so the order bump, the one-click upsell and the rebill all run on the MID the first sale used.
The judgment calls the steps above don't cover.
- Apply for the second MID before you need it. Each one is its own application, and you don't want to be filling one in while the first account is under review.
- Don't trust a blended dispute ratio on any dashboard. If it doesn't show each MID on its own line, it is hiding the account that matters.
- Don't widen the cascade to chase approval rate. Every extra retry is a fee risk, and Visa counts them.
- When a vendor pitches more MIDs as a fix for your ratio, end the call.
None of this is glamorous. Nobody picks a funnel builder for its descriptor settings. But the checkout is where the money actually changes hands, and an afternoon spent on it now is a lot cheaper than learning it during an account review.
