A payment gateway is the part of card payments most people can point at, because it is the only part they see. It is the form on the checkout page, the spinner after the customer presses pay, and the message that comes back. Everything else happens somewhere they will never look.
That visibility makes it the thing merchants blame when payments fail, and it is usually the wrong culprit. Understanding what the gateway does, and where it hands off, is what tells you who to call when something breaks.
What actually happens when someone pays
The sequence takes about two seconds and has more steps in it than that suggests.
Your customer enters their card details. The gateway encrypts them immediately, so the number is not sitting in readable form on your site or in your logs. It then sends an authorisation request through the card network to the bank that issued the card.
That bank makes the decision. It checks the card is real and active, that funds or credit are available, and that the transaction does not look like fraud against everything else it knows about that cardholder. It answers approve or decline, and it does so in under a second.
The answer travels back the same way: through the network, to your acquirer, to the gateway, to your checkout. If it is an approval, the amount is held against the customer's balance. No money has moved yet. Settlement comes later, in a batch, and that is a separate process from the one you just watched.
Two things follow from this. The gateway never decides anything, it carries decisions. And the two seconds a customer waits contain several parties, any of which can be the reason the answer was no.
Gateway, merchant account, acquirer, processor
These four words get used as though they were interchangeable, largely because most providers sell all four as one product.
The gateway moves information. The merchant account receives money and is held with an acquirer, the licensed institution that underwrote your business and is accountable for it to the card schemes. The processor is the party that does the technical work of moving funds afterwards.
A bundled provider gives you one contract covering the lot, which is genuinely simpler until something goes wrong or you want to change one part. An unbundled setup means more relationships and more flexibility, including the ability to keep your integration while changing who holds the money.
Neither is better. But knowing which arrangement you are in tells you who is responsible when a payment fails, and that is worth establishing before you need it rather than during an outage.
Hosted or API, and what each does to your PCI scope
This is the decision with the longest tail, because it is difficult to reverse.
A hosted checkout means the card details are entered on a page the provider controls, either by redirecting the customer or by embedding an iframe. The card number never touches your servers. The trade is that you have less control over how the payment step looks and feels, though the gap has narrowed considerably.
An API integration means the details are captured in your own interface and sent to the provider by your own code. You control the entire experience. You also take on responsibility for card data passing through your systems.
The difference matters most for PCI DSS. Every business accepting cards is in scope, but the level of validation required varies enormously with where the card number goes. Keeping it off your infrastructure entirely puts you at the lighter end. Handling it directly puts you in a considerably heavier bracket, with the audit burden and the ongoing cost that implies.
Most businesses should start hosted and move to an API only when there is a concrete reason, because rebuilding a checkout to reduce compliance scope is a worse project than choosing correctly at the start. Confirm the specifics with your acquirer before you build.
Why a gateway decline is rarely the gateway
The most useful thing to know about gateways is that they almost never refuse anyone. The technology is not making a judgement about your business.
When a transaction fails, it is one of three things. The issuing bank declined it, which is by far the most common and has nothing to do with your setup. Authentication failed, meaning the customer did not complete the 3DS2 step or their bank was not satisfied by it. Or your acquirer's own risk rules stopped it before it left, which is the case worth investigating, because those rules are tuned and can be tuned badly.
The same logic applies to onboarding. A business that is told it cannot use a gateway has almost always been refused by the underwriting behind the gateway, not by the gateway itself. The technology would happily carry the transaction. The institution accountable for the money decided otherwise.
This distinction is worth pressing on when a provider gives you a vague answer. The gateway response code names the reason, and a provider who will not tell you what it was is choosing not to.
What a good gateway adds
Beyond carrying transactions, the differences worth paying for are these.
Authentication applied with judgement. 3DS2 protects you, and it also adds friction that costs conversions. A good gateway applies it where the risk merits it rather than to everything.
Tokenisation. The card is stored as a token so repeat customers and subscriptions do not re-enter details, and the real number stays out of your systems. This is what makes recurring billing possible without holding card data.
The payment methods your customers actually use. Wallets, and local methods in the markets you sell to. A checkout that only offers cards will lose sales in countries where cards are not the default.
Reporting your finance team can reconcile. Itemised per transaction, with fees broken out. Blended reporting hides where money went.
Routing, if the provider has more than one acquiring path. Where several are available, the gateway is where the choice gets made per transaction, which shows up as an approval rate rather than as a feature.
What to ask before you integrate
Four questions, all answerable in one conversation.
Which integration methods do you support, and what does each do to my PCI validation? Who underwrites me, and is that the same company as the gateway? What happens to my integration if I change acquirer later? And when a transaction is declined, will you tell me the reason code?
A provider who answers all four plainly is one you can plan around. A provider who cannot answer the last one has told you something useful about how the next year is going to go.