Webhooks for payments: delivery you can trust
How to get told the instant money moves — and be sure the notification is real and never lost.
A webhook is an HTTP callback: when something happens — a payment completes, a return arrives — the platform posts an event to your endpoint. For payments, the quality of that delivery is not a detail.
Three properties that matter
- Durable. The event should be written in the same transaction as the change it describes, then delivered from an outbox — so a crash between "it happened" and "we told you" loses nothing.
- Signed. Each delivery carries an HMAC signature over the raw body. Verify it before you trust the payload.
- At-least-once. Retries and replays reuse the same event id, so you deduplicate and keep your handler idempotent.
Verifying signatures
Recompute the HMAC with your signing secret over the exact bytes received and compare in constant time — before parsing the JSON. During a secret rotation, accept the delivery if any of the comma-separated signatures matches.
On DigitalTreasury
Every event writes to an outbox and delivers signed, with retries and lossless secret rotation. See verifying webhooks in the docs.
Idempotency keys in payment APIs
How to retry a payment after a timeout without ever sending it twice.
ACH return codes explained (R01, R02, R03…)
Why a payment came back — and why 'insufficient funds' and 'account closed' should be different branches in your code.
What is embedded finance?
When the software you already use becomes where money moves — and what it takes to offer it.