You type your card number, tap "Pay", a spinner turns for a couple of seconds, and a green tick appears. It feels like one step.

It's actually a relay race between at least five parties, two of which you've probably never heard of, and the money hasn't even moved yet when you see that tick.

If you build anything that takes payments (rent, bookings, subscriptions, donations), knowing this relay changes how you write the code. So let's follow one payment from the button to the bank.

Meet the cast

• The customer (cardholder), with a card from their bank.
• The issuer: the customer's bank. It decides yes or no.
• The merchant: you, or your client.
• The acquirer: the merchant's bank, which receives card payments on the merchant's behalf.
• The card network: Visa, Mastercard and friends, routing messages between acquirers and issuers.
• The payment gateway: the service your code actually talks to. It wraps everything above in an API, and often acts as the acquirer side too.

Your app only ever speaks to the gateway. Everything else happens behind it.

Leg 1: tokenization, or "never touch the card"

The first rule of modern payments: the card number should never reach your server.

Instead, the card form is provided by the gateway: a hosted payment page you redirect to, or fields embedded in your page that are really served from the gateway's domain. The customer types the card details into the gateway's fields. The gateway stores them and hands your frontend a token: a meaningless reference like tok_8fa2... that only that gateway, for your account, can turn back into a card.

Think of a coat check. You hand over the coat and get a numbered ticket. The ticket is useless to a thief who doesn't also have access to that cloakroom.

This matters because of PCI DSS, the security standard for anyone handling card data. If raw card numbers pass through your servers, your whole system is in scope for it: audits, controls, paperwork. If they only ever touch the gateway's fields, your scope shrinks dramatically. Hosted fields aren't a design preference; they're the cheapest security decision you'll ever make.

Leg 2: authorization, the "yes, probably"

Your server sends the token and the amount to the gateway. The gateway passes an authorization request through the acquirer and card network to the issuer, which checks a few things in a fraction of a second: is the card valid, is there enough available balance or credit, does this look like fraud?

Sometimes the issuer wants proof it's really the cardholder, which is where 3-D Secure comes in: the "confirm in your banking app" or one-time code step. Your integration has to handle that extra round trip, which is why modern gateway APIs model a payment as something with states rather than a single call that returns success or failure.

If approved, the issuer places a hold on the amount. The customer sees it as pending. No money has moved. The issuer has only promised it.

Leg 3: capture, the "yes, take it"

Capture tells the gateway to actually collect the authorized amount. Most online shops authorize and capture in one go, and you never notice two steps.

Splitting them is useful when the final amount or the delivery isn't certain yet. Hotels and car rentals are the classic example: authorize at booking, capture at checkout. You can usually capture less than you authorized, but not more. And authorizations don't last forever: if you don't capture within the window your gateway and the card network allow, the hold drops and you have to authorize again.

Leg 4: settlement, the slow part

Captured payments are batched and settled between the banks, and the money lands in the merchant's account later, typically after a few business days, minus fees. This is why "payment succeeded" and "money in the bank" are two different events, and why finance teams reconcile payouts against transactions rather than trusting the app's dashboard.

Leg 5: webhooks, the source of truth

Here's the part that bites developers. After 3-D Secure or a hosted payment page, the customer is redirected back to your site with something like ?status=success. It's tempting to mark the invoice as paid right there.

Don't. Customers close tabs, lose signal, or never get redirected back at all. And a redirect URL is something anyone can type.

A webhook is the gateway calling your endpoint: "payment succeeded", "payment failed", "refund completed", "dispute opened". Treat these events with care:

• Verify the signature on every webhook, so nobody can fake a "payment succeeded".
• Expect duplicates. Gateways retry until you respond with success, so the same event can arrive twice. Store the event ID with a unique constraint.
• Expect odd ordering. Events can arrive out of order. When in doubt, fetch the payment's current state from the gateway's API.
• Respond fast, process later. Save the event, return 200, and do the real work in a queued job.

Leg 6: refunds and disputes

A refund isn't "undoing" the payment. It's a new transaction in the opposite direction, linked to the original, and it can be partial. It also takes time to show up on the customer's statement, which is worth telling them in the UI so they don't contact support the next morning.

A dispute (chargeback) is different: the customer asks their bank to reverse the charge. The money is pulled back while the case is reviewed, and the merchant submits evidence. Your system should record disputes as their own state, not quietly flip a payment back to "unpaid".

What this means for your code

Also store amounts as integers in the smallest currency unit (or as exact decimals), never as floats, and always store the currency next to the amount.

The two-second summary

Token instead of card. Authorization is a promise. Capture is the claim. Settlement is the money. Webhooks are the truth. Refunds are new transactions.

Next time you see that green tick, you'll know it's the start of the process, not the end.

Which part of payment integrations caught you out first: webhooks, 3-D Secure, refunds, or reconciliation?