Verifying callbacks

Your resultUrl is a public endpoint — anything on the internet can POST to it. Treat the result callback as a signal that something changed, and confirm the actual outcome with Pesepay before you fulfil an order.

Caution

Pesepay does not currently sign callback payloads, and the body is not encrypted. Nothing in the request body alone proves it came from Pesepay, so the server-to-server confirmation in step 2 below is not optional — it is the verification step.

How to verify

1. Check the Authorization header. Pesepay sends your application’s own integration key in it. Compare it against the key you hold and reject the request if it doesn’t match — this filters out casual forged posts cheaply.

2. Confirm the outcome server-to-server. Take referenceNumber from the payload and call Check Payment Status. That response is authenticated with your integration key and encrypted with your encryption key, so it can’t be forged. Act on that status, not on the status in the callback body.

3. Match it to your own order. Look the referenceNumber up in your database. If you don’t recognise it, return 2xx and ignore it — never create an order from a callback you didn’t originate.

4. Check the amount. Compare amountDetails.amount and amountDetails.currencyCode against what your order expects before fulfilling.

Idempotency

Make the handler safe to run twice for the same referenceNumber — record which references you’ve already processed and short-circuit on a repeat. A duplicate delivery, a retried request from your own infrastructure, or a reconciliation job catching up can all deliver the same result more than once.

Note

On the rare occasion Pesepay can’t resolve the integration key for an application, the callback is sent without an Authorization header. If your handler rejects those outright, make sure your reconciliation job still catches the transaction.