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.
What this symptom actually tells you
Whitelisting a provider’s entire traffic without confirming the response source can weaken the site and still leave invalid secrets.
Capture evidence before changing anything
- 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.
Most common causes
- 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.
Safe diagnostic and repair sequence
- 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.
How to choose between the likely causes
Do not treat Wrong secret and Header stripping as interchangeable. The sender and receiver sign with different credentials. By contrast, a proxy removes Authorization or signature headers. Use two checks to separate them: Record the callback URL, method, headers, response body and source service; and determine which layer generated the 401/403 from headers and logs. Those observations usually show whether the next safe move is to recreate or rotate the webhook secret on both sides deliberately or to preserve the current state and widen the investigation.
On a live store, reproduce the issue with a controlled test order and follow the same payment, stock, tax and notification path used by customers. Avoid changing several checkout components at once because that changes the application state and can obscure the original sequence of events needed to attribute the failure. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not expose a webhook route without signature verification merely to obtain a 200 response.
How to verify the repair
- Valid signed events return success.
- Invalid signatures and unrelated requests remain rejected.
- Order state changes once per event and is visible in logs.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
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.