Understanding the Payment Lifecycle: From Authorization to Settlement

Why understanding the payment lifecycle matters

Businesses often rely on a payment provider's status to determine whether a customer has paid.

That status is useful, but it does not necessarily describe the complete financial position of the transaction.

For example, a card payment may have been authorized but not yet captured. Another payment may have been captured but not yet settled. A settled transaction might still be awaiting inclusion in a payout to the business.

These distinctions matter when businesses need to answer questions such as:

• Has the customer's payment actually been collected?
• Can an authorized payment still fail or expire?
• Why does a transaction appear as successful but not yet appear in a bank statement?
• When should an invoice or order be marked as paid?
• What happens when a payment is refunded or disputed?

Understanding the payment lifecycle helps businesses interpret these situations correctly rather than treating every successful-looking transaction as the same financial event.

1. Payment initiation: The transaction begins

The payment lifecycle starts when a customer initiates a transaction.

Depending on the checkout process, this might involve entering card details, selecting a saved payment method, confirming a bank-based payment, or using a digital wallet.

The business or its payment integration sends the necessary transaction information to the payment provider.

This typically includes the amount, currency, merchant reference, and information needed to process the selected payment method.

At this stage, the payment may exist as an initiated or pending transaction even though the customer has not yet completed the process.

For example, the customer might be redirected to their bank to complete additional authentication.

If they abandon the process, the transaction may remain incomplete or eventually expire.

An initiated payment is not evidence that money has been successfully collected.

This is particularly important for businesses that create an order or invoice before requesting payment.

The billing record and the payment attempt may already exist, but the financial outcome is not yet known.

2. Authorization: The payment is approved

For card payments, authorization is the process through which the card issuer evaluates the transaction and decides whether to approve it.

The process typically involves checking the card's validity, available funds or credit, and relevant security and risk conditions.

Additional customer authentication may be required before authorization can succeed.

When a payment is authorized, the issuer generally reserves the approved amount against the customer's available balance or credit limit.

However, authorization does not necessarily mean that the merchant has collected the funds.

Consider a customer purchasing a €120 subscription.

The issuing bank approves the transaction and places an authorization hold for €120.

From the customer's perspective, the amount may appear as pending in their banking application.

The business has confirmation that the transaction was authorized, but the payment may still require capture.

What can happen after authorization?

Several outcomes are possible:

• The payment is captured successfully.
• The authorization is canceled.
• The authorization expires before capture.
• A capture attempt fails.
• Only part of the authorized amount is captured, where supported.

Authorization validity periods vary by card network, provider, payment method, and transaction circumstances.

Businesses using delayed or manual capture need to account for these limitations.

For systems that generate invoices or activate services based on payment events, the distinction between authorization and collection is particularly important.

See Stripe's authorization and capture documentation ↗ (opens in a new tab) for provider-specific validity windows.

3. Capture: The business requests the funds

Capture is the stage at which an authorized card payment is submitted for collection.

Many payment providers support automatic capture, where the capture process is initiated shortly after successful authorization.

Other integrations use manual capture, allowing the business to authorize a payment first and capture it later.

Manual capture can be useful in situations where the final amount or delivery conditions are not yet confirmed.

For example, an online retailer might authorize a payment when an order is placed and capture it when the goods are ready to ship.

A SaaS business, by contrast, may use automatic capture because access to a digital service is typically provided shortly after purchase.

Full and partial capture

Depending on the payment method and provider, a business may be able to capture the full authorized amount or only part of it.

Imagine an authorized payment of €200.

If the final amount to be collected is €160, the provider may support capturing €160 rather than the full €200.

What happens to the remaining authorization depends on the provider's rules and configuration.

A capture request can also fail or remain pending.

This is why a business should not assume that an authorization automatically results in a completed financial transaction.

4. Settlement: The payment is financially processed

After capture, the payment proceeds through the applicable clearing and settlement processes.

At a high level, settlement involves the financial transfer and accounting of funds between the institutions participating in the transaction.

The exact process depends on the payment method and the provider's acquiring and settlement arrangements.

For a card payment, this typically involves the card network, issuing bank, acquiring institution, and payment provider.

When a provider reports that a transaction is settled, it generally means the payment has reached the relevant settlement stage in that provider's processing model.

Settlement does not necessarily mean that the funds have already reached the business's bank account.

This distinction is important because providers may hold settled amounts in a merchant balance or combine them with other transactions before making a payout.

The business may therefore have hundreds of individually settled transactions but receive a single consolidated bank transfer.

Why settlement timing varies

Several factors can affect when a transaction settles:

• Payment method and card network processing rules.
• The payment provider's settlement model.
• Weekends, holidays, and banking schedules.
• Transaction currency and cross-border processing.
• Provider-specific processing delays or adjustments.

Businesses should consult their payment provider's documentation for the exact settlement rules applicable to their accounts.

For an example of how a provider distinguishes settlement from payout, see Adyen's payment lifecycle documentation ↗ (opens in a new tab).

5. Payout: Funds reach the business

A payout is the transfer of funds from the payment provider or acquiring arrangement to the merchant's designated bank account.

Depending on the provider, payouts may take place daily, weekly, or according to another schedule.

In some arrangements, funds may be transferred individually; in others, multiple transactions are aggregated into a single payout.

The amount transferred may also differ from the total value of the underlying customer payments.

For example:

Illustrative example; actual fee and payout arrangements vary by provider.

Here, €5,000 in settled customer payments contributes to a €4,700 bank payout.

The difference does not automatically indicate an error. It may reflect legitimate fees and adjustments.

Businesses need payout reports or equivalent financial records to understand how individual transactions contribute to the amount received.

This is one reason payment tracking and bank reconciliation are related but distinct activities.

6. Not every payment follows the same lifecycle

Authorization, capture, settlement, and payout describe a common card-payment model.

However, not every payment method uses these stages in exactly the same way.

Some bank-based payment methods rely on customer approval and bank transfer confirmation rather than a separate card-style authorization and capture process.

Other payment methods use asynchronous confirmation, meaning the business may not receive a definitive result immediately.

A payment can remain pending while the customer completes an action or while the provider processes the transaction.

Even among card payments, providers may present different status names or combine several processing stages into a simplified status.

For businesses integrating multiple payment providers, these differences can create operational challenges.

A status labeled "successful" in one system may not represent precisely the same processing milestone as a similarly named status in another.

This makes it important to understand the meaning of each provider's statuses rather than relying exclusively on their labels.

7. Payment failures, cancellations, and refunds

The payment lifecycle is not always a straightforward progression toward settlement.

Transactions can fail or change at several points.

Failed authorization

The issuer or payment service declines the initial transaction.

Possible reasons include insufficient available funds, incorrect payment information, authentication failure, or risk controls.

The business may allow the customer to retry using the same or a different payment method.

Canceled authorization

An authorization may be canceled before funds are captured.

This generally releases the reserved amount, although the timing of the release can depend on the issuing institution.

Failed capture

A payment that was authorized may still encounter problems during capture.

Businesses need to distinguish these cases from successful collections so that orders, subscriptions, and invoices are not updated incorrectly.

Refunds

After a payment has been captured, a refund may return some or all of the collected amount to the customer.

The refund becomes a separate financial event associated with the original transaction.

It may also affect later settlement reports or payouts.

Disputes and chargebacks

A customer may dispute a payment through their issuing bank or payment provider.

The resulting process can introduce additional events, adjustments, and fees.

These events can occur well after the original payment was considered successful.

For accurate financial records, businesses need to retain the relationship between the original payment and any subsequent refund, dispute, or adjustment.

8. How the payment lifecycle affects invoicing

Payment processing and invoicing are closely related, but they represent different parts of a business transaction.

An invoice documents a charge or the relevant commercial transaction according to applicable invoicing rules.

Payment records document attempts to collect funds and the resulting financial events.

The two need to remain consistent even when their timelines differ.

Consider a SaaS business that issues an invoice for a new subscription.

The customer initiates a card payment, which is authorized successfully.

If capture later fails, marking the invoice as fully paid based solely on the authorization could create an incorrect financial record.

Alternatively, a payment may be captured successfully while the associated bank payout happens several days later.

In that case, the invoice may appropriately be treated as paid under the business's accounting and legal rules even though the provider has not yet transferred the money to the company's bank account.

These examples demonstrate why invoice status, payment status, and payout status should not be treated as interchangeable.

The precise accounting and invoicing treatment depends on the applicable jurisdiction and business circumstances.

9. Building reliable payment tracking

Understanding the payment lifecycle is useful, but businesses also need systems capable of recording it accurately.

Several practices can make payment operations more reliable.

Preserve the transaction history

Instead of storing only the latest payment status, retain relevant events such as authorization, capture, failure, refund, and settlement.

The history helps explain how a transaction reached its current state.

Maintain consistent references

Connect external payment identifiers to internal invoices, orders, subscriptions, or customer accounts.

These references make it easier to investigate discrepancies and reconcile financial records.

Handle asynchronous updates

Some payment results arrive through provider notifications, commonly called webhooks, after the initial request has completed.

Systems should process these updates reliably, verify their authenticity, and handle duplicate or out-of-order notifications where relevant.

The customer returning to a success page should not be the only source of truth for payment completion.

Distinguish operational and financial states

Businesses should avoid reducing every transaction to a single "paid" or "unpaid" flag.

A payment can be captured but not settled, settled but not paid out, or subsequently refunded.

The required level of detail depends on the business, but those distinctions should remain available when needed.

Monitor exceptions

Failed captures, prolonged pending transactions, unexpected settlement differences, and unresolved refunds should be visible to the people responsible for payment operations.

This becomes increasingly important as transaction volumes grow.

Stripe's webhook guidance ↗ (opens in a new tab) explains signature verification, duplicate events, and event ordering.

Connecting the payment lifecycle with financial records

As businesses expand, payment processing often involves multiple providers, currencies, and systems.

Understanding the payment lifecycle helps explain what happens to each transaction, but maintaining consistent information across those systems remains a separate challenge.

A business may have reliable payment processing while still struggling to connect payment events with invoices and related financial records.

This is one of the areas A3BSS is being developed to address.

A3BSS is designed to help businesses connect invoicing and payment information while using their own accounts with payment providers. Its invoicing and payment capabilities are intended to be usable independently or together, depending on business needs.

Learn more about the planned capabilities on our Payments and Invoicing pages.

Final thoughts

A successful payment confirmation is only one part of the financial lifecycle of a transaction.

Authorization confirms approval, capture initiates collection, settlement processes the underlying financial transfer, and payout brings the relevant funds to the business.

These stages may happen close together, but they are not necessarily simultaneous.

Their exact sequence and terminology also depend on the payment method and provider.

For SaaS companies and online businesses, understanding these differences helps prevent incorrect payment statuses, improves customer support, and creates a stronger foundation for financial reporting.

The objective is not simply to know whether a payment succeeded. It is to understand what happened to the transaction, what still needs to happen, and how the resulting financial events relate to the business's records.