> ## Documentation Index
> Fetch the complete documentation index at: https://docs.moduluslabs.io/llms.txt
> Use this file to discover all available pages before exploring further.

# Retries and Retriggering

> Handle duplicate, delayed, failed, and manually retriggered Payment Webhooks

Payment Webhooks use at-least-once delivery. A timeout or non-`2xx` response
is retried automatically on an exponential-backoff schedule.
Duplicate and out-of-order deliveries are possible.

## Retry schedule

Failed deliveries are retried with increasing delays. The platform uses exponential backoff with the following default intervals after the initial attempt:

| Attempt | Delay after previous |
| ------- | -------------------- |
| 1       | Immediate            |
| 2       | \~5 seconds          |
| 3       | \~5 minutes          |
| 4       | \~30 minutes         |
| 5       | \~2 hours            |
| 6       | \~8 hours            |

All attempts are exhausted within roughly **10 hours**. After the final attempt, the event stops retrying automatically. Use the [manual retrigger](#manual-retrigger) to redeliver it.

A delivery is considered failed when your endpoint returns a non-`2xx` status or does not respond within 15 seconds.

## Handling deliveries

Your endpoint should:

1. Verify the signature against the raw body.
2. Persist the event under a unique constraint on its envelope `id`.
3. Return `2xx` quickly after durable acceptance.
4. Process slow business work asynchronously.
5. Ignore a duplicate `id` without repeating side effects.

## Manual retrigger

`POST /v1/webhook_events/{id}/retrigger` resubmits the persisted canonical
payload. It does not rebuild or mutate the event. Ownership and API-key scope
checks still apply.

<Note>
  `SUBMITTED` means the event was accepted for delivery, not confirmed
  merchant receipt. See [Payment Webhooks overview](/docs/webhooks/payment/overview).
</Note>