What matters first: The gateway or external service reached a URL but did not receive an authorised success response. The failure may occur in WordPress, basic auth, a WAF, CDN access policy or signature verification.
A 401/403 tells you where the callback was rejected
Whitelisting a provider’s entire traffic without confirming the response source can weaken the site and still leave invalid secrets.
Capture the response at every boundary
- Record the callback URL, method, headers, response body and source service.
- Determine which layer generated the 401/403 from headers and logs.
- Verify the webhook secret, signature algorithm and endpoint configuration.
- Check WAF, basic-auth and maintenance rules for the exact route.
Four places authentication can fail
- Wrong secret: The sender and receiver sign with different credentials.
- Header stripping: A proxy removes Authorization or signature headers.
- WAF rule: The JSON body or provider IP triggers a security policy.
- Endpoint permissions: The route requires a logged-in user or wrong capability.
Fix the narrowest failing layer first
- Recreate or rotate the webhook secret on both sides deliberately.
- Pass required headers through the proxy and server.
- Scope any WAF exception to the exact path, method and provider behaviour.
- Replay one signed test event and confirm the resulting WooCommerce state.
Secret mismatch or stripped headers?
First identify which layer generated the 401 or 403. If the request reaches WordPress with the expected signature headers, investigate the secret and endpoint verification. If those headers disappear before WordPress sees them, the proxy, CDN or web server is the fault boundary. Broad whitelisting before that distinction weakens security without fixing the actual failure.
For gateway-specific examples, compare a rejected callback with Stripe webhooks that do not update the order and PayPal payments whose WooCommerce order stays unchanged. The provider differs, but the useful boundary is the same: where the signed callback stops being accepted.
Keep the endpoint authenticated after the fix
Do not expose a webhook route without signature verification merely to obtain a 200 response.
Replay one signed event end to end
- Valid signed events return success.
- Invalid signatures and unrelated requests remain rejected.
- Order state changes once per event and is visible in logs.
Close the incident only after valid signed events succeed through the real production path, invalid signatures remain rejected, and one replayed event changes WooCommerce state no more than once.
WP REPAIR INCIDENT STANDARD
Reconstruct the incident before fixing it
Whitelisting a provider’s entire traffic without confirming the response source can weaken the site and still leave invalid secrets.
- 1
Record the callback URL, method, headers, response body and source service.
- 2
Determine which layer generated the 401/403 from headers and logs.
- 3
Verify the webhook secret, signature algorithm and endpoint configuration.
- 4
Check WAF, basic-auth and maintenance rules for the exact route.
What must be verified
- Valid signed events return success.
- Invalid signatures and unrelated requests remain rejected.
- Order state changes once per event and is visible in logs.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
If I whitelist the payment provider's IP range, will that fix the 401/403?+
Not reliably, and it can weaken security. Whitelisting a provider's entire traffic without confirming which layer actually generated the rejection can leave invalid secrets in place while broadening what's allowed through your firewall unnecessarily.
How do I know if the 401/403 is coming from WordPress itself or from a WAF/proxy in front of it?+
Determine which layer generated the response by examining the response headers and logs at each layer: WordPress, basic auth, a WAF, a CDN access policy and signature verification can all independently produce a 401 or 403, and the fix differs depending on which one is responsible.
Is it acceptable to just remove authentication on the webhook endpoint so it stops returning errors?+
No, this is explicitly warned against. Exposing a webhook route without signature verification merely to get a 200 response removes the check that confirms requests genuinely came from the payment provider, trading a visible error for a hidden security hole.
What's the safest way to confirm a fix actually works before trusting it in production?+
Replay one signed test event through the corrected configuration and confirm the resulting WooCommerce order state changes correctly, rather than assuming a fix works just because the endpoint stops returning errors.