What is a transaction lifecycle?
Transaction lifecycle
A transaction lifecycle is the set of statuses a transfer moves through from accept to finish. In Blnk those statuses are QUEUED, APPLIED, INFLIGHT, VOID, and REJECTED. Each new status is a new record that points at the last one. The old row stays.
How does the transaction lifecycle work?
A request lands as QUEUED. The worker then applies it, holds it inflight, or rejects it. An inflight record later becomes APPLIED or VOID. You never write a status backwards. Immutability is the rule.
| Status | Meaning |
|---|---|
| QUEUED | Accepted, waiting for the worker |
| APPLIED | Posted to settled balances |
| INFLIGHT | Held until commit or void |
| VOID | Hold released, balances unchanged |
| REJECTED | Not posted, often insufficient funds |
Why is each status a new record?
If you overwrite one row, you cannot prove what the transfer was an hour ago. A new record per status keeps the path. The parent field ties them. Webhooks fire on the new state, not on a silent edit.
Scheduled and queued
A scheduled transfer waits with a scheduled status until its time, then enters the same lifecycle as any other transfer. Queued is not scheduled. Queued means “accepted, not yet worked.” Scheduled means “do not work this until the clock says so.”
In Blnk the five statuses above are the lifecycle. Follow parent_transaction to walk QUEUED to INFLIGHT to APPLIED or VOID. Subscribe to webhooks for the state changes you care about. See transaction lifecycle.