How Online Payments Actually Work: Behind the Scenes

Most people running an online business treat payments as a black box that occasionally returns an error they cannot interpret. Understanding the actual sequence is worth an hour, because almost every confusing situation in payments, a charge that shows on the customer's statement but not in your dashboard, a decline that succeeds on retry, money that arrives days later than expected, has a straightforward explanation once you know the steps.

The parties involved

A card payment has more participants than the two obvious ones.

• The cardholder, your customer.


• The issuing bank, which gave them the card and holds their money.


• The card network, Visa, Mastercard, Amex, which routes messages and sets the rules.


• The acquiring bank, which holds the merchant account that receives funds.


• The payment processor or gateway, which is what you actually integrate with. Stripe, Adyen, PayPal and similar sit here, and many bundle the acquirer role.


• The merchant of record, the legal seller. Usually you; sometimes a provider like Paddle, which changes who carries tax and dispute liability.

Fees exist because five of these entities take a share.

The sequence, step by step

1. Tokenisation

The customer enters card details. In any modern setup these do not touch your server. The processor's hosted field or SDK sends them directly to the processor, which returns a token, a meaningless reference standing in for the card.

This is why PCI compliance is manageable for small businesses: if card data never reaches your systems, most of the burden falls on the processor. Handling raw card numbers yourself moves you into a much heavier compliance regime, which is why nobody should.

2. Authorisation

You send the token and amount to the processor, which routes an authorisation request through the network to the issuing bank.

The issuer checks the card is valid, the funds or credit are available, and its own risk rules. It responds approve or decline, typically in under a second.

Crucially, authorisation is not payment. No money has moved. The issuer has placed a hold on the amount, reducing the cardholder's available balance. This is why a customer can see a charge on their app that you cannot see as settled revenue.

3. Capture

Capture converts the authorisation into an actual request for funds.

Most online checkouts authorise and capture in one step, which is why the distinction is invisible. But they are separable, and the separation is useful: authorise when the order is placed, capture when it ships. Authorisations expire, typically within about a week, and an expired authorisation must be redone.

4. Clearing and settlement

The captured transaction is batched and submitted through the network. The issuer transfers funds to the acquirer, minus interchange. The acquirer credits the merchant account, minus its own fees.

This is where the delay lives. Settlement takes days, not seconds, which is why your payout schedule is not instant.

5. Payout

The processor transfers the settled balance to your bank account on your payout schedule. New accounts usually sit on a longer hold while the processor assesses risk, and some categories carry a rolling reserve where a percentage is held back for a period.

Why payments get declined

Decline codes are more informative than most people realise, and the important distinction is between hard and soft declines.

Soft declines are temporary and worth retrying:

• Insufficient funds


• A temporary issuer or network problem


• Velocity limits, meaning too many attempts in a short window


• A generic "do not honour", which frequently means an issuer risk rule fired

Hard declines should not be retried, and repeated retries can flag your account:

• Card reported lost or stolen


• Card closed or invalid


• Explicit issuer refusal

For subscription billing this distinction is the whole game. Retrying soft declines intelligently recovers real revenue; retrying hard declines achieves nothing and damages your standing with the network. The subscription billing best practices piece covers retry strategy in detail.

The most common single cause of a "do not honour" is the issuer's fraud model, not the customer's balance. Which is why the same card often succeeds on a second attempt from a different device or after the customer confirms the transaction in their banking app.

3D Secure and strong customer authentication

In the EU, the UK and a growing set of other markets, regulation requires additional authentication on many consumer transactions. In practice this means the customer is redirected to their bank to confirm, usually through an app.

The tradeoffs are real:

• It shifts liability for fraudulent transactions from you to the issuer.


• It reduces fraud materially.


• It adds a step, and some customers abandon at it.

There are exemptions, for low-value transactions, for recurring charges of a fixed amount, and for transactions the issuer judges low risk. Configuring these correctly reduces friction substantially, and most businesses never look at them.

Where the fees actually go

The headline rate decomposes roughly into:

• Interchange, paid to the issuing bank. The largest component, set by the network, varying by card type. Premium rewards cards cost more to accept, which is why the same processor rate can produce different effective costs across customer bases.


• Network assessment, paid to Visa or Mastercard. Small.


• Processor margin, which is what your provider keeps.

This is why "2.9 percent plus a fixed fee" is a blended average rather than a real per-transaction cost. Businesses at scale move to interchange-plus pricing, which exposes the components and is usually cheaper.

Alternatives to cards

Cards are not the only rail, and in several markets they are not the main one.

• Bank transfer and direct debit, including SEPA in Europe and ACH in the US. Cheaper, slower, and reversible for a period.


• Real-time payment schemes such as Pix in Brazil, which are fast, cheap and irreversible.


• Wallets such as Apple Pay and Google Pay, which sit on top of cards but raise mobile conversion substantially by removing form entry.


• Buy now pay later, which shifts credit risk to the provider at a higher fee.

The relevant point is that irreversibility differs. Card payments can be disputed for months. A real-time bank transfer generally cannot. That difference matters more than the fee for some businesses.

Refunds and disputes are different mechanisms

A refund is a new transaction sending money back. It takes days to appear on the customer's statement, which generates support tickets from customers who expect it to be instant.

A chargeback is the cardholder disputing through their bank. The funds are pulled back immediately, you pay a fee, and you may contest with evidence. The process runs on the network's timeline, not yours, and can take months.

The chargeback ratio matters beyond the individual losses. Exceed the network thresholds and you enter a monitoring program with fines, and eventually lose the ability to accept cards.

What this means practically

• A charge on the customer's statement that you cannot see is usually an authorisation that was never captured, and it will drop off.


• A decline that succeeds on retry was almost certainly an issuer risk rule, not a balance problem.


• Money arriving later than expected is settlement plus your payout schedule, not an error.


• A rising decline rate is worth investigating at the issuer and country level before assuming it is your checkout.

For the cost side of all this, payment processing for creators covers what you actually pay, and cross-border payments covers the part that gets expensive once your customers are international.