Un webhook de pago retrasado o rechazado es primero un problema de observabilidad, no de “añadir más reintentos”. Hay que saber si el proveedor alcanzó el endpoint, si WordPress aceptó la petición y si el handler terminó.
Prueba el endpoint público
Comprueba DNS, TLS y HTTP desde fuera del hosting. Revisa redirecciones, WAF, modo mantenimiento y autenticación básica.
Separa rechazo del proveedor y fallo de aplicación
El panel de la pasarela suele mostrar código y reintentos. Un 403/401 apunta a seguridad/perímetro; un 500 a PHP/plugin; un timeout puede ser latencia aguas arriba.
Valida la firma
Confirma que el endpoint recibe el payload bruto que espera la pasarela y que proxy o transformaciones no alteran la verificación.
Haz los reintentos idempotentes
Un reintento debe actualizar el mismo pedido. Guarda event IDs del proveedor para que una entrega duplicada no duplique stock, notas ni emails.
Vigila antigüedad, no solo errores
Alerta si el evento pendiente más antiguo supera un umbral de negocio. Una cola puede estar “activa” y aun así llevar horas de retraso.
Para correlacionar sin datos sensibles, usa la guía de rastreo de pagos. Si hay cobro pero el pedido sigue pendiente, consulta el diagnóstico de estado pendiente.
Interpreta el patrón de respuestas antes de tocar el endpoint
Una serie de 403 apunta a una capa distinta que 504 intermitentes o 200 correctos seguidos de pedidos sin nota. Agrupa fallos por código, traza de perímetro y antigüedad del evento. El patrón suele indicar si debes empezar por WAF/proxy, PHP, latencia de cola o código de la pasarela.