Reintentos y logs
Política de reintentos
Sección titulada «Política de reintentos»Si tu aplicación responde con cualquier código distinto de 2xx, o no responde dentro del timeout, Rapid considera el intento como fallido y vuelve a enviar el webhook.
Son 4 intentos en total: el inicial y 3 más, cada uno esperando más que el anterior.
- En el momento 1.er intento, apenas el evento entra en la cola
- +5 min 2.º intento, 5 minutos después de la falla anterior (5 minutos desde el inicio)
- +15 min 3.er intento (20 minutos desde el inicio)
- +30 min 4.º y último intento (50 minutos desde el inicio)
Si el 4.º también falla, la entrega se cierra y la alerta queda disponible en el panel para acción manual (ver Reenvío manual).
Timeout
Sección titulada «Timeout»Cada intento tiene un timeout de 30 segundos. Si tu aplicación no responde en ese plazo, el intento se considera fallido.
Qué cuenta como éxito
Sección titulada «Qué cuenta como éxito»Cualquier código 2xx: 200, 201, 202, 204 y los demás del rango. El cuerpo de la respuesta es opcional.
Cualquier otro código (incluidos 4xx y 5xx) dispara un reintento.
Redirección
Sección titulada «Redirección»Registra la URL final. Rapid trata las redirecciones así:
| Respuesta de tu URL | Qué pasa |
|---|---|
301, 302, 303 | Falla. Estos códigos cambian el POST por GET y descartan el cuerpo, así que seguirlos sería no entregar nada. El intento entra en el flujo de reintentos y el log muestra hacia dónde redirige tu URL. |
307, 308 al mismo dominio | Se sigue, con el POST, el cuerpo y los headers intactos. Hasta 3 redirecciones seguidas. |
307, 308 a otro dominio | Falla. El payload firmado no sale del dominio que registraste. |
Los casos comunes son que el servidor agregue / al final de la ruta y que cambie de dominio, como de ejemplo.com a www.ejemplo.com (que cuenta como otro dominio). En el log de entregas, el motivo empieza con [redirecionamento], junto con la dirección de destino.
Dirección que no es pública
Sección titulada «Dirección que no es pública»Si la dirección registrada no resuelve a una dirección pública de internet (apunta a una red local o privada, o el dominio no existe), la entrega falla sin ninguna solicitud y entra en el flujo normal de reintentos. En el log de entregas, el motivo empieza con [destino]. Corrige la URL o el DNS del dominio; ver Usa una dirección pública de internet.
Si el motivo empieza con [https], la URL registrada no usa HTTPS y Rapid no entrega en texto plano: registra una URL https://.
Si el motivo empieza con [assinatura], la falla es del lado de Rapid: la entrega no sale sin firma, y se reintenta automáticamente. No hace falta hacer nada en tu sistema.
Empresas bloqueadas
Sección titulada «Empresas bloqueadas»Si la empresa está bloqueada por falta de pago en Rapid, el flujo de webhooks sigue normal: las alertas se siguen recibiendo de los proveedores, guardando y entregando a la URL configurada. El panel sigue disponible. Lo que el bloqueo corta es la API por credencial (lectura y escritura: GET/PATCH /chargeback-alert/alerts, transacciones, merchants, alias heredados), que pasa a responder 403 COMPANY_BLOCKED, y la defensa de nuevas disputas.
Para dejar de recibir alertas nuevas, hay que desactivar el registro directamente en el proveedor (acción que realiza el equipo de Rapid).
Logs de entrega
Sección titulada «Logs de entrega»Cada intento se registra internamente con:
- Evento entregado (
chargeback_alert.received,dispute.fraud.revoke_access) - Fecha y hora del intento
- URL de destino
- Código HTTP de la respuesta
- Cuerpo de la respuesta (truncado en 1000 caracteres)
- Número del intento
Ves estos registros en el panel de Rapid en dos lugares: en Configuración › Webhook, en el Historial de entregas, las entregas más recientes; en Actividad, pestaña Webhooks, el historial completo para depurar fallas. Cuando la falla no llegó a tu servidor, el panel muestra una explicación del motivo; el texto original, que empieza con [https], [destino], [redirecionamento] o [assinatura], aparece al pasar el mouse.
Reenvío manual
Sección titulada «Reenvío manual»Cuando todos los intentos automáticos fallan, la alerta sigue en el panel. Para enviarla de nuevo, usa el botón Reintentar en el Historial de entregas, en Configuración › Webhook. La entrega reenviada llega como un webhook nuevo con el mismo alert_id, por eso la idempotencia es esencial.
El reenvío desde el panel vale para alertas. El evento dispute.fraud.revoke_access no tiene reenvío manual.