From checkout to settlement: the full transaction journey and where bill_line fits in

Every online payment looks simple from the outside: a customer clicks “Pay”, and a few seconds later the purchase is confirmed. But behind that interaction lies a chain of decisions, authorisations and fund movements involving multiple parties. Each one of them has its own timeline, its own rules, and its own infrastructure. bill_line team is online and here to help you understand why this chain matters not as a technical exercise, but because the points where it breaks — or gets optimised. Short answer: this is where the economics of online commerce are decided. The long one from the perspective of tech solutions operator starts now.

The journey, step by step

It starts at checkout. The moment a customer submits their card details, the merchant’s gateway packages the transaction data and passes it to the acquirer — this is the financial institution that holds the merchant’s account and acts as its entry point into the card network.

The acquirer forwards the request to the relevant card framework, which routes it to the issuing bank. Then, the issuer checks available balance, fraud signals, card status, and authentication requirements. It responds with an auth code or declines payment. And the funny thing is you read this part longer then the actual process go: the full exchange takes under two seconds.

Authorisation is not the transfer of money. It is a hold on funds. The actual movement happens later, during clearing and settlement. Clearing begins at the end of the business day, when the acquirer compiles batched transactions and submits them to the card network. The network calculates all applicable fees: interchange paid to the issuer, scheme fees, and cross-border charges.

The actual transfer of funds is called settlement.It follows typically within one to three business days depending on the scheme and the merchant’s contractual terms. Only at this stage does money move from the issuer through to the merchant’s account, net of fees. You see a nearly simultaneous action, which become possible in recent years. Early e-commerce didn’t have that privilege, forged in IT progress.

Where things get expensive

Payment failures and cost inefficiencies concentrate at specific points in the chain.

Authorisation is where conversion is captured or lost. A declined transaction that didn’t gone through has many faces. It can happen due to suboptimal routing, missing retry logic, or avoidable authentication friction. But the most important thing here is the fact that revenue doesn’t recover.

Clearing is where fee structures crystallise: interchange rates vary by card type, geography, and merchant category code. Frameworks fees differ across networks and cross-border processing adds another layer. For merchants operating across markets, these decisions — most of which happen automatically and invisibly — can represent a meaningful share of revenue.

The infrastructure question

For most merchants, the default answer has been to find a PSP and go live. A PSP provides gateway, processing, acquiring, and settlement under one roof. The simplicity is real at early stages.

The trade-off is equally real. A single PSP means a single routing path, a single approval rate, a single fee schedule, and a single point of failure. As volumes grow and markets expand, that simplicity becomes a constraint. Adding a second provider means duplicating integrations, splitting reporting, and managing separate compliance obligations.

Payment orchestration is the architectural response. An orchestration platform is a technology layer connecting multiple PSPs through a single integration. It enables dynamic routing, fallback logic and centralised reporting without rebuilding infrastructure each time a provider changes.

This is where bill_line operated in tech level. We’re not replacing the PSPs. We stand above them be creating the solution where each transaction goes to the provider best positioned to approve it based on geo, card type, cost or real-time performance. This shifts the question from “which PSP do I use?” to “who manages my payment infrastructure, and how much control do I have over it?”

Where bill_line operates

Yes, over the last years we outgrow the PSP level. bill_line now is a technical operator of payment infrastructure. We’re positioned between a merchant’s product and the broader ecosystem of acquirers, gateways, and payment methods.

When a transaction enters the bill_line infrastructure at checkout, the platform handles routing decisions, retry logic, reconciliation, and reporting across connected providers — without the merchant managing those providers directly. Settlement visibility, approval rate monitoring, and cross-market compliance are handled at the infrastructure level.

We think you understand by now that the distinction from a PSP is architectural. A PSP is a regulated entity that processes payments and holds a direct relationship with card networks. An infrastructure operator at the orchestration layer is provider-agnostic. Our goal is to ensure the right provider handles each transaction under the right conditions.

For merchants running subscription models, operating across multiple markets, or scaling volume rapidly — this is where performance differences compound. In either direction.

According to Grand View Research, the global payment orchestration market is projected to reach $6.5 billion by 2030, up from $1.4 billion in 2023. The growth is structural: a payment stack spanning several markets and multiple acquiring relationships is not manageable as a direct integration problem.

The transaction lifecycle is the same regardless of who manages the infrastructure around it. What changes is visibility into each stage, the ability to act on anomalies before they affect revenue, and who carries the overhead of maintaining the stack as the business grows. That’s the problem bill_line is built to solve.