Replay safety

Delivery is at-least-once. The same event_id reuses the event row. The initial delivery is unique per event and endpoint (ON CONFLICT DO NOTHING). A manual replay with a new Idempotency-Key inserts another row with delivery_kind=replay. Ordering across events is not guaranteed.

Treat id as the idempotency key in your system. A repeated POST with the same MuPag-Signature, the same X-Gateway-Event-Id, and the same body is the same fact, not a new event. X-Gateway-Signature carries the same HMAC-SHA256.

What the sender does not do

There is no global ordering. There is no fixed sender tolerance: the window, when you validate, is the verify argument. Tests use 300 seconds. Manual replay, issued from the account session, deduplicates the same Idempotency-Key for the same merchant, endpoint, event, and reason: the response returns the delivery already created. The key is at most 80 characters and is stored as a SHA-256 hash. The same key with different parameters fails. A new key creates another delivery of the same id.

The 10-failure / 1-hour circuit, the retryable statuses 408, 425, 429, and 500–599 (including transport 599), and abandonment of status 0 are described in Retries. The secret remains the whsec_ value returned once on creation or rotation.

checkout_session.completed is the completed-session type. checkout_session.paid does not exist.