Transaction workflows

​

Overview

When you record transactions on Blnk, there are three main statuses — queued, applied, and rejected.

First, you have a default QUEUED status immediately your “record transaction” request is sent; then a final APPLIED status when it has been applied to the participating balances.

When a transaction has been applied to a balance, it means the transaction amount has reflected in the balances computed. For instance, if a ledger balance received funds, APPLIED means the transaction amount has been added to its total balance.

A transaction status is only REJECTED if all of the conditions required for a transaction has not been met.

The conditions are:

1. The participating balances (source and destination) must have the same asset class (currency) as specified in the transaction request.
2. The source must have enough funds to process the transaction.
3. Overdraft must be enabled if the transaction has to happen but the source has insufficient funds.

​

Transaction recording workflows

It is crucial to make sure that your transaction records reflect exactly what’s going on in the outside world, i.e., if you record that a certain balance has sent money to an account, it needs to have actually happened for the record to be true.

To do this, you need to implement workflows that ensure your Blnk Ledger accurately mirrors what happens in real life.

There are two main ways to implement this workflow:

1. Payout workflow
2. Pay-in workflow

​

Payout workflow

You record the transaction first in your Blnk Ledger before it happens in real life. This workflow is best advised when recording transactions between balances in your Blnk Ledger or transactions to an external balance.

This is how to approach it:

1. When a transaction is initiated, record it first in your Blnk Ledger. This makes sure that your ledger serves as the full source of truth for every transaction activity that goes in your application.

2. Blnk sends a transaction.applied webhook when the transactions has been applied to the balances. Set up your application to listen for this webhook event. This also means all conditions for a successful transaction to take place have been met.

3. If it is a transaction between balances managed by your application, you don’t have to do anything.

4. If it is a transaction to an external balance, immediately trigger a payout with your payment partners as soon as you receive the transaction.applied webhook event.

   • If you receive a successful response from your partners, you are good to go; you don’t have to do anything else.
   • If you receive a failed response from your partners meaning they were unable to process it, you can refund the transaction on your Blnk Ledger.

​

Pay-in workflow

Here, the transaction happens first in real life before you record it in your Blnk Ledger.

This is how to approach it:

1. When an external balance initiates a transaction with a balance managed by your application, your partners notify you via a webhook that you’ve received some funds.

2. Once confirmed, identify which specific balance the transaction is intended for, and immediately initiate a transaction record on your Blnk Ledger providing the specified balance_id as the destination.

3. Blnk sends a transaction.applied webhook to notify you that the balance now reflects the transaction.

​

See also

​

Need help?

Are you stuck? Do you have a question that isn’t answered in this doc? Have you run into a problem you can’t solve? Want to file a bug report?

Join our Discord server and share your questions/thoughts with other developers building financial applications like you.