Skip to main content

​
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 a parent_transaction attribute. Here’s how it works:
Transaction lifecycle diagram showing how transactions move through different states in Blnks

Transaction lifecycle flow showing how transactions progress from QUEUED to final states

​
Statuses

Blnk transactions can have one of five possible statuses throughout their lifecycle. Each status represents a specific state in the transaction processing flow:
StatusDescriptionWhen it occurs
QUEUEDTransaction is received and waiting to be processedInitial state when a transaction is first created
APPLIEDTransaction has been successfully processed and applied to balancesWhen transaction completes successfully or when an inflight transaction is committed
INFLIGHTTransaction is on hold, waiting for further actionWhen a transaction is created with "inflight": true
VOIDInflight transaction was cancelled and balances resetWhen an inflight transaction is voided
REJECTEDTransaction was not processed due to errors (e.g., insufficient funds)When transaction fails validation or processing
All transactions in Blnk are immutable. Once a transaction has been applied, committed, or voided, you cannot roll back the status to its previous state.

​
Transaction lifecycle

By default, every transaction begins in a QUEUED state.
You can track balances with transactions still in queue using Queued Balances.
Blnk then processes it and moves it to one of three possible states:
  • 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.
Here’s an example response when you record a new transaction on Blnk:
Example response
{
  "precise_amount": 10000000,
  "amount": 100000,
  "rate": 0,
  "precision": 100,
  "transaction_id": "txn_d4951810-706c-44d1-be45-6f254be0e167",
  "parent_transaction": "",
  "source": "bln_7769aedf-bc88-49f7-bbb2-118f121daee6",
  "destination": "bln_c42e4bbd-4ea9-494a-89be-7634b0c1e41a",
  "reference": "ref_e55c4f33-bff7-4c30-9b9f-5d2d10a29b7a",
  "currency": "USD",
  "description": "Sample transaction",
  "status": "QUEUED",
  "hash": "3ef19e9cd9aba07d33068d096da1e1596f1270a70c9aa2d160206b4d6da553dc",
  "allow_overdraft": true,
  "inflight": false,
  "created_at": "2025-02-02T02:35:16.606614793Z",
  "scheduled_for": "0001-01-01T00:00:00Z",
  "inflight_expiry_date": "0001-01-01T00:00:00Z"
}

​
Parent transactions

Because transactions in Blnk are immutable, each new state or related record is linked back to the one that created it through the parent_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.
This structure ensures that every transaction has a clear lineage. By following the 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.

Parent transactions

Learn how parent transactions work in Blnk and how to use them in your application.

​
Skip transaction queue

Available in version 0.8.2 and later.
The 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: 
{
  "amount": 102.12,
  "precision": 100,
  ...
  "allow_overdraft": true,
  "skip_queue": true
}

​
How it works

When you enable skip_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

Use skip_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.

​
Need help?

We are very happy to help you make the most of Blnk, regardless of whether it is your first time or you are switching from another tool. To ask questions or discuss issues, please contact us or join our Discord community.
Tip: Connect to Blnk Cloud to see your Core data.You can view your transactions, manage identities, create custom reports, invite other team members to collaborate, and perform operations on your Core — all in one dashboard.Check out Blnk Cloud →