Delayed or rejected payment webhooks are an observability problem before they are a retry problem. First establish whether the provider could reach the endpoint, whether WordPress accepted the request and whether the gateway handler finished.
Test the public endpoint
Resolve DNS, TLS and HTTP from outside the hosting network. Check redirects, WAF rules, maintenance mode and basic authentication.
Separate provider rejection from application failure
Provider dashboards usually show response code and attempts. A 403/401 points toward edge/security rules; a 500 points toward PHP/plugin execution; a timeout may be upstream latency.
Validate signature handling
Confirm the endpoint receives the raw payload expected by the gateway and that proxy/body transformations do not break signature verification.
Make retries idempotent
A retry must update the same order and event record. Store provider event IDs so duplicate delivery cannot duplicate stock, notes or emails.
Monitor age as well as failures
Alert when the oldest unprocessed payment event exceeds a business threshold. A queue can be technically “running” while confirmations are hours late.
For safe identifiers and correlation, use payment tracing without card data. If the gateway is paid but the order is pending, follow the pending-order path.
Interpret response patterns before changing the endpoint
A sequence of 403 responses points to a different layer than intermittent 504s or clean 200s followed by missing order notes. Group failures by response code, edge trace and event age. The pattern usually tells you whether to inspect WAF/proxy rules, PHP execution, queue latency or gateway code first.