When a customer clicks "Pay" on your checkout page, the confirmation appears in a second or two. Behind that second sits a chain of at least five parties, two network hops across card scheme rails, and a settlement cycle that usually takes days. Understanding that chain is not academic: it explains your fees, your failed transactions, your refund timing and most of your reconciliation headaches.
The cast: who does what
Online card payments involve a fairly fixed set of roles. Names differ by market, but the functions do not.
- Cardholder — the person paying, using a card issued by their bank.
- Merchant — you, selling goods or services online.
- Payment gateway — the technical layer that collects card data securely and speaks to the acquirer. Often bundled with a checkout UI, a hosted payment page or an SDK.
- Virtual POS — in many markets (Turkey and Cyprus included) this term refers to the acquiring bank's online card acceptance service: the merchant account plus the API/endpoint your gateway calls. Think of it as a physical card terminal without the plastic hardware.
- Acquirer — the bank or licensed institution holding your merchant account and taking on the settlement risk.
- Card scheme — Visa, Mastercard and others, providing the rails and the rules.
- Issuer — the cardholder's bank, which approves or declines and ultimately moves the money.
Step 1: Checkout and tokenization
The customer enters card details. If you are doing this responsibly, those details never touch your own servers in raw form. A hosted field, iframe or redirect keeps the card data inside the gateway's PCI DSS scope, and your system receives only a token — a reference you can use for refunds or repeat charges without storing a PAN.
This single design decision determines how heavy your PCI DSS compliance burden is. Merchants who post raw card numbers through their own backend inherit a much larger audit scope than those who never see them.
Step 2: 3-D Secure and strong customer authentication
Before authorization, most e-commerce transactions pass through 3-D Secure (branded as Visa Secure, Mastercard Identity Check, and required under PSD2's Strong Customer Authentication rules in Europe). The gateway sends transaction and device data to the issuer's access control server, which decides between:
- Frictionless flow — the issuer is confident from risk signals and approves authentication invisibly.
- Challenge flow — the cardholder is asked for a one-time password by SMS or push, biometric approval in the banking app, or another factor.
Two points that merchants often miss: the 3-D Secure OTP is generated and sent by the issuing bank, not by you, and successful 3DS authentication generally shifts liability for fraudulent chargebacks from merchant to issuer. That liability shift is the main commercial reason to keep 3DS on, even where local rules do not force it.
Step 3: Authorization
The gateway sends an authorization request through the acquirer to the scheme, and the scheme routes it to the issuer. The issuer checks the card status, available balance or credit line, velocity rules and fraud scoring, then answers with an approval code or a decline reason.
An approval is not a payment. It is a hold: the amount is reserved on the cardholder's account, typically for a limited window that varies by card type and issuer. Nothing has moved yet.
Step 4: Capture
Capture converts the hold into a claim for funds. Some merchants capture immediately at authorization (common for digital goods). Others use delayed capture — authorize at checkout, capture at shipment — which is standard in retail and avoids charging for items that turn out to be out of stock. If you never capture, the hold expires and the reservation drops off the customer's statement, often without any clear notification to them. This is a frequent source of "you charged me twice" support tickets.
Step 5: Clearing and settlement
At the end of the processing day, the acquirer batches captured transactions and submits them to the schemes. The schemes calculate what each issuer owes each acquirer, net of interchange, and the funds move between banks. Your acquirer then credits your merchant account, minus its fees, according to your settlement cycle — daily, weekly, or with a rolling reserve if you are in a higher-risk category.
Instalment plans, common in Turkey and some neighbouring markets, complicate this: the customer pays over months while the merchant may be paid earlier or later depending on the contract. Read the settlement terms, not just the headline commission.
Where the money goes: the fee stack
Your effective cost is rarely one number. It typically layers interchange (paid to the issuer, set by the schemes and varying by card type, region and channel), scheme fees, and the acquirer/gateway margin. Cross-border and commercial cards usually cost more than domestic consumer debit. Currency conversion adds another spread. Ask for the breakdown; blended pricing hides which of your traffic is expensive.
Refunds, reversals and chargebacks
These are three different things. A reversal (void) cancels an authorization before capture and is fast. A refund is a new transaction pushing money back after settlement, and it carries its own timeline of several business days on the issuer's side — which is why customers who "see nothing yet" are usually just waiting on their own bank. A chargeback is a dispute raised by the cardholder through the issuer; you defend it with evidence such as delivery proof, AVS/CVV results, 3DS authentication data and your terms of sale.
Practical hygiene for merchants
- Use idempotency keys on payment API calls so a retried request never creates a second charge.
- Treat the gateway's webhook — not the browser redirect — as the source of truth for order status; browsers close, webhooks retry.
- Log the acquirer reference and scheme transaction ID against every order for reconciliation and dispute defence.
- Keep a clear descriptor on the customer's statement; unrecognisable descriptors generate chargebacks.
- Notify customers at the moments that matter — order received, payment captured, refund issued — because silence generates support load. Many businesses run these transactional notifications over SMS alongside email, which is where a delivery-reported messaging channel such as UIPAPP's API fits in the wider stack.
Payments look instant because the authorization is. Everything after it — capture, clearing, settlement, disputes — runs on a slower, bank-to-bank timetable. Designing your order and support flows around that gap, rather than assuming money arrives with the approval code, saves a great deal of confusion on both sides of the checkout.