What actually happens inside an online card payment

When someone pays by card on a website, what looks like a single click is really three separate processes, with different actors and different timings. Mixing them up is the most common source of accounting surprises: an order marked as paid that never reaches the bank, or an amount held on the customer's card that matches no sale at all.

The three moments of a payment

1. Authorisation

Authorisation is a question: does this customer have funds, and does the issuing bank accept the transaction? The merchant sends the amount and the card details — normally already turned into a token, never the real number — and within seconds receives a yes or a no.

A "yes" is not money. It is a hold against the card's limit, and it expires: if nobody charges it, it is released on its own after a few days. That is why a customer can see a "pending" amount in their banking app with no final charge behind it.

2. Capture

Capture is the instruction to actually take the authorised money. It can be immediate (the norm for digital goods and subscriptions) or deferred, which is what many physical-goods shops do: they authorise when the order is confirmed and capture when it ships.

Capture can also be partial: if you authorised €120 and end up shipping half the order, you capture €60 and release the rest. What you cannot do is capture more than you authorised.

3. Settlement

Settlement is the real movement of money from the customer's bank to your account, grouped into batches and delayed by a number of working days that depends on your provider contract. This is where fees are deducted, and where yesterday's sale shows up in your bank as an aggregated deposit that matches no single order.

Who takes a cut along the way

The fee on your invoice does not go to one company. Broadly, it splits into three layers:

• Interchange fee: charged by the bank that issued the customer's card. In the European Economic Area it is capped by regulation for consumer cards, with different caps for debit and credit.
• Scheme fee: charged by the card networks for the use of their infrastructure.
• Provider margin: what the gateway or acquirer charges for the service, the support, and the risk.

When comparing providers, the headline rate matters less than the full breakdown, including surcharges for non-European cards, foreign currency, or failed transactions. The pricing page shows how a real fee breaks down on a specific amount.

Authentication: the step that can sink your conversion

In Europe, most online payments require strong customer authentication: on top of the card details, the bank asks for a second check, usually through its own app. That is why some transactions open an extra screen and others don't — exemptions exist for low amounts or trusted merchants, and it is the issuing bank, not the merchant, that decides whether to apply them.

That step is where most carts are lost, so measure it separately from the rest of the funnel: a customer who never reaches the payment is not the same as one who drops out on the bank's screen.

What goes wrong, and how it shows

• Authorised but not captured: the order reads as paid in your shop and the money never arrives. It is usually an integration bug, not a bank problem.
• Captured twice: badly handled retries after a timeout. The defence is idempotency: the same operation repeated must not charge twice.
• Bank figures that don't add up: expected if you compare order by order. Reconciliation is done against settlement, not against sales.

In short

A payment is not an event, it is a sequence. If your system distinguishes authorisation, capture, and settlement — and stores the state of each — you always know what was promised, what was charged, and what actually landed in the bank. That is the difference between closing the month in an afternoon and spending three days chasing discrepancies. You can see these states on sample data in the demo dashboard, and keep reading the rest of the articles on online payments.