Payment processing is often described in simple terms, charging a card, receiving funds, and reconciling transactions. In practice, modern payment systems are far more complex, operating as distributed financial networks that coordinate financial institutions, card networks, and technology platforms in real time and across delayed settlement cycles. These systems underpin over 250 billion transactions annually, moving an estimated $5–7 trillion every day across global payment networks.
Most explanations focus on surface-level flows or individual components such as gateways or processors. What is often missing is a clear, end-to-end understanding of how data, money, and risk move through the system, and how those movements are shaped by infrastructure design and business model decisions. This directly impacts cost, risk, and scalability.
This guide provides a technical, system-level view of payment architecture, covering transaction flows, infrastructure layers, and business models such as traditional merchant accounts and Payment Facilitators.
What is a Payment System
A payment system is best understood as a coordinated set of services that enable the transfer of value between parties under defined rules and constraints. Rather than being a single platform or provider, it is an ecosystem that combines financial institutions, networks, and technology layers into a unified transaction flow.
At a structural level, every payment system operates across three distinct layers that function on different timelines and serve different purposes. Understanding these layers is essential for interpreting how transactions behave in practice, particularly when reconciling authorization results with actual cash movement.
- Data layer handles real-time communication, including authorization and routing
- Money layer governs clearing, settlement, and funding between institutions
- Risk layer manages fraud detection, chargebacks, and compliance obligations
These layers are tightly coupled but not synchronized. As a result, a transaction can be approved instantly at the data layer while still being subject to reversal or delay at the money and risk layers.
The Payment Ecosystem (Who Does What)
Every card transaction relies on a network of specialized participants, each responsible for a specific function within the overall system. These roles are defined by both technical capabilities and regulatory obligations, and they operate under standardized rules set by global card networks.
While the transaction appears simple from the perspective of the customer and merchant, it actually involves coordinated communication between multiple independent entities. Each participant plays a role in validating, routing, funding, or securing the transaction.
Core participants include:
- Cardholder – initiates the transaction
- Merchant – accepts payment and delivers goods or services
- Gateway – securely captures and transmits payment data
- Processor – orchestrates routing and communication between systems
- Acquiring Bank (Acquirer) – provides merchant accounts and receives funds
- Card Networks such as Visa and Mastercard – define rules and route transactions
- Issuing Bank (Issuer) – evaluates and approves or declines transactions
Although these roles are often grouped together in simplified explanations, it is important to distinguish between them. For example, a gateway handles data transmission, while a processor manages routing logic, and an acquirer manages financial settlement. Confusing these roles can lead to misunderstandings about pricing, responsibility, and system behavior.
Authorization Flow (Real-Time Data Movement)
Authorization is the first critical stage of a transaction, where the system determines whether a payment should be approved or declined. This process is entirely data-driven and occurs in real time, typically within one to two seconds, despite involving multiple institutions and systems.
The purpose of authorization is to validate that the card is legitimate, the account has sufficient funds or credit, and the transaction does not trigger fraud controls. Importantly, authorization does not move money. It only establishes whether a transaction is allowed to proceed.
The flow proceeds through a structured sequence:
- Card data is captured at the point of interaction
- Data is encrypted and tokenized by the gateway
- Transaction is routed through the processor to the acquirer
- The card network forwards the request to the issuing bank
- The issuer evaluates risk and available funds
- An approval or decline response is returned
Because this process is standardized across networks, it enables global interoperability across millions of merchants and financial institutions.
Payment Flow Responsibility Table
| Stage | Gateway | Processor | Acquirer | Network | Issuer |
|---|---|---|---|---|---|
| Data capture | Yes | No | No | No | No |
| Encryption/tokenize | Yes | Partial | No | No | No |
| Routing | Partial | Yes | Yes | Yes | No |
| Authorization | No | Yes | Yes | Yes | Yes (decision) |
| Fraud checks | Partial | Partial | Partial | Network rules | Primary |
| Settlement | No | Partial | Yes | Yes | Yes |
| Fund transfer | No | No | Yes | Yes | Yes |
Settlement & Funding (Where Money Moves)
Once a transaction is authorized, it enters a separate phase where funds are actually transferred between institutions. This phase operates on a delayed timeline and is governed by clearing and settlement processes defined by card networks and banking systems.
Settlement typically occurs in batches rather than in real time. Merchants submit authorized transactions for capture, which are then aggregated and processed through clearing systems before funds are transferred from issuing banks to acquiring banks.
This distinction between authorization and settlement is one of the most important concepts in payments. It explains why a transaction can appear complete to a customer while funds are still in transit within the banking system.
Payment Timeline (Typical Card Transaction)
| Step | Timeline | Description |
|---|---|---|
| Authorization | Seconds | Approval/decline decision |
| Capture | Same day | Merchant submits batch |
| Clearing | 1–2 days | Network processing |
| Settlement | 1–3 days | Funds transferred |
| Funding | 1–3 days | Merchant receives funds |
Fees & Economics (How Money Is Distributed)
Every transaction involves a distribution of fees across the participants that enable the system to function. These fees reflect both the operational costs and the risk taken on by each party in the transaction lifecycle.
From the merchant’s perspective, fees are often presented as a single blended rate. In reality, they are composed of multiple layers that vary depending on card type, transaction method, and geography.
The largest component is typically interchange, which compensates the issuing bank for extending credit and taking on risk. Additional fees are paid to networks for routing and rule enforcement, and to processors and gateways for providing technical infrastructure.
Payment Fee Breakdown by Component
| Fee Type | Paid To | Typical Range | What It Covers |
|---|---|---|---|
| Interchange | Issuing bank | ~1.5% – 2.5% | Credit risk, rewards, fraud |
| Network fees | Card networks | ~0.1% – 0.3% | Routing, infrastructure |
| Processor fees | Processor / ISO | ~0.1% – 0.5% | Transaction handling |
| Gateway fees | Gateway provider | Fixed or % | Data transmission |
Payment system economics are influenced by interchange frameworks and network rules, as well as national payment system infrastructure governed by institutions such as the Federal Reserve in the United States and Payments Canada.
Risk, Fraud, and Chargebacks
While authorization determines whether a transaction is approved in real time, it does not eliminate risk. Payment systems are designed to allow transactions to proceed quickly, but risk is managed continuously after authorization through fraud monitoring, dispute processes, and network rules.
Fraud detection occurs across multiple layers, including gateway-level signals, processor-level rules, and issuer-level decisioning. However, even approved transactions can later be reversed through the chargeback process, which is governed by card network rules and enforced through issuing and acquiring banks.
Chargebacks typically occur when a cardholder disputes a transaction due to fraud, non-delivery, or dissatisfaction. The dispute process flows back through the system, often reversing funds and requiring the merchant to provide evidence.
Payment Business Models and System Architecture
Traditional Payment Processing (ISO / Merchant Account Model)
In the traditional model, each merchant is issued a dedicated merchant account by an acquiring bank. The processor and gateway provide technical infrastructure, but the merchant relationship and underwriting are handled at the individual level.
This model emphasizes separation of responsibilities and structured risk management, with each merchant evaluated independently.
Characteristics:
- Individual merchant accounts
- Full underwriting before approval
- Risk distributed across participants
- Stable and predictable funding
Payment Facilitator (PayFac) Architecture
In the PayFac model, a platform acts as the primary merchant of record and onboards businesses as sub-merchants under its umbrella. This significantly simplifies onboarding and integration but centralizes operational and regulatory responsibility.
Instead of each merchant having a direct relationship with an acquiring bank, the PayFac maintains that relationship and manages onboarding, compliance, and risk internally.
Characteristics:
- Rapid onboarding (minutes to hours)
- Centralized compliance and risk
- Simplified integration for platforms
- Increased operational complexity behind the scenes
Comparison of Payment Models
While both models ultimately enable the same transaction flow, they differ significantly in how responsibilities and risks are distributed. These differences have direct implications for pricing, onboarding, and scalability.
Table: Payment Models Comparison
| Feature / Dimension | Traditional Merchant Account (ISO) | Payment Facilitator (PayFac) | Hybrid / Platform Model |
|---|---|---|---|
| Merchant account | Individual per merchant | Shared (sub-merchant) | Mixed |
| Onboarding time | Days to weeks | Minutes to hours | Varies |
| Underwriting | Full upfront | Light upfront + ongoing | Tiered |
| Risk ownership | Distributed (merchant + acquirer) | Centralized (PayFac) | Shared |
| Compliance burden | Shared | PayFac-heavy | Platform-heavy |
| PCI responsibility | Merchant + providers | Primarily PayFac | Shared |
| Pricing control | Processor / ISO driven | PayFac controlled | Platform controlled |
| Funding flow | Direct to merchant | Through PayFac | Configurable |
| Best for | SMBs, established businesses | SaaS, marketplaces | Vertical SaaS |
| Key tradeoff | Slower onboarding | Higher operational burden | Complexity |
Technology Implications of Each Model
From a technology perspective, the PayFac model requires significantly more infrastructure than traditional processing. While both models rely on gateways, processors, and bank integrations, PayFac platforms must build additional layers to manage sub-merchants and financial flows.
These include onboarding systems, identity verification, transaction monitoring, internal ledgering, and payout orchestration. As a result, PayFacs operate closer to full financial platforms than simple payment processors.
Technology Stack (Payments Infrastructure)
Modern payment systems are built as modular, API-driven architectures that enable integration across multiple channels, including in-person, online, and mobile environments. This flexibility is critical for supporting evolving payment methods and business models.
At a high level, the payment technology stack consists of layered components that handle user interaction, orchestration, secure data transmission, transaction routing, and financial settlement.
Key capabilities:
- Tokenization reduces exposure of card data
- APIs enable integration with SaaS platforms
- Webhooks provide real-time transaction updates
Compliance and Regulatory Layer
Payment systems operate within a highly regulated environment, where compliance requirements apply across all stages of the transaction lifecycle. These requirements are designed to protect consumers, prevent fraud, and ensure the integrity of financial systems.
Unlike other components, compliance is not isolated to a single layer. It spans data handling, merchant onboarding, transaction monitoring, and settlement processes.
Key frameworks include:
- PCI DSS from the PCI Security Standards Council
- KYC and KYB requirements for merchant onboarding
- AML regulations for monitoring financial activity
Payment systems operate under strict regulatory frameworks, including PCI DSS standards from the PCI Security Standards Council, as well as AML and KYC requirements enforced by regulators such as the Financial Crimes Enforcement Network (FinCEN) in the United States and the Office of the Superintendent of Financial Institutions (OSFI) in Canada.
Real-World Example
To understand how these components interact in practice, consider a simple transaction at a dental clinic in Canada. While the experience appears seamless to the customer, it triggers a complex sequence of interactions across the payment ecosystem.
When a card is tapped at a terminal, the transaction is immediately routed through the gateway and processor to the issuing bank for authorization. Within seconds, the issuer approves or declines the transaction, allowing the merchant to complete the interaction.
Later, the transaction is included in a batch for settlement, processed through clearing systems, and ultimately funded to the merchant’s account within one to three business days.
