Airwallex logo
Airwallex logo

Transaction lifecycle

The progression of card transactions through authorization, clearing, and settlement stages.

Copy for LLMView as Markdown

The transaction lifecycle describes how a card payment progresses from initial authorization through to final settlement or reversal. Understanding this lifecycle is important when monitoring card activity and reconciling balances, as it helps you interpret transaction statuses and anticipate fund movements.

When a cardholder uses an Airwallex issued card to make a purchase, an authorization request is initiated by the merchant and reaches Airwallex via the card scheme (Visa). Airwallex performs checks to ensure that the authorization is genuine and meets any authorization controls you have configured. The transaction then progresses through various stages, with each stage represented by a specific transaction type and status.

Authorization scenarios

Card transactions follow one of two authorization scenarios, which determine how funds are reserved and settled.

Dual message

In a dual message (DM) scenario, the authorization and clearing processes are separate. The merchant's bank first initiates an authorization request to reserve funds for later clearing. The reserved funds appear in your reserve balance but are not yet deducted from your available balance.

Funds are only debited when the merchant sends a clearing request, typically after goods are shipped or services are rendered. If the clearing request is not initiated within the timeframe specified by the card scheme, the transaction expires and the reserved funds are released back to your available balance.

Single message

In a single message (SM) scenario, the authorization and clearing requests are combined into a single message. The requested amount is immediately debited from your available balance when the transaction is approved. This scenario is common for ATM withdrawals and certain point-of-sale transactions.

Transaction types

Each stage in the transaction lifecycle is represented by a specific transaction type. The following transaction types are supported on issued cards.

Transaction typeDescription
AUTHORIZATIONAn authorization request sent to the issuer to determine the validity of the card for making a payment. This request can either be approved or declined. In dual message scenarios, successful authorization reserves funds without debiting them.
CLEARINGA clearing request sent to the issuer to complete the settlement of a previously approved authorization request. The clearing request can settle a partial amount, the exact amount, or a greater amount (up to a certain percentage based on card scheme rules) of the previously approved authorization.
REVERSALA reversal request sent to the issuer to reverse a previously approved authorization request or a previously cleared transaction. The reversal request can reverse a partial amount or the exact amount of the previously approved or cleared amount.
REFUNDA refund request sent to the issuer to refund a previously cleared transaction. This can be either a merchant refund or a dispute refund. For merchant refunds, the request can sometimes be linked back to the original transaction. For dispute refunds, the request can always be linked back to the original transaction.
ORIGINAL_CREDITA credit request sent to the issuer to facilitate money movement from the merchant to the cardholder without a prior debit transaction.

Transaction statuses

Each transaction type can have different statuses depending on the authorization scenario and the current state of the transaction.

Transaction typeStatusDescription
AUTHORIZATIONPENDINGAuthorization approved and funds are reserved (dual message).
CLEAREDAuthorization has been cleared by a subsequent clearing request.
EXPIREDAuthorization was not cleared within the required timeframe and reserved funds have been released.
REVERSEDAuthorization has been reversed and reserved funds have been released.
FAILEDAuthorization was declined or failed after initial approval.
CLEARINGAPPROVEDClearing has been processed and funds have been debited (dual message and single message).
FAILEDClearing or single message transaction was declined.
REVERSALCLEAREDReversal of reserved funds has been processed (dual message).
APPROVEDReversal of debited funds has been processed (single message).
REFUNDAPPROVEDMerchant refund has been processed and funds have been credited.
FAILEDMerchant refund was declined.
CLEAREDDispute refund has been processed and funds have been credited.
ORIGINAL_CREDITAPPROVEDOriginal credit has been processed and funds have been credited.

The status transitions determine how funds move between your available balance and reserved balance. In dual message scenarios, funds move to reserve balance when an authorization is PENDING and move back to available balance when the authorization is CLEARED, EXPIRED, REVERSED, or FAILED. Clearing transactions then debit from your available balance.

Lifecycle identifier

Airwallex provides a unique identifier called lifecycle_id to group related transactions together. This identifier allows you to track all transaction events that belong to the same payment lifecycle, from initial authorization through to final settlement or reversal.

The lifecycle_id is available on the Get transactions API and Get authorization status API endpoints. All transactions with the same lifecycle_id represent different stages or events in the lifecycle of a single payment.

In the case of unmatched refunds (refunds that cannot be linked back to an original transaction), a new lifecycle_id is created as there is no previous transaction to associate with.

Transaction scenarios

The following scenarios illustrate common transaction lifecycle patterns and show how funds are affected at each stage.

Single authorization with single clearing (dual message)

This is the most common dual message scenario where an authorization is approved and then fully cleared.

StageTransaction IDLifecycle IDTypeTransaction statusImpact on fundsAmount
Authorization received and approved1AAUTHORIZATIONPENDINGFunds reservedReserve $100
Clearing received and processed1AAUTHORIZATIONCLEAREDFunds releasedRelease $100
2ACLEARINGAPPROVEDFunds debitedDebit $100

Single authorization with clearing (single message)

In a single message scenario, authorization and clearing occur simultaneously.

StageTransaction IDLifecycle IDTypeTransaction statusImpact on fundsAmount
Authorization received and approved1ACLEARINGAPPROVEDFunds debitedDebit $100

Authorization expiration

If a clearing request is not received within the card scheme's required timeframe, the authorization expires.

StageTransaction IDLifecycle IDTypeTransaction statusImpact on fundsAmount
Authorization received and approved1AAUTHORIZATIONPENDINGFunds reservedReserve $100
Authorization not cleared within required timeframe1AAUTHORIZATIONEXPIREDFunds releasedRelease $100
2AREVERSALCLEARED--

Partial clearing with reversal

An authorization can be partially cleared, with the remaining authorized amount subsequently reversed.

StageTransaction IDLifecycle IDTypeTransaction statusImpact on fundsAmount
Authorization received and approved1AAUTHORIZATIONPENDINGFunds reservedReserve $100
Partial clearing received1AAUTHORIZATIONCLEAREDFunds releasedRelease $100
2ACLEARINGAPPROVEDFunds debitedDebit $70
3AAUTHORIZATIONPENDINGRemaining funds reservedReserve $30
Full reversal of remaining amount3AAUTHORIZATIONREVERSEDFunds releasedRelease $30
4AREVERSALCLEARED--

Refund after clearing

After a transaction has been cleared, a refund can be processed to return funds to the cardholder.

StageTransaction IDLifecycle IDTypeTransaction statusImpact on fundsAmount
Authorization received and approved1AAUTHORIZATIONPENDINGFunds reservedReserve $100
Clearing received and processed1AAUTHORIZATIONCLEAREDFunds releasedRelease $100
2ACLEARINGAPPROVEDFunds debitedDebit $100
Merchant refund processed3AREFUNDAPPROVEDFunds creditedCredit $100

These scenarios demonstrate the key patterns, but actual transaction lifecycles can be more complex with multiple authorizations, partial clearings, and reversals all sharing the same lifecycle_id.

See also

To understand how to retrieve and monitor these transactions, refer to:

Was this page helpful?