Transaction scenarios
Example flows by transaction category - purchase, account funding, original credit, cash withdrawal, and bill payment - with authorization, clearing, reversal clearing, declines, and refunds.
These examples show how card payment patterns map to lifecycles, card transactions, and transaction events. Placeholder IDs follow a consistent pattern: LC-* (lifecycle), CT-* (card transaction), TE-* (transaction event). For event type, subtype, and fund movement by category, see Transaction events and categories.
Each scenario below starts with a business scenario (what happens for the cardholder or merchant), then in the API (how that maps to lifecycle, card transaction, and transaction events).
Purchase transaction
PURCHASE is a purchase of goods or services at a merchant. Typical use: the cardholder buys goods or services at a merchant (retail, online, or in-person). Unless noted, the transaction category in the tables is PURCHASE. Refunds use MERCHANT_CREDIT or DISPUTE_CREDIT on a separate card transaction.
Purchase with $0 verification (no payment)
Business scenario: A merchant or issuer checks that the card is valid before charging, without moving money.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 verifies card (VERIFIED). See Event type and fund movement mapping for AUTHORIZATION / VERIFICATION on PURCHASE.
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| $0 verification approved | LC-1 | CT-1 | VERIFIED | NO_MOVEMENT | PURCHASE | TE-1 | AUTHORIZATION | VERIFICATION |
Purchase with $0 verification followed by a separate purchase
Business scenario: The cardholder passes a $0 check, then completes a separate purchase that uses an authorization and a clearing.
In the API: One lifecycle LC-1, two card transactions CT-1, CT-2. TE-1 verifies card (VERIFIED); TE-2 reserves funds (AUTHORIZED); TE-3 completes clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| $0 verification approved | LC-1 | CT-1 | VERIFIED | NO_MOVEMENT | PURCHASE | TE-1 | AUTHORIZATION | VERIFICATION |
| Purchase authorization received and approved | LC-1 | CT-2 | AUTHORIZED | DEBIT | PURCHASE | TE-2 | AUTHORIZATION | AUTHORIZATION |
| Purchase clearing received and processed | LC-1 | CT-2 | CLEARED | DEBIT | PURCHASE | TE-3 | CLEARING | CLEARING |
Purchase with an authorization followed by a clearing
Business scenario: A standard purchase where the merchant gets an approval first and a clearing settles the amount later.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 reserves funds (AUTHORIZED); TE-2 completes clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization received and approved | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-1 | AUTHORIZATION | AUTHORIZATION |
| Clearing received and processed | LC-1 | CT-1 | CLEARED | DEBIT | PURCHASE | TE-2 | CLEARING | CLEARING |
Purchase with an authorization and clearing in a single message
Business scenario: The cardholder pays where authorization and clearing are processed together in one step.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 completes clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization and clearing in one message | LC-1 | CT-1 | CLEARED | DEBIT | PURCHASE | TE-1 | CLEARING | CLEARING |
Purchase with declined authorization and clearing in a single message
Business scenario: Airwallex or the scheme declines the combined authorization and clearing request; the payment does not complete and no funds are debited.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 is CLEARING / CLEARING and the card transaction ends in DECLINED. The transaction event includes a failure_reason; see Transaction failure reasons.
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization and clearing declined | LC-1 | CT-1 | DECLINED | DEBIT | PURCHASE | TE-1 | CLEARING | CLEARING |
Purchase with authorization expiration
Business scenario: The merchant never completes the sale after an approval, and the authorization reserve expires or is released.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 reserves funds (AUTHORIZED); TE-2 releases the reserve (EXPIRED). For default expiration periods, exceptions, and why expiration matters, see Authorization expiration.
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization received and approved | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-1 | AUTHORIZATION | AUTHORIZATION |
| Authorization not cleared within required timeframe | LC-1 | CT-1 | EXPIRED | DEBIT | PURCHASE | TE-2 | EXPIRED_AUTHORIZATION | - |
Purchase with an authorization, partial clearing, and reversal
Business scenario: The merchant clears part of the authorized amount, then reverses the remainder.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 reserves funds (AUTHORIZED); TE-2 applies partial clearing (AUTHORIZED); TE-3 completes partial reversal (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization received and approved | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-1 | AUTHORIZATION | AUTHORIZATION |
| Partial clearing received | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-2 | CLEARING | PARTIAL_CLEARING |
| Reversal of remaining amount | LC-1 | CT-1 | CLEARED | DEBIT | PURCHASE | TE-3 | REVERSAL | PARTIAL_REVERSAL |
Purchase with an authorization and three partial clearings
Business scenario: The merchant settles the purchase in three partial clearing advices.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 reserves funds (AUTHORIZED); TE-2 applies partial clearing (AUTHORIZED); TE-3 applies partial clearing (AUTHORIZED); TE-4 completes clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization received and approved | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-1 | AUTHORIZATION | AUTHORIZATION |
| First partial clearing received | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-2 | CLEARING | PARTIAL_CLEARING |
| Second partial clearing received | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-3 | CLEARING | PARTIAL_CLEARING |
| Third partial clearing received (final) | LC-1 | CT-1 | CLEARED | DEBIT | PURCHASE | TE-4 | CLEARING | CLEARING |
Purchase with two incremental authorizations and one clearing
Business scenario: The merchant raises the authorized amount twice, then sends one clearing for the full settled amount.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 reserves funds (AUTHORIZED); TE-2 increases authorization (AUTHORIZED); TE-3 increases authorization (AUTHORIZED); TE-4 completes clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization received and approved | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-1 | AUTHORIZATION | AUTHORIZATION |
| First incremental authorization | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-2 | AUTHORIZATION | INCREMENTAL_AUTHORIZATION |
| Second incremental authorization | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-3 | AUTHORIZATION | INCREMENTAL_AUTHORIZATION |
| Clearing received and processed | LC-1 | CT-1 | CLEARED | DEBIT | PURCHASE | TE-4 | CLEARING | CLEARING |
Purchase with two incremental authorizations and four partial clearings
Business scenario: The authorized amount is raised twice, then the merchant settles with four partial clearing advices.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 reserves funds (AUTHORIZED); TE-2 increases authorization (AUTHORIZED); TE-3 increases authorization (AUTHORIZED); TE-4 applies partial clearing (AUTHORIZED); TE-5 applies partial clearing (AUTHORIZED); TE-6 applies partial clearing (AUTHORIZED); TE-7 completes clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization received and approved | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-1 | AUTHORIZATION | AUTHORIZATION |
| First incremental authorization | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-2 | AUTHORIZATION | INCREMENTAL_AUTHORIZATION |
| Second incremental authorization | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-3 | AUTHORIZATION | INCREMENTAL_AUTHORIZATION |
| First partial clearing received | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-4 | CLEARING | PARTIAL_CLEARING |
| Second partial clearing received | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-5 | CLEARING | PARTIAL_CLEARING |
| Third partial clearing received | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-6 | CLEARING | PARTIAL_CLEARING |
| Fourth partial clearing received (final) | LC-1 | CT-1 | CLEARED | DEBIT | PURCHASE | TE-7 | CLEARING | CLEARING |
Purchase with two incremental authorizations, a partial reversal, and two partial clearings
Business scenario: After incremental authorizations, a partial reversal reduces the open authorization before two partial clearings finish settlement.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 reserves funds (AUTHORIZED); TE-2 increases authorization (AUTHORIZED); TE-3 increases authorization (AUTHORIZED); TE-4 partially reverses (AUTHORIZED); TE-5 applies partial clearing (AUTHORIZED); TE-6 completes clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization received and approved | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-1 | AUTHORIZATION | AUTHORIZATION |
| First incremental authorization | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-2 | AUTHORIZATION | INCREMENTAL_AUTHORIZATION |
| Second incremental authorization | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-3 | AUTHORIZATION | INCREMENTAL_AUTHORIZATION |
| Partial reversal received | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-4 | REVERSAL | PARTIAL_REVERSAL |
| First partial clearing received | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-5 | CLEARING | PARTIAL_CLEARING |
| Second partial clearing received (final) | LC-1 | CT-1 | CLEARED | DEBIT | PURCHASE | TE-6 | CLEARING | CLEARING |
Purchase with clearing and reversal clearing
Business scenario: A settled purchase is later reversed; the reversal appears as a separate card-level flow that credits the wallet.
In the API: One lifecycle LC-1, two card transactions CT-1, CT-2. TE-1 reserves funds (AUTHORIZED); TE-2 completes clearing (CLEARED); TE-3 completes reversal clearing (CLEARED). See Event type and fund movement mapping for CLEARING / CLEARING_REVERSAL on PURCHASE.
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization received and approved | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-1 | AUTHORIZATION | AUTHORIZATION |
| Clearing received and processed | LC-1 | CT-1 | CLEARED | DEBIT | PURCHASE | TE-2 | CLEARING | CLEARING |
| Reversal clearing received | LC-1 | CT-2 | CLEARED | CREDIT | PURCHASE | TE-3 | CLEARING | CLEARING_REVERSAL |
Purchase with clearing and a matched merchant credit refund
Business scenario: A refund is tied to the original purchase (same payment story).
In the API: One lifecycle LC-1, two card transactions CT-1, CT-2. TE-1 reserves funds (AUTHORIZED); TE-2 completes clearing (CLEARED); TE-3 authorizes credit (AUTHORIZED); TE-4 completes refund clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization received and approved | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-1 | AUTHORIZATION | AUTHORIZATION |
| Clearing received and processed | LC-1 | CT-1 | CLEARED | DEBIT | PURCHASE | TE-2 | CLEARING | CLEARING |
| Refund authorization received and approved | LC-1 | CT-2 | AUTHORIZED | CREDIT | MERCHANT_CREDIT | TE-3 | AUTHORIZATION | AUTHORIZATION |
| Refund clearing received and processed | LC-1 | CT-2 | CLEARED | CREDIT | MERCHANT_CREDIT | TE-4 | CLEARING | CLEARING |
Purchase with clearing and a matched dispute refund
Business scenario: A dispute resolves in the cardholder's favor; the credit is modeled like a matched refund and uses DISPUTE_CREDIT.
In the API: One lifecycle LC-1, two card transactions CT-1, CT-2. TE-1 reserves funds (AUTHORIZED); TE-2 completes clearing (CLEARED); TE-3 completes clearing (CLEARED). CT-2 uses DISPUTE_CREDIT.
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization received and approved | LC-1 | CT-1 | AUTHORIZED | DEBIT | PURCHASE | TE-1 | AUTHORIZATION | AUTHORIZATION |
| Clearing received and processed | LC-1 | CT-1 | CLEARED | DEBIT | PURCHASE | TE-2 | CLEARING | CLEARING |
| Dispute credit received and processed | LC-1 | CT-2 | CLEARED | CREDIT | DISPUTE_CREDIT | TE-3 | CLEARING | CLEARING |
Merchant credit with authorization and clearing (unmatched lifecycle)
Business scenario: A refund cannot be linked to a prior purchase in the same lifecycle, so it starts its own lifecycle.
In the API: One lifecycle LC-2, one card transaction CT-1. TE-1 authorizes credit (AUTHORIZED); TE-2 completes clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Refund authorization received and approved | LC-2 | CT-1 | AUTHORIZED | CREDIT | MERCHANT_CREDIT | TE-1 | AUTHORIZATION | AUTHORIZATION |
| Refund clearing received and processed | LC-2 | CT-1 | CLEARED | CREDIT | MERCHANT_CREDIT | TE-2 | CLEARING | CLEARING |
Merchant credit with declined authorization (unmatched lifecycle)
Business scenario: Airwallex or the scheme declines the refund authorization; the credit does not post and no funds are credited.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 declines authorization (DECLINED). The transaction event includes a failure_reason; see Transaction failure reasons.
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization declined | LC-1 | CT-1 | DECLINED | CREDIT | MERCHANT_CREDIT | TE-1 | AUTHORIZATION | AUTHORIZATION |
Purchase with declined authorization
Business scenario: Airwallex or the scheme declines the authorization request; the payment does not proceed and no funds are reserved.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 declines authorization (DECLINED). The transaction event includes a failure_reason; see Transaction failure reasons.
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization declined | LC-1 | CT-1 | DECLINED | DEBIT | PURCHASE | TE-1 | AUTHORIZATION | AUTHORIZATION |
Account funding transaction
ACCOUNT_FUNDING is a transaction that loads or adds funds to an account. Typical use: loading a prepaid or wallet account, or adding funds to the card balance. Authorization reserves funds and clearing debits the wallet, consistent with PURCHASE and CASH_DISBURSEMENT in the fund movement mapping.
Account funding with authorization and clearing in a single message
Business scenario: The cardholder loads funds in one step where authorization and clearing arrive together.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 completes clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization and clearing in one message | LC-1 | CT-1 | CLEARED | DEBIT | ACCOUNT_FUNDING | TE-1 | CLEARING | CLEARING |
Account funding with clearing and reversal clearing
Business scenario: A completed load is reversed; the reversal clearing credits the wallet.
In the API: One lifecycle LC-1, two card transactions CT-1, CT-2. TE-1 completes clearing (CLEARED); TE-2 completes reversal clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization and clearing in one message | LC-1 | CT-1 | CLEARED | DEBIT | ACCOUNT_FUNDING | TE-1 | CLEARING | CLEARING |
| Reversal clearing received | LC-1 | CT-2 | CLEARED | CREDIT | ACCOUNT_FUNDING | TE-2 | CLEARING | CLEARING_REVERSAL |
Account funding with declined authorization and clearing in a single message
Business scenario: Airwallex or the scheme declines the combined load request; the account funding does not complete and no funds are debited.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 is CLEARING / CLEARING and the card transaction ends in DECLINED. The transaction event includes a failure_reason; see Transaction failure reasons.
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization and clearing declined | LC-1 | CT-1 | DECLINED | DEBIT | ACCOUNT_FUNDING | TE-1 | CLEARING | CLEARING |
Original credit transaction
ORIGINAL_CREDIT is a credit pushed to the card without a prior debit (no linked purchase). Typical use: payroll, benefits, disbursements, or other push payments sent to the card. Clearing credits the wallet. CLEARING_REVERSAL can debit the wallet to reverse a cleared credit, often on a separate card transaction. See fund movement mapping.
Original credit with authorization and clearing in a single message
Business scenario: A push credit is applied in one step where authorization and clearing arrive together.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 completes clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization and clearing in one message | LC-1 | CT-1 | CLEARED | CREDIT | ORIGINAL_CREDIT | TE-1 | CLEARING | CLEARING |
Original credit with clearing and reversal clearing
Business scenario: A completed push credit is reversed.
In the API: One lifecycle LC-1, two card transactions CT-1, CT-2. TE-1 completes clearing (CLEARED); TE-2 completes reversal clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization and clearing in one message | LC-1 | CT-1 | CLEARED | CREDIT | ORIGINAL_CREDIT | TE-1 | CLEARING | CLEARING |
| Reversal clearing received | LC-1 | CT-2 | CLEARED | DEBIT | ORIGINAL_CREDIT | TE-2 | CLEARING | CLEARING_REVERSAL |
Original credit with declined authorization and clearing in a single message
Business scenario: Airwallex or the scheme declines the combined push-credit request; the credit does not post and no funds are credited.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 is CLEARING / CLEARING and the card transaction ends in DECLINED. The transaction event includes a failure_reason; see Transaction failure reasons.
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization and clearing declined | LC-1 | CT-1 | DECLINED | CREDIT | ORIGINAL_CREDIT | TE-1 | CLEARING | CLEARING |
Cash withdrawal transaction
CASH_DISBURSEMENT is a cash withdrawal, typically at an ATM or over the counter. Typical use: the cardholder withdraws cash from an ATM or receives cash from a bank or agent. Authorization, clearing, and reversal clearing follow the same fund movements as PURCHASE and ACCOUNT_FUNDING.
Cash withdrawal with authorization and clearing in a single message
Business scenario: The cardholder withdraws cash in one step where authorization and clearing arrive together.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 completes clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization and clearing in one message | LC-1 | CT-1 | CLEARED | DEBIT | CASH_DISBURSEMENT | TE-1 | CLEARING | CLEARING |
Cash withdrawal with clearing and reversal clearing
Business scenario: A completed withdrawal is reversed; reversal clearing credits the wallet.
In the API: One lifecycle LC-1, two card transactions CT-1, CT-2. TE-1 completes clearing (CLEARED); TE-2 completes reversal clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization and clearing in one message | LC-1 | CT-1 | CLEARED | DEBIT | CASH_DISBURSEMENT | TE-1 | CLEARING | CLEARING |
| Reversal clearing received | LC-1 | CT-2 | CLEARED | CREDIT | CASH_DISBURSEMENT | TE-2 | CLEARING | CLEARING_REVERSAL |
Cash withdrawal with declined authorization and clearing in a single message
Business scenario: Airwallex or the scheme declines the combined withdrawal request; cash is not dispensed and no funds are debited.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 is CLEARING / CLEARING and the card transaction ends in DECLINED. The transaction event includes a failure_reason; see Transaction failure reasons.
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization and clearing declined | LC-1 | CT-1 | DECLINED | DEBIT | CASH_DISBURSEMENT | TE-1 | CLEARING | CLEARING |
Bill payment transaction
BILL_PAYMENT is a payment to another party or a domestic bill-pay style payment (historically PAY_OTHER_PARTY and PAYMENT_US). Typical use: the cardholder pays a bill, pays a third party, or completes a domestic bill-pay or similar payment flow. Authorization, clearing, reversal clearing, and matched refunds follow the same patterns as PURCHASE in the fund movement mapping.
Bill payment with authorization and clearing in a single message
Business scenario: The cardholder pays a bill in one step where authorization and clearing arrive together.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 completes clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization and clearing in one message | LC-1 | CT-1 | CLEARED | DEBIT | BILL_PAYMENT | TE-1 | CLEARING | CLEARING |
Bill payment with an authorization followed by a clearing
Business scenario: The cardholder gets an approval for the bill payment, then clearing debits the wallet.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 reserves funds (AUTHORIZED); TE-2 completes clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization received and approved | LC-1 | CT-1 | AUTHORIZED | DEBIT | BILL_PAYMENT | TE-1 | AUTHORIZATION | AUTHORIZATION |
| Clearing received and processed | LC-1 | CT-1 | CLEARED | DEBIT | BILL_PAYMENT | TE-2 | CLEARING | CLEARING |
Bill payment with clearing and reversal clearing
Business scenario: A completed bill payment is reversed; reversal clearing credits the wallet.
In the API: One lifecycle LC-1, two card transactions CT-1, CT-2. TE-1 reserves funds (AUTHORIZED); TE-2 completes clearing (CLEARED); TE-3 completes reversal clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization received and approved | LC-1 | CT-1 | AUTHORIZED | DEBIT | BILL_PAYMENT | TE-1 | AUTHORIZATION | AUTHORIZATION |
| Clearing received and processed | LC-1 | CT-1 | CLEARED | DEBIT | BILL_PAYMENT | TE-2 | CLEARING | CLEARING |
| Reversal clearing received | LC-1 | CT-2 | CLEARED | CREDIT | BILL_PAYMENT | TE-3 | CLEARING | CLEARING_REVERSAL |
Bill payment with clearing and a matched merchant credit refund
Business scenario: A refund is tied to the original bill payment (same payment story).
In the API: One lifecycle LC-1, two card transactions CT-1, CT-2. TE-1 reserves funds (AUTHORIZED); TE-2 completes clearing (CLEARED); TE-3 authorizes credit (AUTHORIZED); TE-4 completes refund clearing (CLEARED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization received and approved | LC-1 | CT-1 | AUTHORIZED | DEBIT | BILL_PAYMENT | TE-1 | AUTHORIZATION | AUTHORIZATION |
| Clearing received and processed | LC-1 | CT-1 | CLEARED | DEBIT | BILL_PAYMENT | TE-2 | CLEARING | CLEARING |
| Refund authorization received and approved | LC-1 | CT-2 | AUTHORIZED | CREDIT | MERCHANT_CREDIT | TE-3 | AUTHORIZATION | AUTHORIZATION |
| Refund clearing received and processed | LC-1 | CT-2 | CLEARED | CREDIT | MERCHANT_CREDIT | TE-4 | CLEARING | CLEARING |
Bill payment with declined authorization
Business scenario: Airwallex or the scheme declines the bill payment authorization; the bill is not paid and no funds are debited.
In the API: One lifecycle LC-1, one card transaction CT-1. TE-1 declines authorization (DECLINED).
| Stages | Lifecycle ID | Card transaction ID | Card transaction status | Fund direction | Transaction category | Transaction event ID | Transaction event type | Transaction event subtype |
|---|---|---|---|---|---|---|---|---|
| Authorization declined | LC-1 | CT-1 | DECLINED | DEBIT | BILL_PAYMENT | TE-1 | AUTHORIZATION | AUTHORIZATION |
See also
- Transaction lifecycle
- Transaction events and categories
- Retrieve lifecycle and transaction data
- Transaction lifecycle (older API versions)