You click “Pay Now.” A second or two later, a confirmation screen appears. From the customer’s perspective, that’s the whole story. Behind it, though, a chain of decisions and data exchanges has already been completed — involving multiple companies, two banks, a card network, and several layers of security checks.
Many people working in e-commerce or fintech are familiar with the general mechanics of online payments. What is often less visible is the full sequence behind them: what happens at each stage, who makes which decisions, and where the process is most likely to break down. That visibility matters more than it may seem because the same points in the payment flow that shape performance are often where revenue is lost unnoticed.
This is a walkthrough of a standard online payment transaction — from checkout to settlement — with an eye toward what each step means for businesses that process payments at scale.
The Step-by-Step Payment Flow
Step 1: The customer submits payment details
The process begins when a customer enters their card details — or selects a saved payment method — and confirms the purchase. At this point, the merchant’s checkout page sends that data to the payment gateway, which is the first piece of infrastructure the transaction touches on the merchant’s side.
The gateway’s job at this stage is to receive the payment data securely, encrypt it, and pass it forward. Reputable gateways tokenize the card number immediately, replacing it with a unique identifier that travels through the rest of the system in place of the real card data. This protects sensitive information from exposure at any downstream step.
Step 2: The gateway routes to the processor
Once the gateway has the transaction data, it sends it to a payment processor — the entity responsible for actually communicating with the card networks (Visa, Mastercard, Amex, and so on). The processor acts as the operational intermediary: it takes the formatted transaction request and submits it to the appropriate network for authorization.
In some setups, the gateway and processor are the same company. In others, they’re separate. The distinction matters for businesses thinking about provider flexibility, because changing one doesn’t always mean changing the other.
Step 3: The card network routes to the issuer
The card network receives the authorization request from the processor and routes it to the issuing bank — the bank that issued the customer’s card. The issuer is the entity that actually owns the decision: it checks whether the card is valid, whether sufficient funds or credit are available, and whether the transaction looks consistent with the cardholder’s normal behavior.
This is where most fraud detection occurs. The issuer’s systems evaluate the transaction against a set of risk rules and behavioral models. A transaction that passes these checks receives an authorization code. One that raises a flag gets declined — either with a specific reason code or a generic refusal.
Step 4: Authorization flows back
The issuer’s decision — approved or declined, and with what code — travels back through the same chain in reverse: issuer to card network, card network to processor, processor to gateway, gateway to merchant. The whole round trip, from the moment the customer clicks pay to the moment the merchant receives a result, typically takes between one and three seconds under normal conditions.
If the transaction is approved, the merchant can fulfill the order. The funds aren’t transferred yet — they’re reserved on the customer’s account, pending settlement.
Step 5: Capture and settlement
Authorization and settlement are two separate events. Authorization confirms that the funds are available and reserved. Settlement is when they actually move from the customer’s bank to the merchant’s acquiring bank.
Capture — the instruction to settle a previously authorized transaction — usually happens automatically at the end of the day or within a defined window after authorization. For some transaction types (hotel holds, subscription renewals, multi-item shipments), capture may be delayed intentionally. Settlement itself typically completes within one to two business days, though this varies by acquirer and card network.
Key Players in the Payment Ecosystem
Understanding who does what makes it easier to identify where your payment stack can be improved. The main participants in a standard online payment transaction are:
- The merchant: the business accepting the payment. Responsible for checkout UX, gateway selection, and how payment data is handled at the point of entry.
- The payment gateway: receives and encrypts card data, routes it to the processor, and returns results to the merchant. The gateway is also typically where 3DS authentication, tokenization, and initial fraud rules are managed.
- The payment processor: communicates with card networks on behalf of the acquiring bank. Handles the technical formatting and routing of authorization requests.
- The acquiring bank: the merchant’s bank. Sponsors the merchant’s ability to accept card payments and receives settled funds before passing them to the merchant.
- The card network: Visa, Mastercard, Amex, or others. Sets the rules, routes messages between acquirer and issuer, and manages interchange.
- The issuing bank: the customer’s bank. Makes the authorization decision and holds the customer’s funds until settlement.
In practice, many of these roles overlap or are bundled. Some processors double as acquirers. Some gateways include their own fraud scoring. Some platforms combine gateway, processor, and acquiring functions into a single integration. That bundling can simplify onboarding but often reduces flexibility as the business grows.
Where Things Can Go Wrong
Payment failures happen at every stage of this flow, and not all failures are created equal. The key distinction is between hard declines and soft declines.
Hard declines are final. The issuer has refused the transaction definitively — because the card is stolen, the account is closed, or the card number is invalid. No retry will change the outcome. The only path forward is for the customer to provide a different payment method.
Soft declines are conditional. The transaction failed, but the underlying reason may be temporary or recoverable. Common causes include:
- Insufficient funds at the time of the attempt, which may clear if retried later.
- A velocity limit triggered by multiple transactions in a short window.
- A risk flag from the issuer’s fraud model that doesn’t reflect actual fraud.
- A 3DS authentication step that wasn’t completed correctly.
- A routing issue that sent the transaction to an acquirer with poor performance for that card type.
False declines — legitimate transactions blocked by over-cautious fraud detection — are a significant and underreported category. The customer had a valid card, sufficient funds, and a genuine intent to buy. Something in the authorization chain flagged the transaction incorrectly and turned a sale into an abandoned cart.
Gateway timeouts, processor outages, and network connectivity issues add another layer of failure risk that’s entirely separate from card-level decisions. A transaction can fail not because the issuer declined it, but because the authorization request never reached the issuer in the first place.
How Businesses Optimize This Flow
Knowing the failure points tells you where optimization is possible. The most impactful levers are:
Smarter routing
The acquirer you route a transaction through affects both the likelihood of approval and the processing cost. Different acquirers have different approval rate histories for different card types, regions, and merchant categories. Static routing — all transactions through the same provider — leaves performance on the table. Dynamic routing, which selects the best-performing route per transaction based on real-time and historical data, consistently produces better authorization rates.
For businesses managing multiple providers, a white label payment gateway with built-in routing logic can handle this automatically — directing each transaction to the acquirer most likely to approve it, without requiring custom development for every routing rule.
Cascading for soft declines
When a transaction is declined by the primary acquirer, cascading logic can automatically retry it through a secondary provider. This recovers a portion of soft declines that static setups simply write off. The key is configuring cascade triggers carefully: retrying a hard decline wastes processing time and can flag the card with the network, while retrying a soft decline on the right provider frequently succeeds.
3DS optimization
3DS authentication is necessary for compliance and fraud liability in most markets, but blanket application of strong authentication to every transaction adds friction that reduces conversion. Risk-based 3DS, where low-risk transactions proceed with frictionless flow and higher-risk ones receive a challenge, reduces abandonment without weakening fraud protection.
Unified data and monitoring
Most payment failures are only visible in aggregate long after they’ve happened. Real-time monitoring of authorization rates, decline codes, and route performance makes it possible to catch degradation early. Platforms like Corefy centralize data across multiple acquirers and processors, giving businesses a single view of payment performance rather than disconnected dashboards from each provider.
Final Thoughts
An online payment transaction is simple from the outside and complicated from the inside. For customers, the experience should feel instant and frictionless. For businesses, the infrastructure behind that experience involves multiple interdependent systems, each of which can influence whether a transaction succeeds, fails, or costs more than it should.
The payment flow described here — gateway, processor, card network, issuer, acquiring bank, settlement — is the same for most card-based transactions. What varies is how well each step is configured, monitored, and optimized. That variation is what separates businesses with consistently high authorization rates from those losing revenue to failures they’ve never fully diagnosed.
Understanding the mechanics is the first step. The second is having infrastructure that can act on that understanding.
