Overview
Every transaction goes through multiple states in Blnk, and each state change is stored as a separate record in the database. This gives you complete traceability, allowing you to see the lifecycle of a transaction from initiation to completion. Each state is connected to the previous state through aparent_transaction
attribute. Here’s how it works:

Transaction lifecycle flow showing how transactions progress from QUEUED to final states
Transaction lifecycle
By default, every transaction begins in aQUEUED
state.
You can track balances with transactions still in queue using Queued Balances.
INFLIGHT
: If the transaction request includes"inflight": "true"
. It continues to:APPLIED
: If the inflight transaction is committed or;VOID
: If the inflight transaction is voided.
APPLIED
: When the transaction is completed and applied to the balances.REJECTED
: When the transaction is not processed due to reasons like insufficient funds, etc.
Example response
Parent transactions
Because transactions in Blnk are immutable, each new state or related record is linked back to the one that created it through theparent_transaction
field.
For example, if you have a $100 inflight transaction that is later committed, the commit record points to the inflight record as its parent.
parent_transaction
chain, you can always trace a transaction back to its origin, see how it evolved, and connect it to any related siblings.
- Queued transactions act as the parent of the next state (e.g.
APPLIED
,INFLIGHT
,REJECTED
). - Inflight transactions are the parent of their final outcome (e.g.
APPLIED
,VOID
). - Split transactions are the parent of the resulting individual transactions.
- Bulk transactions are the parent of the included individual transactions.
- Scheduled transactions are the parent of the executed state (e.g.
APPLIED
,REJECTED
). - Refunds use the original transaction as their parent.
Skip transaction queue
Available in version 0.8.2 and later.
skip_queue
feature allows you to bypass the default transaction queuing system and immediately process transactions directly. This is useful for scenarios where you need real-time transaction processing while still maintaining data consistency.
To enable this feature, include “skip_queue”: true in the request body when calling the Create Transaction endpoint:
How it works
When you enableskip_queue
, the transaction:
- Bypasses the normal queuing process
- Executes immediately on the balance
- Uses distributed locks via Redis to maintain consistency
- Applies optimistic locking at the database level
Example applications
Useskip_queue
when:
- Processing low-volume transactions with minimal balance contention;
- You need synchronous confirmation of transaction completion;
- Time-sensitive financial operations.
We recommend using queues for high traffic scenarios to avoid lock errors. Learn how: Handling Hot Balances
Transaction statuses
Learn about all transaction statuses and what they mean in your ledger.
Applying inflight
Understand how to hold transactions until specific conditions are met.