Developer Docs
Webhooks & Transaction Status
Know the final result without guessing.
Some transactions finish instantly; others come back as PENDING and settle a little later. There are two ways to learn how they ended.
Sample guide
This shows how it works across our APIs. Exact header names, values and any extra steps are confirmed with your sandbox credentials.
Two ways to get the result
| Way | How it works | Use it for |
|---|---|---|
| Webhook | We call an HTTPS endpoint you provide when a status changes. | Your main path — no polling, no delay. |
| Status call | You ask for a transaction by its reference. | A backstop when a webhook has not arrived, and for support lookups. |
What a webhook carries
A JSON body with the transaction's references and its new status — for example:
Webhook body · sample
{
"event": "transaction.updated",
"referenceId": "KRXB71Q2M8",
"clientReference": "order_20260921_0001",
"status": "SUCCESS",
"amount": 1240,
"updatedAt": "2026-09-21T10:42:07+05:30"
}Handling webhooks well
- Reply with a 2xx quickly, then do the work. Slow replies look like failures and get retried.
- Expect the same event more than once. Use
referenceIdto ignore repeats. - Only move a status forward — PENDING to SUCCESS or FAILED — never back.
- Verify the sender. How webhooks are signed is shared with your credentials; until you check it, treat the body as a hint and confirm with a status call.
📘 Give us a test endpoint early
A webhook URL is one of the five things to have ready. A temporary one is fine in sandbox — it only has to be HTTPS.
Status calls
Each API that can return PENDING has a status call: