Developers
Your endpoint will be down at some point
Not because you built it badly. Because everything is down sometimes, and a payment event system that assumes otherwise is one that loses records.
Every payload is signed. Verify it before trusting the contents.
At least once. Your handler must be safe to run twice.
Not guaranteed. Each event carries its own sequence and timestamp.
Exponential backoff until acknowledged or the window expires.
A 2xx response. Anything else is treated as not delivered.
Anything missed can be re-requested for a defined period.
See it live
The delivery contract, not just the promise
Signature, sequence, retry count and acknowledgement state travel with every event, so verifying a callback is a lookup rather than a guess.
An outage, end to end
What happens between your endpoint failing and your records being whole again
- 1
Detect
Deliveries start failing. Backoff widens rather than hammering an endpoint that is already struggling, which is the difference between a retry policy and a denial of service.
- 2
Queue
Events continue to be generated and held. Nothing is dropped because your endpoint is unavailable — the payment happened whether or not you heard about it.
- 3
Recover
When acknowledgements resume, the backlog is delivered in order of occurrence with the original timestamps intact.
- 4
Reconcile
Anything beyond the retry window can be replayed on request, so a long outage is recoverable rather than a permanent gap in your records.
FAQ
Payment callbacks: common questions
6 short answers to what teams ask before a demo.
Events are queued and retried with widening backoff. Nothing is dropped — the payment occurred whether or not you were reachable, and when acknowledgements resume the backlog is delivered in order of occurrence.
Yes, and you should assume it will. Delivery is at least once, which is the only honest guarantee over an unreliable network. Every event carries an identifier so your handler can recognise a repeat and treat it as a no-op.
Not guaranteed. Each event carries its own sequence number and timestamp, so ordering can be established at your end. Anything that promises strict ordering across a network is either buffering heavily or being optimistic.
Every payload is signed, and you verify the signature before acting on the contents. Accepting an unverified webhook is the single most common security mistake in payment integrations.
Yes, for a defined retention period. This is what makes a long outage recoverable rather than leaving a permanent hole in your records that has to be reconstructed by hand.
Deposit and withdrawal state changes, conversion completions, payout run outcomes and monitoring decisions. You subscribe per type, so a system that only cares about credits does not have to filter everything else.
Still have a question?
A specialist will answer it directly, with your set-up in mind.
Ask a specialistIs your handler safe to run twice?
It is the one question worth answering before any payment integration goes live, and the one most teams answer optimistically.