Merchant account payment processing is not one service, it is four stacked together: a gateway, a processor, an acquiring bank and the account itself. When a payment fails, most of the wasted time goes to describing the problem to a company that cannot see the layer it happened on.

Here is how to tell them apart, using the failures you are most likely to hit.

The four layers, plainly

The gateway takes card data from your checkout or terminal and encrypts it. The processor carries messages between the gateway, the card networks and the banks. The acquiring bank holds your merchant account, takes on your risk and settles funds to you. The account is the ledger where card money lands before it reaches your business bank.

Sometimes one company sells you all four under a single contract. That is convenient, and it also means you may not know which layer failed, because the support desk answering you is not necessarily the team that owns it.

The card was declined at checkout

This one is usually not yours at all. A decline is typically the cardholder’s issuing bank saying no, for reasons it does not have to share: insufficient funds, a fraud rule on their side, an address mismatch, a card blocked for travel. Your gateway just relays the message.

Two versions are worth separating. A single customer declining is a customer problem. A pattern of declines across many customers, starting at a specific hour, is a gateway or processor problem, and it is worth checking whether anything on your side changed that day: a plugin update, a new checkout, an expired certificate.

Payments went through, but no money arrived

Now you are looking at the account and the bank, not the gateway. Authorizations succeeded, so the top of the stack is fine. Something in settlement is not.

Common causes, in rough order: the batch did not close, settlement bank details are wrong or newly changed, a reserve is holding back part of the funding, refunds and chargebacks from an earlier period netted against this cycle, or the account has been placed under review. The first two are administrative and fix quickly. The third is a written term you should already know, explained in how rolling and capped reserves work. The last one changes your week.

Where merchant account payment processing actually stops working

Not at the gateway. At the underwriting layer, where somebody decides whether your business gets to keep processing at all.

That decision belongs to the acquiring bank, which is why your gateway vendor cannot help you with it and why an aggregated setup, where the underwriting relationship is not in your name, leaves you with even less to work with. The difference between an aggregator and your own account is exactly this: who holds the relationship that decides your continuity.

If it goes as far as a termination, the card networks add a record. Under Mastercard’s Security Rules and Procedures Merchant Edition, a processor must report a qualifying terminated merchant within one business day, and the listing runs five years before Mastercard purges it automatically. Mastercard does not assess whether a listing is accurate, and only the acquirer that placed it can remove it, and only if it was added in error or under reason code 12 for PCI non-compliance once compliance is confirmed.

Which company do you actually contact

Work down the stack in this order and you will nearly always land in the right place first time:

  • Checkout page or terminal misbehaving: the gateway.
  • Declines across many cards at once: the gateway, then the processor.
  • Money missing or late: your processor’s support, referencing the batch and settlement dates.
  • A hold, a reserve change or a review notice: the processor, and behind them the acquiring bank.
  • A closure notice: read it first, then get in touch about a replacement immediately, because those two clocks run separately. The first week after being dropped sets out the order.

What to ask before you sign, so this is easier later

Ask who the sponsoring bank is, by name. Ask whether the gateway is included and whether you keep it if you leave. Ask who handles disputes and where they appear. Ask what your settlement schedule is and what would change it. The full list of questions worth asking a processor covers the rest.

A business that can name all four layers in its own stack recovers from a failure in hours. One that cannot spends the week finding out who to talk to.

Frequently asked questions

Can I keep my gateway if I change processors? Sometimes, depending on whether the gateway is a separate product or bundled into your processor’s platform. Ask before you sign rather than at the point of leaving, since rebuilding a checkout and re-tokenizing stored cards is real work that lands at the worst possible moment.

Is the processor the same as the acquiring bank? Not usually. The processor runs the technology and the day to day relationship. The acquiring bank sponsors the account and carries the risk. Many businesses only ever speak to the processor, which is fine until a risk decision arrives from a party they have never dealt with.

Why does my descriptor matter? Because it is what customers see on their statement, and an unrecognizable descriptor generates disputes from people who simply do not remember buying from you. Fixing it is one of the cheapest ways to lower a dispute rate, covered in how to bring a chargeback ratio down.

Do I need separate accounts for online and in-person sales? Not necessarily, though card-present and card-not-present transactions are priced and risk-assessed differently. What matters is that both channels were disclosed during underwriting, since adding an unexpected channel later is a common trigger for review.

What is the fastest thing I can do today to reduce failures? Reconcile one recent month, line by line, from gross sales to what landed in the bank. Most stack problems show up there before anyone notices them at the checkout.