Managing side effects with Inflight
When dealing with financial transactions, it’s crucial to handle scenarios where additional verification or processing time is needed.
Blnk’s Inflight feature provides a powerful tool for managing transactions that require additional steps or approvals before being finalized. This feature allows you to hold funds without applying the transaction until certain conditions are met.
Overview of Blnk Inflight
Inflight is a transaction parameter that instructs Blnk to hold on applying a transaction until a specified condition has been met. This condition could be confirming that it has been processed by your payment partners or custom conditions set by your application.
Key benefits of using Inflight:
- Manages transactions that may take time to complete.
- Ensures funds are not available for spending until the transaction is finalized.
- Eliminates the need for refunds when partners return a failed response.
Example: Using Inflight for a payment requiring additional information
Let’s consider a scenario where we need to transfer $750.00 from Customer A’s USD wallet to an external payment provider, but the payment requires additional verification before being finalized. We’ll use the Inflight feature to manage this process.
First, let’s initiate the transaction with the Inflight flag:
How Inflight works
When you enable inflight
on a transaction:
- The transaction is added to the queue with status QUEUED.
- Once ready for processing, the status changes to INFLIGHT.
- The inflight balances of the participating ledger balances (
source
anddestination
) are updated:- inflight_credit_balance: Total amount waiting to be credited.
- inflight_debit_balance: Total amount waiting to be debited.
- The amount is debited from the source’s
inflight_debit_balance
and credited to the destination’sinflight_credit_balance
. - The main balances of the source and destination remain untouched until the transaction is finalized.
Handling webhooks and automating inflight transaction resolution
Let’s set up a simple Express.js server to handle webhooks and automate the Inflight transaction resolution process:
This example demonstrates:
- Setting up a webhook endpoint to receive notifications from your payment provider.
- Processing the webhook based on the payment status (VERIFIED or REJECTED).
- Committing or voiding the Inflight transaction accordingly.
- Error handling and logging.
Using expiry dates with inflight transactions
Expiration dates are crucial for managing Inflight transactions effectively. They ensure that transactions don’t remain in a pending state indefinitely, which could potentially lock funds unnecessarily.
Example: Setting and handling expiration
Blnk automatically voids the transaction once the expiration date is met and the transaction has not been committed fully.
Implementing partial commits for inflight transactions
Partial commits allow you to finalize a portion of an Inflight transaction while keeping the remainder in the Inflight state. This is particularly useful for scenarios where a transaction may be processed in parts.
Example: Partial commit of an inflight transaction
In this example:
- We defined a
partialCommitInflightTransaction
function that commits only a portion of the Inflight transaction. - The
handlePartialPaymentVerification
function demonstrates how you might use partial commits in your payment flow:- It commits the verified amount.
- Updates internal records.
- Checks if there’s any remaining amount still in the Inflight state.
- The
checkRemainingInflightAmount
function (which you would implement to query Blnk’s API or your database) helps track the progress of partial commits.
By using partial commits, you can handle complex scenarios where funds are released incrementally, such as:
- Multi-stage payment processes.
- Partial fulfillment of orders.
- Gradual release of funds based on milestone completions in a project.
Best practices for managing side effects with Inflight
-
Balance Checks: Ensure the source balance has enough funds to complete the transaction. Prevent the source balance from having a balance lower than the amount in its inflight_debit_balance.
-
Available Balance Calculation: This prevents users from accessing funds that are held in Inflight transactions. In your application, calculate the available balance as:
-
Error Handling: Implement robust error handling in your Inflight process. If a commit or void operation fails, you may need to retry or escalate to manual intervention.
-
Customer Communication: Implement a system to notify customers about the status of their transactions, especially when they’re held in Inflight.
-
Reconciliation: Regularly reconcile your internal records with Blnk’s transaction logs to ensure accuracy, paying special attention to Inflight transactions.(Blnk v1 will support reconcillation features built into the ledger).
-
Webhook Authentication: In a production environment, implement a mechanism to verify that the webhook is genuinely from your payment provider.
-
Idempotency: Ensure your webhook handler is idempotent. Providers may send the same webhook multiple times, so your system should handle duplicate notifications gracefully.
-
Monitoring: Set up monitoring and alerting for your webhook endpoint and Inflight transactions. This can help you quickly identify and respond to any issues in the payment verification process.
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.
Was this page helpful?