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 y el equipo de Skip recibe una alerta interna. No hay más retries automáticos, pero una notificación fallida no pasa desapercibida: Skip puede repetirla una vez que tu endpoint se recupere — ver Replay.
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 entregas duplicadas — por ejemplo, cuando SkipPay te mandó un evento, tu endpoint timeouteó pero el procesamiento original tuvo éxito, y SkipPay reintentó. En esos casos el payload es idéntico al original (es la misma notificación re-enviada; Skip crea a lo más una notificación paid por orden). Haz tu handler idempotente: dedupe por la tupla (data.hash, data.status). Si ya procesaste esa combinación, trátala como no-op.
Replay después de los 6 intentos
Si te perdiste los seis por una caída más larga, pídele al equipo de Skip que repita. Ver Replay y debugging.