Entrega y reintentos

Tonder da un evento por entregado cuando tu servidor responde cualquier 2xx en menos de 10 segundos. Si no, lo reintenta automáticamente —hasta 6 intentos en unas 8,5 horas— y tú puedes reenviar cualquier evento desde el registro de eventos.

Calendario de reintentos

Cada espera varía ±10% para no saturar tu servidor. Si el sexto intento falla, el evento queda Fallido.

Cómo lee Tonder tu respuesta

Un endpoint desactivado o eliminado no recibe reintentos: sus eventos pendientes quedan Fallidos como "Endpoint no disponible".

Reenvía eventos tú mismo

Un evento. En el registro de eventos, abre el evento y haz clic en Reenviar evento.

• Si el evento aún se estaba reintentando y el reenvío falla, conserva los intentos automáticos que le quedaban.
• Si ya estaba Fallido o Entregado, el reenvío es un solo intento.
• No se puede reenviar mientras un intento automático está a punto de enviarse (±1 minuto), ni dos veces en 30 segundos.

Todos los fallidos. Reintentar todos vuelve a enviar los eventos Fallidos del filtro actual —hasta 5,000, a un ritmo de 10 por segundo.

Los reenvíos manuales se suman al total de intentos, pero no a los 6 automáticos, así que un contador puede marcar 7/6.

Qué significa para tu integración

• Responde 2xx de inmediato y procesa después en tu propia cola —tienes 10 segundos.
• Deduplica con el header webhook-id. Un reintento o un reenvío trae el mismo webhook-id.
• No dependas del orden de llegada. Un payment_Pending reintentado puede llegar después de un payment_Success; usa el status y la fecha created del payload.
• Después de una caída, revisa el registro de eventos cuando tu servidor vuelva: lo que haya quedado Fallido se puede reenviar.

• Con Webhooks 2.0, deduplica con el header webhook-id — un reintento o un reenvío trae el mismo. Sin Webhooks 2.0, deduplica con id + event_type. Correlaciona con metadata.external_id, que se repite en cada evento de una transacción y funciona en los formatos Short + Long.
• Guarda los webhook-id procesados durante al menos 60 días —un evento se puede reenviar mientras se conserva.
• Mantén un índice idempotency_key en tu base de datos.
• En modo Híbrido, trata el par Pending + Success como intencional.
• Verifica siempre el estado final con GET /api/v1/transactions/{id}/.
• Maneja los cinco estados terminales de retiros — Success, Declined, Cancelled, Failed y Returned; Returned llega después de Success.

Sin Webhooks 2.0

Las cuentas en la versión anterior reciben cada evento una sola vez. La respuesta se registra, pero no dispara una nueva entrega:

Concilia consultando GET /api/v1/transactions/{id}/ para cualquier periodo en el que tu endpoint no estuvo disponible o devolvió errores, y si detectas eventos perdidos, contacta a soporte con el rango de fechas. Deduplica con id + event_type: metadata.external_id se repite en cada evento de la misma transacción, así que correlaciona pero no distingue Pending de Success.

Siguientes pasos