How online payments actually work

A single "checkout button" hides a real chain of parties and a request/response flow. What a payment gateway actually does, the terminology that gets thrown around loosely, and why almost nobody should touch a raw card number.

Beginner

4 min read

The parties involved, stripped down

Customer   -- pays --> Merchant (your product)
Merchant   -- charges --> Payment Gateway (Paymob, Stripe, etc.)
Gateway    -- routes to --> Card network / Acquiring bank
Acquirer   -- talks to --> Issuing bank (the customer's own bank)

A "payment gateway" (Paymob, Stripe, and similar products globally) is the layer a product actually integrates with — it exists specifically so a merchant never has to speak the card networks' own protocols directly, or hold the licenses and compliance burden required to do so. The gateway handles the messy, regulated part; the merchant just calls an API and gets back a result.

Gateway vs. processor vs. PSP — terms used loosely, worth pinning down once

Payment Processor   - moves the transaction data between the merchant,
                       card networks, and banks. The plumbing.
Payment Gateway      - the customer/developer-facing layer: takes card
                       details, tokenizes them, talks to a processor.
Payment Service
Provider (PSP)       - a gateway that bundles merchant-account setup
                       too, so a business doesn't need its own separate
                       merchant account with a bank. Most products
                       developers integrate with today (Paymob, Stripe,
                       PayPal) are PSPs — gateway and merchant account
                       bundled into one integration.

In everyday conversation these three get used interchangeably, and for the purposes of building a product, that's usually fine — what matters is the one integration surface: an API and/or hosted checkout page, plus a webhook.

Hosted checkout vs. direct API integration

Hosted checkout  - the gateway's own page collects the card details.
                   Your server never sees a raw card number at all.
Direct API        - your own form collects card details, your server
                   (or client-side JS) sends them to the gateway's API.

This choice is really a choice about PCI DSS scope — the security/compliance standard for handling cardholder data. Hosted checkout keeps a card number from ever touching the merchant's own servers, which is why most products default to it: there's no card data to protect because it never arrives. Direct API integration (or even client-side tokenization) still typically ends with the card data going straight to the gateway, never persisted by the merchant, but the compliance surface is larger, and it's the wrong default for a first integration. "Never store a raw card number, ever, under any circumstance" isn't a best practice — it's close to a hard rule.

The typical request flow, end to end

1. Merchant server creates a "payment intent" / "order" via the
   gateway's API (amount, currency, a reference to the merchant's own
   order/invoice ID)
2. Customer is redirected to (or shown inline) the gateway's hosted
   checkout, enters card details there
3. Gateway talks to the card network / issuing bank, gets an
   authorization result
4. Customer is redirected BACK to the merchant's site with a
   success/failure indicator in the URL
5. Separately, asynchronously, the gateway calls the merchant's own
   webhook endpoint with the authoritative result

Step 4 and step 5 look redundant, but they're not — and the difference between them is the entire subject of the next lesson. The short version: step 4 is for the customer's browser experience: which page to show them. Step 5 is the one a merchant's backend should actually trust before marking anything as paid.

Why this matters even before writing any code

A product's actual code footprint for "accepting payments" is often small — call an API to create a charge, receive a webhook, update a database row. The parts that are easy to get wrong aren't the happy path; they're the edges: trusting the wrong signal as proof of payment, mishandling money as a data type, and not planning for a webhook arriving twice. The next several lessons in this domain are about exactly those edges, since that's where nearly every real payment bug in production actually lives.