Ask ten store owners who processes their payments and you will get ten different answers, most of them naming a company that does something else. The confusion is understandable. The card industry sells bundles, and the bundle usually carries one brand name while four companies do the work underneath.
This matters the day something goes wrong. A late payout, a sudden hold on funds, a decline that makes no sense, a rate that crept up: each of those has a different owner, and calling the wrong one wastes a week.
The four parties
Every card payment involves at least four organisations, plus the card networks that sit between them.
The gateway
The gateway is software. It takes the card details from your checkout, encrypts them, and passes them to the processor in a format the processor understands. It also handles the things that happen around a transaction: tokenising a card so you can charge it again, running an address check, triggering a 3D Secure challenge, retrying a failed authorisation, storing a transaction history you can search.
NMI is a gateway. So are Authorize.Net and Braintree. A gateway does not hold your money and cannot pay you. It is the wiring, not the bank.
The processor
The processor moves the message on to the card networks and, later, moves the money. When an authorisation request leaves your gateway it reaches the processor, which routes it to Visa or Mastercard, which routes it to the customer bank for a yes or no. That round trip takes about a second.
The processor is also the party that batches your day of sales and starts the settlement that eventually lands in your bank account. First Data, TSYS, Elavon, Worldpay and Global Payments are processors.
The acquiring bank
The acquirer is a bank licensed by the card networks to accept card money on behalf of merchants. It carries the risk. If you take fifty thousand in orders, disappear, and every customer files a chargeback, the acquirer pays those customers back out of its own pocket and then tries to recover from you.
That risk is the reason underwriting exists, the reason a reserve may be held, and the reason an acquirer can close an account with little notice. Many processors are owned by, or partnered with, an acquiring bank, which is why the two names blur together.
The merchant account
The merchant account is the account the acquirer opens in your business name. It is a holding account: card money lands there, fees come out, and the balance is paid to your ordinary business bank account on a schedule. It has a merchant ID, an MID, which identifies your business to the card networks.
You either have your own merchant account, underwritten in your name, or you are a sub-merchant on somebody else aggregated account. That single distinction changes almost everything about how you get paid, and it is covered below.
Where the ISO fits
An independent sales organisation, an ISO, sells merchant accounts on behalf of an acquirer. Most merchants sign with an ISO rather than with the bank directly. Your rates, your statement and your support line usually come from the ISO. The ISO may also brand a gateway as its own, which is why so many stores run what looks like a proprietary gateway and is really NMI with a different logo on the login screen.
A good ISO is a genuine advocate: it knows the underwriting, it can argue an interchange qualification with the processor, and it answers the phone. A bad one is a layer of markup with a call centre attached.
Aggregators, and why they feel simpler
Stripe, PayPal, Square and WooCommerce Payments work differently. They hold one large merchant account with an acquirer and place thousands of businesses inside it as sub-merchants. There is no underwriting for you to pass at sign-up, which is why you can start taking money in ten minutes.
The trade is control. The aggregator owns the relationship with the acquirer, sets the payout schedule, decides when to hold funds, and can close your account on its own risk model without the notice a direct merchant account would give you. For a store doing a few thousand a month, that trade is usually worth it. For a store doing six figures a month, or selling anything an automated risk model finds unusual, it stops being worth it.
Following one payment through
A customer buys a two hundred pound order at ten in the morning.
- The checkout collects the card in a hosted field, so the number never reaches your server. The gateway returns a token.
- Your store asks the gateway to authorise two hundred pounds against that token.
- The gateway sends the request to the processor, which routes it through Visa to the customer bank.
- The bank checks the balance, runs its own fraud scoring, and approves. The two hundred is now held against the customer available balance, but no money has moved.
- Approval travels back the same path in about a second. Your store marks the order as paid.
- That evening your gateway or your plugin captures the authorisation and the day sales are batched.
- The processor settles the batch through the networks. The acquirer receives the funds, deducts interchange, network fees and its own margin, and credits your merchant account.
- One to three business days later, the balance is paid out to your business bank account.
Two useful facts fall out of this. First, an authorisation is not money, which is why a void before settlement is free and a refund after it is not. Second, the delay you experience as slow payouts is settlement plus your acquirer funding schedule, and no plugin setting can shorten it.
Who to call when
| Symptom | Who owns it |
|---|---|
| Card declined, code 200 or a bank response | Nobody you can call. The customer bank declined it. The customer must ask their bank. |
| Gateway timeout, transaction not appearing | Gateway support, through your ISO if you have one. |
| Payout later than usual, or held | Acquirer or ISO. This is a risk decision, not a technical one. |
| Rate went up without notice | ISO first, then read the statement for a new network pass-through. |
| Chargeback received | Acquirer sends it, you respond through the gateway or the ISO portal. |
| Checkout error before the card is sent | Your plugin or theme. Nothing has reached the gateway yet. |
Why the split matters for a WooCommerce store
Because the gateway is separable from everything else, you can change the software without changing who banks you. A store on NMI can move from one ISO to another, or from one processor to another, and keep the same integration, the same saved cards and the same reporting. A store on an aggregator cannot: leaving means a new integration and, usually, losing the stored cards.
That portability is the real argument for keeping your own merchant account, and it is worth reading in full: why keep your own merchant account.
A short glossary
- MID: your merchant ID at the acquirer. A store selling in two countries or under two brands often has several.
- Authorisation: a hold on the customer available funds. Expires, usually in seven days.
- Capture: the instruction that turns an authorisation into money owed to you.
- Settlement: the nightly movement of captured funds through the networks.
- Funding: the payout from your merchant account to your bank account.
- Interchange: the share of each sale that goes to the customer bank. Set by the networks, not negotiable.
- Sub-merchant: a business trading inside somebody else merchant account.
Learn these six and most merchant statements stop being mysterious.