Recover missed and repeated bill payment webhooks
Acknowledge webhook events after durable receipt, recover from receiver outages and handle repeat deliveries without duplicate receipts or financial entries.
Already registered? Open API settings and follow the business-access steps. Sandbox purchases do not deliver real services.
Reviewed
Your webhook endpoint can return 200 and still lose an event if the process crashes before saving it. A receiver needs a durable handoff between accepting a delivery and updating the customer's order.
Acknowledge something you can recover
Verify the signature and timestamp against the original request bytes before trusting the payload. Parse the verified event, validate the fields you use, and persist it or enqueue it durably before returning a successful acknowledgement.
Keep the event ID unique within the appropriate partner or endpoint context. Repeated deliveries should find the already-recorded event and acknowledge it without recreating its effects. Use the transaction identity and local order state as additional checks when processing the event.
| Failure point | Recovery you should be able to demonstrate |
|---|---|
| Receiver unavailable | Delivery history shows a failure; later delivery or reconciliation restores the update |
| Event stored but worker stopped | A restarted worker can process the saved event |
| Event processed but acknowledgement lost | A repeat delivery is harmless |
| Older pending event arrives later | It does not roll back a completed order |
| A legitimate reversal follows success | The later state is handled explicitly and once |
Keep the receiver small
Avoid waiting for email, analytics or a downstream integration before acknowledging a durably accepted event. Perform those steps from a recoverable worker. A temporary receipt-email failure should not force the payment event itself to run again from the beginning.
Do not return a success response when durable storage has failed. RizPay's webhook documentation describes retries after unsuccessful delivery, but retries are finite. Check delivery history and endpoint status during an outage; do not assume an endpoint will be retried forever or that every event arrives in order.
Reconcile the gaps
Use transaction reads to compare unresolved local orders with their current API status. The reconciliation process should operate on existing references, never create replacement purchases to make the list look complete.
Some delivery data needs its own recovery plan. For electricity tokens, retain the signed completion event and follow the token recovery guide when a successful purchase has no token in your receipt. A REST status read should not be assumed to contain every field from a webhook.
Run a controlled receiver-outage test in the sandbox. Restart after saving an event but before processing it, then repeat a valid delivery. Check that the original order reaches the correct state, that the customer receives one consistent receipt and that duplicate deliveries do not produce additional ledger entries.