Política de retries
Seis intentos con backoff exponencial.
Si tu endpoint no devuelve 2xx (o no responde dentro del timeout), SkipPay reintenta con backoff exponencial.
Schedule
| Intento | Delay desde el anterior | Tiempo acumulado desde el primer envío |
|---|---|---|
| 1 | — | 0 |
| 2 | +1 minuto | ~1 min |
| 3 | +5 minutos | ~6 min |
| 4 | +15 minutos | ~21 min |
| 5 | +30 minutos | ~51 min |
| 6 | +60 minutos | ~1 h 51 min |
Después de 6 intentos fallidos, la notificación se marca failed en los registros de SkipPay. No hay más retries automáticos.
Timeout por intento
SkipPay espera hasta 10 segundos por la respuesta de tu endpoint. Después de los 10 segundos cuenta como fallo.
Si tu procesamiento es pesado, devuelve 200 de inmediato y procesa el evento en background. El receptor del webhook debería ser muy delgado.
Qué cuenta como éxito
- HTTP
200–299.
Cualquier otra cosa (incluido redirects) cuenta como falla y dispara el siguiente retry.
Idempotencia
De vez en cuando vas a recibir webhooks duplicados — por ejemplo, cuando SkipPay te mandó un evento, tu endpoint timeouteó pero el procesamiento original tuvo éxito, y SkipPay reintentó. Haz tu handler idempotente: dedupe por event_id (presente en cada payload) o por una tupla como (event, order_hash, paid_at).
Replay después de los 6 intentos
Si te perdiste los seis por una caída más larga, pídele a ops de Skip que repita. Ver Replay y debugging.