Delivery and Retries

Tonder treats an event as delivered when your server answers any 2xx in under 10 seconds. If it doesn't, Tonder retries automatically — up to 6 attempts over about 8.5 hours — and you can resend any event yourself from the Events log.

Retry schedule

Each wait varies by ±10% so retries don't all land on your server at once. If the 6th attempt fails, the event is Failed.

How Tonder reads your response

A disabled or deleted endpoint gets no retries: its pending events end as Failed with "Endpoint unavailable".

Resend events yourself

One event. In the Events log, open the event and click Resend event.

• If the event was still being retried and your resend fails, it keeps the automatic attempts it had left.
• If it was already Failed or Delivered, the resend is a single attempt.
• You can't resend while an automatic attempt is about to go out (±1 minute), or twice within 30 seconds.

Every failed event. Retry all resends the Failed events that match the current filter — up to 5,000, at 10 per second.

Manual resends count toward the total attempts but not toward the 6 automatic ones, so a counter can read 7/6.

What this means for your integration

• Answer 2xx immediately, then process in your own queue — you have 10 seconds.
• Deduplicate on the webhook-id header. A retry or a resend carries the same webhook-id.
• Don't rely on arrival order. A retried payment_Pending can arrive after payment_Success; use the payload's status and created.
• After an outage, check the Events log once your server is back: anything left Failed can be resent.

• Dedupe on the webhook-id header with Webhooks 2.0 — a retry or a resend carries the same one. Without Webhooks 2.0, dedupe on id + event_type. Correlate with metadata.external_id, which repeats on every event of a transaction and works across Short + Long formats.
• Keep processed webhook-ids for at least 60 days — an event can be resent while it is kept.
• Keep an idempotency_key index in your DB.
• Treat duplicate Pending + Success in Hybrid mode as intentional.
• Always verify final status via GET /api/v1/transactions/{id}/.
• Handle all five withdrawal terminal states — Success, Declined, Cancelled, Failed and Returned; Returned arrives after Success.

Without Webhooks 2.0

Accounts on the previous version get each event once. The response is recorded, but it does not trigger a redelivery:

Reconcile by polling GET /api/v1/transactions/{id}/ for any period during which your endpoint was unavailable or returning errors, and if you detect lost events, contact support with the date range. Deduplicate on id + event_type: metadata.external_id repeats on every event of the same transaction, so it correlates but cannot tell Pending from Success.

Next steps