Instant Transaction Notifications: Webhooks Now Fire in Real Time

Webhook deliveries now fire at the moment a transaction settles, rather than waiting for the next scheduled dispatch.

What changed

Deliveries were previously queued and sent by a scheduled job, which meant up to a minute between a recharge completing and your system hearing about it. Delivery now starts the instant the status is written.

For most integrations this removes the last delay between a customer's recharge completing and their screen updating.

The queue is still there

Instant delivery is the fast path, not the only one. Every notification is still recorded in the delivery queue before it is sent, so if your endpoint is slow or unreachable at that moment, the scheduled job retries it on the normal backoff.

Nothing is lost either way. If instant delivery cannot complete, the retry schedule takes over — 1, 5, 15, 60, 180 and 360 minutes.

Nothing to change on your side

If you already receive webhooks, they simply arrive sooner. The payload, headers and signature are unchanged.

Timeouts are shorter on the instant path

Because delivery now happens inline with the transaction, the connection timeout is deliberately short — a few seconds rather than fifteen. If your endpoint takes longer than that, the delivery hands off to the retry queue instead of holding anything up.

This is a good reason to reply 200 quickly and do slow work afterwards. A handler that sends an SMS before replying may miss the fast path and arrive by retry instead.