Payment Gateway

A payment gateway is the software that takes payment details at checkout and passes them on for a decision. It sits between the shop front and the bank. The shopper types a card number or taps a wallet button, and the gateway packages that up, encrypts it, and sends it where it needs to go. The answer comes back the same way. To the customer it is a form and a spinner, and to the business it is the part that either works quietly or loses sales at the worst possible moment.

The role grew out of a simple gap. Card networks and banks speak their own message formats, and no shop wants to build against each one. A gateway hides all of that. It offers one interface to the business and deals with the mess behind it, so a shop can add a new card type without rewriting its checkout. It also keeps the riskiest data out of the shop's own systems, which is why the PCI Security Standards Council document library shapes so much of how gateways are designed. Most choices here trace back to keeping card numbers somewhere safe.

What Happens Between Click And Answer

The gateway collects the payment details in a form it controls, then checks the obvious things, such as a card number that fails its own check digit. It encrypts the data and sends the request onward, waits for the answer, returns a clear result to the page, and stores a record so the payment can be found later. Each step sounds small on its own, and together they are what turns a web form into a payment.

Hosted Fields Or Your Own Form

This is the first real decision, and it shapes the audit scope more than anything else you choose. A hosted payment page sends the shopper to the firm's own page, so the card number does not touch the shop at all. Hosted fields keep the shop's design and drop the firm's input boxes into it. A direct build gives full control and pulls the widest scope onto the business. Most teams land on hosted fields. The look stays consistent and the card data still sits elsewhere. This guide to hosted fields against a direct API weighs the choice.

Gateway, Processor And Acquirer

The three are not the same thing, and the words get swapped freely in sales talk. The gateway is what a shop builds against, the processor moves the message traffic, and the acquirer holds the licence, the scheme seat and the money. One firm may sell all three under a single brand. That is fine until something breaks, at which point it helps to know which part is at fault and who has to fix it.

Tokens And Saved Cards

A gateway that keeps cards for repeat use does not store the numbers in the open. It swaps each one for a stored card token and hands that back, and the shop stores the token instead. tokenisation is what makes saved cards, one-click buying and subscriptions workable without heavy audit scope. Tokens are normally tied to one firm, so moving to another means asking for the vault to be transferred rather than simply re-pointing the code. That is worth settling before you sign, not after you want to leave.

More Than Card Traffic

Modern gateways carry wallets, bank transfers, local schemes and buy now pay later through the same layer. Card networks have pushed for a shared online checkout standard, and EMVCo's work on Secure Remote Commerce aims at a common base for that. A virtual terminal covers the case where staff take a payment over the phone, which still matters in trade counters, ticketing and hotels.

Telling The Shop What Happened

A payment does not necessarily finish while the shopper is watching. A bank redirect may complete minutes later, and a bank transfer may land the next morning. So a gateway reports back out of band, often through a webhook call to a web address the shop provides. Handling those calls properly, repeats of the same message included, is one of the more common places an integration goes wrong. Most firms ship a client SDK to take the sharp edges off.

What The Pricing Covers

A gateway is priced per payment, sometimes with a monthly fee on top, and that sits apart from the acquirer's rate for the money side. Where one firm sells both, the two get quoted as a single number, and the split is worth asking for. Refunds, disputes and card storage often carry their own line, and those grow quietly as volume rises.

The Failure Worth Designing For

A clear decline is easy to handle. A gateway timeout is not, because it leaves the payment in an unknown state and a blind retry risks charging the customer twice. The safe pattern is a status check against the first reference before trying anything else. Building it in early costs a day. Bolting it on after a busy weekend costs a good deal more, plus the goodwill of everyone charged twice.

Getting The Build Right First Time

Pick the integration style before the firm, since it shapes the audit scope and the design work. Use tokens from the first build, and make sure repeated webhook calls are handled safely. Log a reference for every payment and keep it on the order. Test the timeout path on purpose rather than hoping it will not happen. And read the pricing for refunds and disputes, not just the headline rate. A payment gateway is often the first payments component a business buys, and this look at the eight step gateway flow shows what happens inside it.

‍