A MID, or merchant ID (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 narrows the field down to the MIDs eligible for this charge, then splits the charge across them by weight.
In the ElasticFunnels checkout, every MID carries a weight and a set of rules, and they all run together on one pass per charge — it isn't a menu where you pick one rule and the others sit unused:
| Setting | What it does | Good for |
|---|---|---|
| Weight | Each MID's share of the traffic that reaches it, such as 60/40 | Spreading volume by plan |
| Card brand, product, amount | Only MIDs whose rules match the charge stay eligible | Sending a card type or product to the account approved for it |
| Daily and monthly caps | A MID over its cap drops out of the pool until it resets | Staying under an acquirer's limit |
| Subscription pin | A rebill always returns to the MID that took the first sale | Keeping a vaulted card on the account that stored it |
The load balancing report breaks out sales, revenue and refunds per MID for the period you pick, so you can see which account is carrying more of the settled volume and adjust weights by hand. Routing runs on your NMI merchant accounts only; Stripe, PayPal, Klarna and Authorize.net each connect as one account, not a pool you can route or cascade across. The checkout itself runs on Stripe, NMI, PayPal, Klarna and Authorize.net.
If you're starting out, two MIDs and a simple weight split covers most of what routing is for. Add card-brand or amount rules once you know which acquirer approves which cards best, and watch the caps so an account never gets shut off mid-charge.
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 — only when the card itself can be re-sent, so it does not reach Collect.js tokenized card entry, Apple Pay, Google Pay or a vaulted card. 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. ElasticFunnels caps it at 2 retries by default (configurable 0-5); I'd keep it low, 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 NMI merchant account. Stripe, PayPal, Klarna and Authorize.net each connect as one account, not a pool of MIDs.
- Set a weight per MID. Start with a simple split across a main account and a backup, then add card-brand or amount rules once the load balancing report shows which account is settling more.
- Turn on the cascade for soft declines only — it needs a re-sendable card, so it does not cover Collect.js or wallet checkouts.
- Read the numbers per MID: sales, revenue and refunds, 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 the step of the funnel where the money actually changes hands, and an afternoon spent on it now is a lot cheaper than learning it during an account review.
