Automatic Retry and Callback Handling
How It Works
When a callback delivery attempt fails, Brick will trigger a retry automatically.
Each retry is scheduled after the system receives the failed callback log from the previous attempt.
Successful Callback Response
Brick treats a transaction callback as successfully received when your endpoint returns HTTP 200 after accepting the event. Return the success response only after your system has stored the callback data or queued it safely for processing.
Dashboard Callback URL Test URL / Save & Test is stricter: the validation request must return HTTP 200 with a JSON ACK that echoes Brick's test referenceId.
Code
The validation flow also accepts reference_id as an alias. Empty responses, plain text, invalid JSON, missing references, mismatched references, non-200 responses, unreachable hosts, and timeouts are failed callback tests.
Callback status inspection is read-only and is available in the Client Dashboard through GET /v3/exp/dashboard/disbursement/callback/status. Resend actions still use the existing legacy route because they create another callback delivery attempt.
Retry Schedule
The automatic callback retry schedule is as follows:
- 1st retry: sent in realtime after the first failed callback log is received
- 2nd retry: sent 1 minute after the failed callback log for the 1st retry is received
- 3rd retry: sent 2 minutes after the failed callback log for the 2nd retry is received
- 4th retry: sent 13 minutes after the failed callback log for the 3rd retry is received
- 5th retry: sent 47 minutes after the failed callback log for the 4th retry is received
📘 Important Notes
- Automatic retry is triggered only when the previous callback attempt is not successfully received.
- Each retry depends on the failed log from the previous attempt.
- Because retries may result in repeated delivery of the same event, merchants should always handle callbacks in an idempotent way.