En esta página
Entrega y reintentos
Diseña para 11 intentos de entrega repartidos en unas 16 horas, deduplica eventos repetidos, revisa los fallos y reenvía tras la recuperación.
Si tu endpoint devuelve un estado fuera de 2xx o supera el tiempo límite de 10 segundos, Paymos reintenta con backoff exponencial (x2). Hasta 11 intentos en total (1 inicial y 10 reintentos) a lo largo de unas 16 horas.
Calendario del backoff
| Intento | Espera desde el anterior | Espera acumulada |
|---|---|---|
| 1 | inmediato | 0 |
| 2 | 1 min | 1 min |
| 3 | 2 min | 3 min |
| 4 | 4 min | 7 min |
| 5 | 8 min | 15 min |
| 6 | 16 min | 31 min |
| 7 | 32 min | ~1 hora |
| 8 | 1 hora | ~2 horas |
| 9 | 2 horas | ~4 horas |
| 10 | 4 horas | ~8 horas |
| 11 | 8 horas | ~16 horas |
Tras los 11 intentos, el evento se marca como fallido. Los eventos fallidos pueden reenviarse desde el panel: al hacerlo se reinicia el contador de intentos y el evento vuelve a la cola de entrega.
Idempotencia
La entrega es al menos una vez. Durante los reintentos las entregas duplicadas son normales, así que tu handler debe ser idempotente. Cada entrega lleva el mismo identificador estable en la cabecera X-Webhook-Id (y en el event_id del cuerpo), sin cambios entre reintentos y reenvíos: deduplica por él sin necesidad de analizar el cuerpo. Persiste los identificadores ya procesados y trata las repeticiones como un 200 OK sin efecto.
Qué cuenta como entrega correcta
- Respuesta HTTP
2xxen menos de 10 segundos → entrega correcta - HTTP
4xxo5xx→ cuenta como fallo, se reintentará - Conexión rechazada, fallo de DNS, error de TLS → cuenta como fallo, se reintentará
- Respuesta después de 10 segundos → cuenta como fallo, se reintentará (tu endpoint puede acabar procesando el duplicado igualmente)
Responde 2xx en cuanto el evento quede persistido de tu lado. Delega el procesamiento costoso a una cola en segundo plano para que el handler del webhook se mantenga por debajo del tiempo límite.