Learn how transactions are recorded and processed in Blnk
Transactions enable money movement between two or more balances. These can be payments, transfers, settlements, internal treasury management, etc. All transactions in Blnk are recorded with the double entry principle — every transaction has a source and a corresponding destination.Transactions happen between balances, and balances are created within ledgers.In this guide, you’ll learn about:
Immutability: Once recorded, transactions in Blnk cannot be modified or deleted. This fundamental property ensures the integrity and reliability of your transaction history, preventing any unauthorized alterations. See also: Transaction hashing
Idempotency: Each transaction in Blnk produces the same result whether executed once or multiple times. This is crucial for maintaining data consistency, especially during network failures or system retries.
Blnk implements idempotency by requiring a unique reference for every transaction. This reference serves as a transaction identifier, preventing duplicate processing and ensuring consistent outcomes.
If this is your first transaction, the participating balances will start at 0. To ensure the transaction is successful, enable overdrafts as shown above, allowing the source balance to go negative.Learn more about Overdrafts and Negative Balances.
Request
Response
Field
Description
Required
Type
precise_amount
Transaction amount in its smallest unit (recommended). Send either precise_amount or amount, not both — see Precision.
Yes
integer
amount
Transaction amount as a float. Blnk multiplies by precision to store precise_amount.
Yes
float
reference
Your unique reference to ensure idempotency.
Yes
string
currency
Short code for your asset class.
Yes
string
precision
Precision for the currency/asset passed. See also: Precision
No
int64
source
Sender’s balance ID
Yes
string
destination
Recipient’s balance ID.
Yes
string
description
Description or narration of the transaction.
No
string
meta_data
Custom data associated with the transaction
No
object
Field
Description
Type
amount
The transaction amount.
Yes
float
reference
Your unique reference to ensure idempotency.
Yes
string
currency
Short code for your asset class.
Yes
string
precision
Precision for the currency/asset passed. See also: Precision
No
int64
source
Sender’s balance ID
Yes
string
destination
Recipient’s balance ID.
Yes
string
description
Description or narration of the transaction.
No
string
meta_data
Custom data associated with the transaction
No
object
id
Unique id for the transaction. This is generated by Blnk.
string
precise_amount
The transaction amount recorded after the precision value has been applied. See also: Precision
Passing detailed data with the meta_data object is encouraged; it provides you with 360-degree insights about each transaction record. Examples of data you can pass include sender_name, account_number, bank_name, receiver_name, payment_id, ip_address, location, payment_method, etc.
Direct API calls: Query the transaction status using the reference or transaction ID. See below:
By reference (direct endpoint)
By reference (search)
By transaction ID
Blnk appends a _q suffix to your original reference after processing a QUEUED transaction. To verify the updated status, retrieve the transaction using your original reference plus the _q suffix.
curl -X GET "http://YOUR_BLNK_INSTANCE_URL/transactions/reference/{reference}" \ -H "X-blnk-key: <api-key>"
To check the updated status, take the queued transaction ID and search with it as the parent_transaction. This is because Blnk treats the queued transaction as the parent for the next transaction state. See also: Transaction lifecycle
The response immediately shows the final status (INFLIGHT, APPLIED, or REJECTED), allowing you to confirm the transaction result without waiting for webhooks or additional API calls.
When using skip_queue: true, you may encounter lock errors if multiple transactions are processed simultaneously on the same balance. Learn how to handle these scenarios in our Handling Hot Balances guide.
A discarded transaction is not recorded in the ledger. Blnk discards transactions for two reasons:
Duplicate reference: Your new transaction reference matches an existing reference in your ledger. Blnk requires unique reference values per transaction. Options are timestamps (e.g. UNIX timestamp), random string or UUID (e.g. ref_e55c4f33-bff7-4c30-9b9f-5d2d10a29b7a), or a business identifier like an order_id.
Zero amount: Your transaction amount is 0. Zero amounts are not recorded in the Blnk ledger.
Make sure your request body match the Blnk Ledger API specifications. For example, avoid passing apply_overdraft instead of allow_overdraft.
Available in version 0.11.0 and later. For versions 0.10.8 and older, see our insufficient funds guide.
Blnk performs comprehensive balance checks before processing any transaction to ensure you have sufficient funds available. The system computes an available balance by calculating balance - inflight_debit_balance on the source balance.Inflight debit balance is the amount waiting to be deducted from the source balance from inflight transactions. Learn more: Create inflight.If the transaction amount is more than the available balance, the source has insufficient funds and:
The transaction is rejected and status is recorded as REJECTED.
A webhook notification to inform your system of the rejected transaction and a reason in its meta_data.
If you want a transaction to proceed even when it exceeds the available balance, you can enable overdrafts by setting allow_overdraft: true in your transaction request. Learn more.
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.