Un webhook de pagament endarrerit o rebutjat és primer un problema d’observabilitat, no de “posar més reintents”. Cal saber si el proveïdor ha arribat a l’endpoint, si WordPress ha acceptat la petició i si el handler ha acabat.
Prova l’endpoint públic
Comprova DNS, TLS i HTTP des de fora de l’allotjament. Revisa redireccions, WAF, mode manteniment i autenticació bàsica.
Separa rebuig del proveïdor i error d’aplicació
El tauler de la passarel·la sol mostrar codi i intents. Un 403/401 apunta a seguretat/perímetre; un 500 a PHP/connector; un timeout pot ser latència aigües amunt.
Valida la signatura
Confirma que l’endpoint rep el payload brut esperat i que el proxy o altres transformacions no trenquen la verificació.
Fes els reintents idempotents
Un reintent ha d’actualitzar la mateixa comanda. Desa els event IDs del proveïdor perquè una entrega duplicada no dupliqui estoc, notes ni correus.
Vigila l’antiguitat, no només els errors
Alerta si l’esdeveniment pendent més antic supera un llindar de negoci. Una cua pot estar activa i portar hores de retard.
Per correlacionar sense dades sensibles, usa la guia de rastreig de pagaments. Si hi ha cobrament però la comanda continua pendent, consulta el diagnòstic d’estat pendent.
Interpreta el patró de respostes abans de tocar l’endpoint
Una sèrie de 403 apunta a una capa diferent que 504 intermitents o 200 correctes seguits de comandes sense nota. Agrupa errors per codi, traça de perímetre i antiguitat de l’esdeveniment. El patró sol indicar si cal començar per WAF/proxy, PHP, latència de cua o codi de la passarel·la.