How Are Online Payments Processed? Payment Gateways, Authorization, and Settlement Made Simple

In online shopping, you enter your card number, press the pay button, and within a few seconds a screen tells you the payment is done. It looks like a single button finished the job, but in that brief moment several companies move in quick coordination.

In this post, I’ll follow the flow of how an online payment is processed, without any code. I’ll unpack who takes part, what a payment gateway does, how authorization and settlement differ, and who holds your card information, all at a non-developer’s level.

A payment has more participants than you’d think #

A single transaction brings five parties into play: the customer who pays, the merchant (the shop) selling the goods, the payment gateway that brokers the transaction, the card company and bank that issued the card, and the card network that links them all.

It looks complicated at first, but the roles are clear. The customer pays, the merchant sells, and the card company decides whether this customer can spend this amount. The problem is that it’s far too cumbersome for a merchant to connect directly with every single card company. This is where the payment gateway comes in.

A payment gateway is the broker of the transaction #

A payment gateway, often called a PG, is a payment broker. Instead of a shop contracting and connecting separately with every card company and every bank, it connects with one gateway, and the gateway links to the many card companies behind the scenes.

Think of a telephone operator. Rather than memorizing everyone’s number and dialing yourself, you ask the operator and they connect you to the right party. The shop only has to deal with one window, the gateway, and the gateway handles the complicated back-and-forth with the card companies. When you press the pay button, a familiar payment window appears, and the side that shows that window and receives the card details is usually the gateway.

Authorization asks whether the payment can go through #

What happens right after you press the pay button is authorization. Through the gateway, the card company is asked whether this card may be charged this amount. The card company checks whether the card is valid, whether there’s enough remaining limit, and whether it’s been reported stolen, then answers right away.

There’s one thing to note here. Authorization only confirms that the payment is possible and sets that amount aside; it doesn’t actually move any money. Even when the “payment complete” screen appears, the money doesn’t immediately land in the merchant’s account. It’s like booking a table at a restaurant: your place is secured, but you haven’t paid for the meal yet.

Settlement is when the money actually moves #

Gathering authorized payments and actually moving the money is settlement. It usually happens not on the day of payment but a few days later. The card company collects the money on the customer’s behalf and hands it to the gateway, and the gateway deposits the remainder, minus its fee, to the merchant.

So from the merchant’s side, a gap opens between when the payment completes and when the money arrives in the account. The payment fee is deducted at this settlement stage too. The reason people say “the payment went through, but the deposit comes days later” is that authorization and settlement are separate stages.

The merchant doesn’t hold your card information #

Finally, security. A card number is highly sensitive, so a small shop holding it directly carries a big leak risk. That’s why, in most payments, card information goes straight to the gateway without passing through the merchant.

Instead of reusing the card number as is, the gateway swaps it for a substitute number called a token. The next time you pay with the same card, this token is used instead of the real number. Companies that handle card numbers are required to meet strict security standards, and this structure lets a small shop avoid that burden directly — the gateway shoulders it instead. All of this happens on top of HTTPS, which seals the communication, of course.

Why this makes work easier for non-developers #

• You understand the settlement cycle. You can see why the money arrives days after the payment completed, and why a fee is deducted in the settlement records.
• You distinguish payment failures. You can tell that the response differs depending on whether it’s the card’s limit, a card company outage, or a problem on the gateway’s side.
• You can explain refunds. You can calmly guide a customer on why refunding a merely authorized payment differs from refunding one that has already settled.

Wrapping up #

Today we looked at how an online payment is processed through the customer, the merchant, the gateway, and the card company, in the two stages of authorization and settlement. The key distinction is that authorization confirms whether the payment can go through, while settlement is when the money actually moves a few days later.

If you’re curious about the HTTPS and encryption that protect payment information, read What the Padlock in Your Address Bar Protects; if you’d like to know more about the agreement by which a shop and a gateway exchange information, read What Is an API.