To ensure the reliable delivery of real-time data to your systems, BR-DGE employs a Webhook Retry Strategy. This guide outlines how our system handles delivery failures and what you need to do on your end to ensure seamless integration of BR-DGE notifications.

How it works

When an event occurs in the BR-DGE ecosystem (e.g., a successful payment or a status change), our system sends an asynchronous POST request to your configured notifications endpoint with a JSON payload.

So that we can consider a notification successfully delivered, your server must respond with an HTTP 2xx status code (e.g., 200 OK or 202 Accepted). If you do not respond to the notification in a timely manner then we will place the notification in the retry queue where it will remain until you successfully respond to a retry attempt or all retry attempts have been exhausted.

Any of the following outcomes will trigger our retry mechanism:

Non-2xx Responses: Any 4xx (Client Error) or 5xx (Server Error) codes.
Timeouts: If your server takes too long to respond.
Connection Errors: If our system cannot establish a connection with your endpoint.

Connection Timeouts

BR-DGE enforces strict timeout limits for all webhook requests. Our system allows for a 10-second connection timeout, meaning your server must establish a TCP connection within this window. Once connected, we apply a 30-second socket/read timeout; if your server does not finish returning the full HTTP response within this timeframe, the attempt will be terminated and marked as a failure, subsequently entering the retry queue.

We strongly recommend that your endpoint acknowledges receipt immediately and moves any heavy processing to a background task to stay well within these bounds.

🚧
To maintain optimal throughput, BR-DGE reserves the right to tune these timeout parameters without notice. Merchants should treat these values as upper limits rather than targets.

Retry Schedule

If an initial delivery attempt fails, the notification is moved into a retry queue. We use an exponential backoff strategy to give your systems time to recover from transient issues while ensuring data is eventually delivered.

📘
All BR-DGE notifications regardless of type use the same retry strategy.

The current retry intervals are per the below:

Attempt	Delay After Previous Attempt	Cumulative Time Elapsed
Initial	Immediate	0 Seconds
Retry 1	1 Second	1 Second
Retry 2	10 Seconds	11 Seconds
Retry 3	30 Seconds	41 Seconds
Retry 4	5 Minutes	5 Minutes 41 Seconds
Retry 5	10 Minutes	15 Minutes 41 Seconds
Retry 6	30 Minutes	45 Minutes 41 Seconds
Retry 7	1 Hour	1 Hour 45 Minutes 41 Seconds
Retry 8	4 Hours	5 Hours 45 Minutes 41 Seconds
Retry 9	12 Hours	17 Hours 45 Minutes 41 Seconds
Retry 10	12 Hours	29 Hours 45 Minutes 41 Seconds

Implementation Best Practices

To handle webhooks effectively, we recommend the following developer patterns:

Respond Early, Process Later

Webhooks should be processed asynchronously. Your endpoint should validate the request and immediately return a 2xx status. Long-running tasks (like updating a database or triggering internal business logic) should be handled by your internal background workers. This prevents timeouts and unnecessary retries.
Verify Request Integrity

Ensure you are validating the webhook signatures provided in the headers to confirm the request originated from BR-DGE and hasn't been tampered with.

Support

If you have any questions regarding the notification retry strategy please contact our support team.