While Brick automatically updates your system via callback URL, there are some edge cases where manually checking a transaction status is recommended or necessary.
When to Manually Check Status
Here are some common scenarios where you should actively call the Disbursement Status API:
1. Processing Too Long (Stuck > 1 Hour)
If your transaction remains in a processing state for more than an hour, this may indicate a delayed update or system issue. To avoid holding up your user experience, call the status API to fetch the latest result manually.
2. Uncertain Transaction Creation (API Error)
If your create payment out API call returns a server error (e.g., 500), you're left uncertain whether the transaction was created or not.
- In this case, do not retry the disbursement immediately—you may accidentally trigger a duplicate payout.
- First, use the Reference ID or Transaction ID to query the transaction status.
- Proceed with retrying only if the transaction status is clearly failed or not found.
3. Callback Delivery Failed
If your system did not receive the callback due to:
- Temporary network issues
- Misconfigured callback URL
- Downtime on your server
You should manually query the status API to keep your users informed and reconcile your records correctly.
How to Check Status
- Option 1: By Transaction ID
Use thetransaction_idreturned in the response after creating a disbursement.
📘 API Reference: Retrieve Disbursement by Transaction ID - Option 2: By Reference ID
Use your ownreference_idvalue that was sent during the disbursement request.
📘 API Reference: Retrieve Disbursement by Reference ID
Sample Use Case
You initiated a payment out, received a 500 Internal Server Error response, and aren't sure if it went through.
→ Query the transaction using the same Reference ID.
→ If status is completed, no need to retry.
→ If failed or not found, it's safe to retry.
For full implementation details, headers, and sample responses, refer to the Disbursement Status API documentation.
