Coinflow Partners with Highnote to Power Stablecoin Payments
Most people think a payment is complete when the card is approved. It is not.
Authorization is a hold. Settlement is the money. Between those two events, a multi-step process moves funds across 4 or 5 parties, through clearing cycles, and into a merchant account that may not reflect the transaction for 1 to 2 business days.
Yet most payment dashboards show a single status: approved.
The payment settlement process is the infrastructure underneath that status. Understanding it is the difference between knowing a payment happened and knowing where the money is.
Follow the money.
Settlement is when money actually moves. Not when the card is approved. Not when the capture request clears. When funds are transferred from the issuing bank to the merchant's account.
Authorization freezes funds. The capture confirms that the merchant intends to collect. Clearing moves the transaction data through the network. Settlement moves the money.
Most systems track authorization and settlement separately. Few connect them on the same ledger. That gap is where reconciliation starts.
Settlement marks the end of the financial record.
The lifecycle has 4 stages. Each one involves different parties and different time windows.
Authorization is real-time approval. The merchant sends a request to the card network via the acquirer, which routes it to the issuer. The issuer checks available funds and returns an approval or decline within seconds. No money moves. A hold is placed on the cardholder's account.
Capture is the merchant's instruction to collect the amount. For most retail transactions, capture happens immediately at authorization. For hospitality, automotive, and travel merchants, they are separate events: the merchant captures the final amount after service delivery. An authorized transaction that is never captured never settles.
Clearing is the exchange of transaction records between the acquiring and issuing banks via the card network. The acquirer submits records in batches, typically daily. The issuer debits the cardholder's account. No money moves in clearing. It is a data exchange that sets up the fund transfer.
Settlement is the actual fund transfer. The card network calculates net positions, funds move between issuing and acquiring banks, and the acquirer deposits the net amount (minus interchange and fees) into the merchant's account. Each step is discrete. Each step can fail independently.
Customer initiates payment. The cardholder presents a card at the point of sale, online checkout, or in-app.
Authorization request. The merchant's system routes the transaction through the acquirer and card network to the issuer. Approval or decline returns in real time. A hold is placed on available funds.
Capture. The merchant confirms the final transaction amount. Immediate for most retail. Delayed for hospitality and travel merchants who finalize the amount after service.
Clearing. The acquirer batches captured transactions and submits them to the card network. The network routes each record to the corresponding issuer. The issuer debits the cardholder's account.
Settlement. The network calculates net positions across all issuers and acquirers. Funds flow to acquirers. The acquirer deposits the settled amount into the merchant's account, minus interchange and processing costs.
When authorization, clearing, and settlement share the same ledger, the transaction and its record move. When they run on separate systems, finance reconstructs what happened after the fact.
Five parties participate in every card settlement. Most failures do not happen within a system. They happen at the handoff between them.
Cardholder. The customer whose account is debited at settlement. The issuer holds those funds until the clearing cycle moves them.
Merchant. The business receives payment. Initiates capture. Receives settled funds in the acquiring account. Settlement reporting quality determines reconciliation accuracy.
Issuer and acquirer are the two banks in the chain. The issuer holds cardholder funds and debits at clearing. The acquirer holds the merchant's account and receives net settlement. When a single platform owns both roles, settlement data is visible across the entire chain without handoffs.
Card network. Routes authorization requests, facilitates clearing, calculates net settlement positions, and enforces interchange rules.
Payment processor. Connects merchants to the acquiring bank. Handles authorization routing, capture processing, and settlement reporting.
Delays and reconciliation failures almost always surface at the handoffs between these parties, not inside any one of them.
Standard card settlement typically runs on a T+1 or T+2 cycle. Timing varies for 4 reasons.
Batch timing. Most acquirers run settlement batches once per day. Transactions captured after the daily cutoff roll into the next batch, adding a full day to funding time.
Card type. Debit transactions typically settle faster than credit. Commercial and international cards may have longer processing times due to network routing.
Merchant category. High-risk categories (travel, gaming, certain e-commerce) often carry settlement holds while processors verify transactions against chargeback risk.
Disputes and holds. A chargeback freezes associated funds in a dispute hold that can last weeks. Elevated chargeback rates can trigger rolling reserve requirements.
Real-time settlement is available on certain rails (RTP, FedNow, some debit networks) but is not yet standard across all card transaction types.
When a clearing batch runs, the card network does not move individual transaction amounts. It calculates a net settlement position for each acquirer: the total funds owed to all issuers minus the total funds owed by all issuers, for all transactions in that batch. That net amount is what moves.
From there, how modern money moves through the acquirer to the merchant depends on the funding arrangement. The acquirer deducts interchange (paid to the issuer), network fees, and processing fees, then deposits the net amount.
Interchange is not a flat fee. It varies by card type, merchant category code, and transaction method. The merchant sees a deposit. The ledger behind that deposit reflects dozens of individual line items.
The standard reconciliation workflow: the processor generates a daily settlement report, the acquirer generates a funding report, and the finance team matches both against the general ledger. Discrepancies arise from partial captures, same-day refunds, in-process disputes, and interchange adjustments applied after original settlement.
Unified payments architecture changes this workflow materially. When issuing, acquiring, and settlement data share the same ledger, the transaction record and the settlement record are created together. Finance reads what the system recorded. It does not reconstruct what happened.
When settlement data is fragmented across processor reports and bank statements, reconciliation is a daily archaeology project. When it runs on a unified ledger, reconciliation is a report.
Settlement failures are predictable failure modes, not rare events.
Settlement delays occur when batch cutoffs are missed, when processors flag transactions for manual review, or when elevated chargeback rates trigger holds. Each delay creates a float gap between expected and actual funding.
Failed settlements result from acquirer technical failures, network outages, or issuer-side exceptions. HighRadius research on payment operations identifies failed batch submissions as a leading cause of unplanned reconciliation work at high transaction volumes.
Disputes and chargebacks interrupt the settlement record after the fact. A chargeback reverses a completed settlement and requires a new reconciliation entry. Without real-time dispute tracking, the first sign is often an unexplained debit in the bank statement.
Reconciliation gaps emerge when authorization, capture, and settlement data reside in different systems and are reported on different schedules. Each gap is a manual research task.
The problem in most settlement challenges is not the payment rails. It is the absence of a shared data model.
How do I know when a payment has fully settled versus when it's just been authorized?
Look for a settlement or funding date, separate from the authorization timestamp, in your processor reporting. Authorization places a hold; settlement moves funds. If your system shows only one timestamp per transaction, you are reading authorization data, not settlement data. Reconciliation built on authorization data will regularly produce discrepancies against bank deposits.
Why does settlement timing vary across payment methods?
Settlement timing depends on the clearing infrastructure behind each method. Standard card transactions batch-settle, typically T+1 to T+2. Debit transactions routed through PIN networks can settle the same day. ACH settles in 1 to 3 business days. Real-time rails (RTP, FedNow) settle in seconds but are not universally available for all merchant types.
Why does the authorization amount sometimes differ from the final settlement amount?
Hotels and rental companies authorize an estimate and capture the final amount at checkout. Restaurants authorize the base charge and settle after the tip is added. Partial refunds and cross-border FX adjustments also create differences. Authorization data alone is insufficient for financial reporting because it does not reflect these adjustments.
Author
Highnote Team