Payment Processing Systems: How Payments Move from Authorization to Settlement

Payment processing systems move payment instructions and financial value between customers, merchants and financial institutions. A transaction can pass through initiation, authorization, clearing, settlement and final account credit before it is complete. The exact sequence depends on the payment method, because card networks, bank transfers and instant-payment systems use different processing and settlement models.

A customer may experience the entire process as one tap.

The financial system sees several separate events.

A payment can be:

• successfully initiated;
• authorized;
• transmitted;
• cleared;
• settled;
• credited to the recipient;
• reconciled in the merchant’s records.

Those states should not be treated as synonyms.

The distinction explains many common payment questions: why an approved card transaction can remain pending, why a merchant may not receive money immediately, and why two payment methods that look equally fast at checkout can settle very differently.

What Is a Payment Processing System?

A payment processing system is the infrastructure, procedures and participating institutions used to receive payment instructions, validate them, transmit required data, calculate obligations and ultimately transfer or settle value.

The ECB describes a payment system more broadly as the instruments, banking procedures and interbank transfer arrangements that facilitate the circulation of money, or as a funds-transfer system.

Payment processing can therefore involve much more than a merchant’s checkout software.

Depending on the method, participating entities can include:

• customer;
• merchant;
• bank;
• payment processor;
• payment gateway;
• acquirer;
• card network;
• issuer;
• clearing system;
• settlement institution.

Not every payment contains all of these participants.

An instant bank transfer and a card purchase can have completely different architectures even though both appear as electronic payments to the user.

Payment Processing vs Payment Method

A payment method describes the way the payer chooses to pay.

Examples include:

• debit card;
• credit card;
• bank transfer;
• direct debit;
• e-money;
• instant account payment.

Our guide to payment methods compares these choices from the user’s perspective.

Payment processing describes what the financial infrastructure does after the payment instruction exists.

That gives us a useful distinction:

Payment method = what the user chooses

Payment processing = how the transaction is executed

A debit card is therefore a payment method.

Authorization, clearing and settlement are parts of processing that may occur behind that card transaction.

Information Gain: A Payment Is a State Machine, Not One Event

The most useful way to understand modern payment processing is to stop thinking about a payment as a binary condition:

paid / not paid

Instead, treat it as a sequence of states.

Different payment systems can combine, omit or accelerate these stages.

Instant-payment infrastructure may move rapidly from instruction to final funds availability.

Traditional card processing separates authorization from later clearing and settlement.

This state-based model is much more useful for troubleshooting than simply asking whether the payment is “complete.”

Stage 1: Payment Initiation

Every payment begins with an instruction.

The instruction can originate from:

• card terminal;
• e-commerce checkout;
• banking application;
• QR code;
• direct debit mandate;
• recurring payment arrangement;
• another authorized payment channel.

Initiation describes the customer’s request.

It does not prove that enough money or credit is available.

The system still needs to determine whether the transaction can proceed.

Stage 2: Authentication

Authentication attempts to establish that the person or device initiating the payment is permitted to do so.

Depending on the payment method, controls can include:

• PIN;
• password;
• biometric verification;
• cryptographic card data;
• one-time authentication;
• trusted-device checks.

Authentication answers a specific question:

Is the user or credential legitimate?

It does not necessarily answer:

Is the recipient correct?

or:

Should this transaction be approved financially?

Those are separate controls.

Stage 3: Authorization

Authorization determines whether the payment can proceed under the rules of the payment product.

For a card transaction, the issuer may evaluate factors including:

• account or credit status;
• available balance or limit;
• card status;
• fraud indicators;
• transaction details.

An approved authorization can allow the merchant to proceed with the purchase.

But approval does not necessarily mean the merchant has already received final funds.

This distinction is crucial:

Authorization is permission to proceed. Settlement is the financial completion of obligations between participants.

Information Gain: “Approved” Does Not Mean “Settled”

Imagine a customer makes a card purchase at noon.

The terminal shows:

Approved

The customer leaves with the goods.

From the customer’s perspective, payment appears complete.

From the payment system’s perspective, later stages can remain.

The transaction information may still need to be:

• submitted for clearing;
• matched with other transactions;
• included in settlement positions;
• funded to the appropriate participant;
• reconciled by the merchant.

That is why a card payment can appear as pending before becoming fully posted.

The authorization event and settlement event solve different problems.

Stage 4: Clearing

Clearing is the process that occurs before settlement to transmit, reconcile and confirm payment instructions and, where appropriate, calculate positions that participants need to settle.

The ECB glossary specifically separates clearing from settlement and notes that clearing can include transmitting and reconciling orders, netting them and establishing final settlement positions.

For a group of payments, a system may not need every institution to settle every transaction individually.

Obligations can sometimes be calculated on a net basis.

For example, instead of:

Bank A pays Bank B $100

then:

Bank B pays Bank A $80

a suitable net settlement structure might leave only a net obligation of:

Bank A pays Bank B $20

The exact mechanics depend on the payment system.

Stage 5: Settlement

Settlement is the stage at which participating institutions meet their financial obligations through the transfer of funds or other accepted settlement assets.

The ECB defines settlement as completion of processing such that participants meet their obligations through transfer of funds or securities.

This is a much more precise concept than simply saying that a payment was “processed.”

Settlement answers:

Has value between the participating financial institutions actually been discharged according to the system’s rules?

Gross vs Net Settlement

Payment systems can settle obligations in different ways.

Gross Settlement

Each payment or obligation can be settled individually.

Real-time gross settlement systems are particularly important for high-value payments.

Net Settlement

Multiple obligations can be offset before participants settle the resulting net positions.

Netting can reduce the total liquidity needed to settle large numbers of transactions.

Neither model is universally better.

The appropriate structure depends on:

• payment value;
• transaction volume;
• urgency;
• liquidity;
• risk;
• system design.

Stage 6: Funds Availability

Settlement between institutions does not always mean the end user’s balance becomes available at the exact same instant.

A receiving provider can still need to:

• post the transaction;
• apply account rules;
• complete internal controls;
• update customer-facing systems.

This distinction appeared repeatedly in our articles about bank and international payments.

The most useful end-user metric is therefore:

When does the recipient get usable money?

—not merely:

When was the payment message sent?

Stage 7: Reconciliation

Payment processing does not end when money arrives.

Merchants and financial institutions need to match external payment records with their own internal records.

Reconciliation may compare:

• order number;
• payment amount;
• transaction identifier;
• fee;
• refund;
• chargeback;
• settlement batch;
• final bank deposit.

A merchant can receive the correct total amount while still having poor financial operations if individual transactions cannot be reliably matched to orders.

Reconciliation converts money movement into usable accounting information.

Card Payment Processing: Who Is Involved?

Card processing commonly contains several specialized roles.

Cardholder

The customer using the card or corresponding digital credential.

Merchant

The business accepting the payment.

Payment Gateway

A gateway commonly provides a technical connection between the checkout environment and payment-processing infrastructure, particularly in e-commerce.

The exact product design varies by provider, so a gateway should not automatically be treated as the entity that settles the transaction.

Processor

A processor can provide technical services for transmitting and processing payment data on behalf of other participants.

Acquirer

The acquiring institution or provider serves the merchant side of the card-payment relationship.

Card Network

The card network provides scheme rules and connectivity that allow participating institutions to exchange card transactions.

Issuer

The issuer provides the customer’s card account or payment credential and typically participates in the authorization decision.

PCI DSS recognizes the breadth of this ecosystem: its payment-data security framework applies to relevant merchants, processors, acquirers, issuers and service providers that store, process or transmit cardholder data or can affect the security of the cardholder-data environment.

A Simplified Card Payment Flow

A typical card purchase can be represented as:

customer → merchant → processing/acquiring infrastructure → card network → issuer

Authorization information then returns through the chain.

Later, clearing and settlement processes determine the financial obligations between the relevant participants.

The merchant ultimately receives funds according to its acquiring and settlement arrangement.

This simplified model deliberately separates the customer’s checkout event from the financial lifecycle that follows.

Payment Gateway vs Payment Processor

These terms are frequently used as though they mean the same thing.

They can describe different functions.

A gateway generally focuses on securely transmitting payment information from a checkout environment toward processing infrastructure.

A processor performs transaction-processing functions and can connect financial participants or systems.

A single commercial provider may offer both functions.

That is why product branding alone is a poor way to classify payment infrastructure.

The better question is:

What function does this component actually perform?

Processor vs Acquirer

A processor and acquirer can also be different entities.

The acquirer has the merchant-side financial relationship within the relevant payment arrangement.

A processor can provide technology or operational processing for an acquirer, issuer or another payment participant.

In highly integrated business models, one organization may perform several roles.

The architecture should therefore be mapped by function, not just company name.

Payment Processing for Bank Transfers

Account-to-account payments follow a different model from cards.

A typical bank transfer might involve:

payer → payer bank → clearing/payment system → recipient bank → recipient

Depending on the rail, the system can use:

• batch clearing;
• same-day settlement;
• instant settlement;
• real-time gross settlement.

Our guide to electronic funds transfers explains how broad electronic-transfer terminology relates to specific payment rails.

This is why the phrase payment processor is most familiar in card and merchant payments but should not be forced onto every bank-transfer architecture.

Instant Payment Processing

Instant-payment systems reduce the separation between payment initiation and funds availability.

The Federal Reserve’s FedNow Service, for example, allows participating financial institutions to provide payments in real time around the clock, with recipients obtaining immediate access to funds.

That changes the processing model.

There may be little room for long batch cycles between authorization and customer availability.

Speed, however, creates another requirement:

fraud and recipient checks must occur earlier because there is less time to react after settlement.

Information Gain: Payment Architecture Determines Where Friction Appears

Every architecture moves friction somewhere.

A slower system may provide more time for:

• batching;
• netting;
• review.

A real-time system reduces waiting but increases the need for:

• pre-execution controls;
• liquidity readiness;
• continuous availability.

A card system can provide rapid merchant authorization while separating settlement until later.

No architecture eliminates processing tradeoffs.

It decides where those tradeoffs are managed.

How Large Are Modern Payment Systems?

Payment processing infrastructure operates at extraordinary scale.

The euro area recorded 83.5 billion non-cash payment transactions during the second half of 2025, with a total value of €117.8 trillion. Card payments represented 57% of transaction count, while credit transfers represented 21%.

The underlying retail payment systems are also highly concentrated.

During that same six-month period, 36 euro-area retail payment systems processed about 60.1 billion transactions worth €27.9 trillion. The three largest systems handled 67% of transaction volume and 63% of value.

Those figures demonstrate why resilience in payment infrastructure matters.

A failure in a major system can affect a very large number of transactions.

Information Gain: Payment Processing Has Strong Economies of Scale

Federal Reserve data provide an unusually useful view into debit-card processing economics.

For covered U.S. debit-card issuers, average authorization, clearing and settlement cost was approximately $0.041 per transaction in 2023, excluding issuer fraud losses.

Issuer scale changed that number dramatically.

The Federal Reserve found average ACS costs of:

• $0.036 per transaction for high-volume issuers;
• $0.121 for mid-volume issuers;
• approximately $1.088 for low-volume issuers.

Low-volume issuers therefore averaged roughly 30 times the per-transaction ACS cost of high-volume issuers in that dataset.

This provides a major Information Gain insight:

Payment processing is not only a technology problem. It is also a scale-economics problem.

Where Processing Costs Come From

Federal Reserve data also break debit issuer authorization, clearing and settlement costs into several categories.

In 2023, approximately:

• 45.2% came from in-house costs;
• 29.6% came from third-party processing fees;
• the remaining share mainly reflected network fees.

The composition varied substantially by transaction and issuer category.

That variation explains why two financial institutions can use broadly similar payment networks while having very different unit economics.

The network is only one cost layer.

Internal operations and external processors also matter.

Processing Cost Is Not the Same as Merchant Fee

A merchant may pay a percentage or fixed charge for accepting a transaction.

That retail/commercial fee should not be confused with one participant’s underlying technical processing cost.

Several components can exist inside the broader economics of a payment:

• processing;
• network fees;
• acquiring costs;
• fraud losses;
• fraud prevention;
• merchant services;
• interchange where applicable.

A visible merchant fee bundles commercial and infrastructure relationships that cannot be reduced to one network-processing number.

Why Payment Processing Can Fail

A payment can fail at several different states.

Authorization Decline

The transaction never receives permission to proceed.

Possible reasons include:

• insufficient available funds or credit;
• invalid credentials;
• account restriction;
• fraud control.

Technical Transmission Failure

The payment request cannot be delivered correctly between systems.

Clearing Exception

Transaction information does not reconcile or cannot enter the expected clearing flow.

Settlement Failure or Delay

A participant cannot complete the expected settlement obligation or processing is interrupted.

The ECB defines settlement failure specifically as a participant’s inability to meet its settlement obligations.

Posting Delay

The recipient-side institution has received the payment but customer availability is delayed.

Each failure needs a different investigation.

Failure Case: Retrying a Payment Without Knowing Its Status

A customer submits an online payment.

The website freezes.

No confirmation appears.

The user immediately submits the payment again.

The first transaction had actually reached the processing system even though the confirmation screen failed.

Result:

two valid transactions

The payment processor did not necessarily duplicate the charge.

The user or merchant retried an instruction without knowing the state of the first transaction.

A robust payment workflow should distinguish:

failed request

from:

unknown request status

before attempting another payment.

Failure Case: Merchant Treats Authorization as Revenue

A merchant sees a payment authorization and immediately records the transaction as fully settled cash.

Later, the transaction is not captured or settled correctly.

The order system and financial records now disagree.

The operational failure comes from treating:

approved payment

as:

completed cash settlement

Reconciliation should verify the actual financial outcome rather than relying only on the checkout result.

Failure Case: Payment Works but Records Do Not Match

Suppose 5,000 customer payments settle correctly.

The merchant’s order system loses reliable transaction identifiers for 1% of the orders.

The money exists.

Operationally, however, staff cannot identify which payment belongs to which customer order.

Support tickets and refund errors increase.

This demonstrates why reconciliation quality is part of payment processing quality.

A payment is not operationally complete until financial and business records can be connected reliably.

Payment Processing Security

Payment systems handle sensitive financial and account information.

Security controls can therefore focus on:

• access control;
• encryption;
• system configuration;
• monitoring;
• vulnerability management;
• authentication;
• protection of payment data.

PCI DSS v4.0.1 provides technical and operational requirements for environments that store, process or transmit payment-card account data.

Security scope depends on the payment architecture.

A merchant that reduces direct exposure to card data can reduce certain risks, but outsourcing payment functions does not automatically remove every security responsibility.

E-Commerce Payment Pages Need Special Attention

Modern checkout pages can contain:

• merchant scripts;
• analytics scripts;
• third-party services;
• payment components.

A malicious or compromised script can potentially interfere with payment-page security.

PCI SSC’s updated SAQ A framework, effective from March 31, 2025, requires eligible merchants to confirm that their site is not susceptible to script-based attacks that could affect e-commerce payment systems.

This is a useful reminder:

A hosted payment provider can secure the payment component while the surrounding merchant website remains part of the risk model.

Information Gain: Payment Security Has Three Surfaces

Payment security is easier to understand when divided into three attack surfaces.

Credential Surface

Can an attacker steal payment or login credentials?

Instruction Surface

Can transaction details be manipulated before submission?

Processing Surface

Can systems, integrations or scripts alter, duplicate or expose payment information during processing?

A company focusing only on card-number encryption may still have weaknesses in the instruction or integration layers.

Payment security should follow the complete transaction path.

Straight-Through Processing

Straight-through processing means completing payment processing with minimal manual intervention.

The ECB glossary describes STP as automated end-to-end processing that can include confirmation, matching, clearing and settlement.

Higher automation can reduce:

• manual data entry;
• delays;
• reconciliation work;
• processing errors.

Automation does not eliminate bad inputs.

A fully automated process can move an incorrect instruction very efficiently.

Validation remains essential.

Processing Speed vs Settlement Speed

These terms should not be treated as synonyms.

Processing speed can describe how quickly systems handle an instruction.

Settlement speed describes when participant obligations are financially discharged.

Funds availability describes when the recipient can actually use the money.

For an instant-payment system, these events may occur within seconds of one another.

For another method, they can be separated by hours or longer.

When comparing payment systems, always specify which speed is being measured.

Batch Processing vs Real-Time Processing

Batch Processing

Transactions are grouped and processed at scheduled intervals.

Benefits can include:

• efficient processing of large volumes;
• netting opportunities;
• predictable cycles.

The tradeoff is that individual payments may wait for the next processing window.

Real-Time Processing

Payments are handled continuously or immediately as valid instructions arrive.

Advantages include:

• faster recipient availability;
• continuous service;
• better support for urgent payments.

The model also requires stronger real-time operations, fraud controls and liquidity management.

Payment Processing and Electronic Funds Transfers

An electronic funds transfer is a broad class of electronically initiated account movements.

Payment processing systems are the operational and technical infrastructure that can execute such transactions.

For example:

online instruction → electronic funds transfer → payment rail → clearing/settlement

Our guide to electronic funds transfers explains that classification in more detail.

The two terms therefore describe different layers of the same transaction.

Payment Processing and Online Bank Transfers

An online bank transfer begins through a digital interface.

The bank then routes it through the appropriate payment infrastructure.

That infrastructure can determine:

• settlement speed;
• operating hours;
• transaction limit;
• recipient availability;
• finality.

The banking application’s Send button is therefore only the starting point.

The payment processing system determines much of what happens next.

Six Questions for Evaluating a Payment Processing System

1. Which Payment Methods Does It Support?

Card, bank transfer, instant payment, e-money or another method?

2. Which Role Does the Provider Perform?

Gateway, processor, acquirer, bank, network connection or several combined functions?

3. When Is a Payment Considered Final?

Authorization and final settlement should not be confused.

4. How Are Failures Represented?

A useful system distinguishes:

• decline;
• pending;
• timeout;
• reversed;
• settled;
• refunded.

5. How Is Transaction Data Reconciled?

Every payment should have stable identifiers that connect financial events with business records.

6. How Is Sensitive Data Protected?

Understand which systems store, process or transmit payment information.

What Makes a Good Payment Processing System?

A reliable processing environment should support more than successful transactions.

Useful characteristics include:

• clear transaction states;
• reliable routing;
• strong security;
• accurate reconciliation;
• transparent fees;
• resilient infrastructure;
• useful failure information;
• appropriate fraud controls;
• sufficient processing capacity.

The objective is not merely to maximize the percentage of payments labeled successful.

The system must produce correct financial outcomes that can be verified afterward.

Key Takeaways

• Payment processing systems move payment instructions and financial value between payment participants.
• Payment processing can involve initiation, authentication, authorization, clearing, settlement, funds availability and reconciliation.
• Authorization does not equal settlement.
• The ECB defines clearing as the transmission, reconciliation and possible netting of payment orders before settlement.
• Settlement completes participants’ financial obligations according to the relevant system.
• Card processing can involve merchants, gateways, processors, acquirers, networks and issuers.
• Instant-payment systems compress the time between payment instruction and funds availability; FedNow operates in real time around the clock for participating financial institutions.
• Euro-area retail payment systems processed around 60.1 billion transactions worth €27.9 trillion during the second half of 2025.
• The three largest euro-area retail systems handled 67% of volume during that period.
• Average U.S. covered debit-issuer authorization, clearing and settlement cost was approximately 4.1 cents per transaction in 2023, excluding issuer fraud losses.
• Low-volume issuers had roughly 30 times the average per-transaction ACS cost of high-volume issuers in the Federal Reserve dataset.
• Payment processing quality includes security, transaction-state clarity and reconciliation, not just checkout speed.

Frequently Asked Questions

What is a payment processing system?

A payment processing system is the infrastructure and procedures used to receive a payment instruction, validate and transmit information, determine obligations and ultimately settle value between payment participants. Different methods such as cards, bank transfers and instant payments use different processing architectures.

How does payment processing work?

A payment normally begins with initiation and authentication. The transaction may then be authorized, transmitted for clearing, settled between participating institutions and finally made available to the recipient. Business systems also reconcile the resulting financial transaction with the original order or obligation.

What is payment authorization?

Authorization is approval for a payment to proceed. In a card transaction, the issuer can evaluate the account, available balance or credit and transaction risk before approving or declining the request. Authorization does not itself prove that final settlement has occurred.

What is payment clearing?

Clearing occurs before settlement and can include transmitting, reconciling, confirming and netting payment instructions so the system can determine the positions participants need to settle.

What is payment settlement?

Settlement is completion of the financial obligation between payment-system participants through the transfer of funds or another accepted settlement asset.

What is the difference between a payment gateway and processor?

A payment gateway generally provides a technical route for sending checkout payment information toward processing infrastructure. A processor performs payment-processing functions between participating systems or financial providers. Commercial companies can combine both roles.

What is the difference between authorization and settlement?

Authorization determines whether a transaction can proceed. Settlement completes the resulting financial obligations between participating institutions. A card payment can therefore be authorized before final financial settlement occurs.

How long does payment processing take?

Timing depends on the payment rail. Card authorization can occur within seconds while settlement happens later. Batch account transfers follow scheduled processing, whereas instant-payment systems can provide near-real-time or real-time funds availability.

Why can a payment remain pending after being approved?

An approved authorization may be waiting for later capture, clearing, settlement or final account posting. The exact meaning of “pending” depends on the payment method and provider.

Are payment processing systems secure?

Payment processors and other participants use security controls to protect payment information and transaction integrity. PCI DSS v4.0.1 provides baseline security requirements for relevant entities that store, process or transmit payment-card account data.

Final Thoughts

A payment should not be understood as one electronic event.

The checkout button is merely the visible beginning.

Behind it, payment systems may need to determine:

who initiated the instruction → whether it is authorized → how transaction information is cleared → how institutions settle → when funds become usable → whether records reconcile correctly

Different payment methods arrange these stages differently.

A card system can provide fast authorization while settling later.

A batch transfer can collect many instructions before settlement.

An instant-payment rail can compress several stages into seconds.

This leads to the central lesson:

The quality of payment processing should be measured by the correctness of the complete financial lifecycle, not only by how quickly a customer sees “Payment Successful.”

A strong processing system moves money accurately, protects payment data, communicates transaction states clearly, survives operational problems and leaves both financial institutions and businesses with records they can reconcile.