Your site is blocking the REST API
Stripe's deliveries all fail with 401, the message reads Only authenticated users can access the REST API, and the plugin says it is not connected. Nothing is wrong with Stripe or with the plugin: something on your site is turning away every visitor who is not logged in, before the plugin ever sees them.
How to recognise it
In Stripe, open Developers → Webhooks, click the endpoint for your site and look at a delivery. The response your site gave is shown underneath. This is the one:
{"code":"rest_unauthorized","message":"Only authenticated users can access the REST API.","data":{"status":401}}
The wording may be in your site's language (Seuls les utilisateurs authentifiés peuvent accéder à l'API REST, Nur authentifizierte Benutzer können auf die REST-API zugreifen) and the code may read rest_not_logged_in, rest_forbidden or rest_cannot_access. The shape is what matters: a 401 or 403, in WordPress's own JSON, before any plugin ran.
You can see it for yourself from any browser. Open https://your-site.example/wp-json/ in a private window. A healthy site shows a page of JSON describing its API. A site with this restriction shows the error above instead.
Since Bang! Cart 3.7.4 the plugin checks for this itself. Set up webhook automatically, Re-check only and Verify connection now each ask your site's own webhook address first, and if it refuses in this way the connection box says so and quotes the answer, with a link to this page.
Why it breaks the shop, not just the webhook
Stripe is not a logged-in user, so every event it sends is refused. That alone means no order emails, no stock changes and no discount redemptions counted, however correct the rest of the setup is. But the restriction does not stop at Stripe: your customers' baskets are priced, and their checkouts started, through the same REST API, as anonymous visitors. With the block in place a customer sees a basket that cannot show a total and a checkout button that does nothing. One setting, both problems.
What is doing it
WordPress does not ship with this restriction. One of these added it:
- A security plugin. Solid Security (formerly iThemes Security) has a REST API setting under Settings → WordPress Tweaks; set to Restricted Access it does exactly this. Plugins named Disable REST API, Disable WP REST API and the like do it on purpose. Wordfence, All-In-One Security and others have similar switches.
- A code snippet. A few lines in your theme's
functions.php, or in a code-snippets plugin, hooked onrest_authentication_errors. The message above is the stock text from the most widely copied one; if you search your site's files forrest_authentication_errorsyou will usually find it. - Your host or firewall. Some managed WordPress hosts and web application firewalls offer a "lock down the REST API" option, sometimes switched on by default on staging copies.
The fix
- Find the setting or snippet above and either switch the restriction off, or allow the
bangcart/v1namespace through it (andssc/v1if it lets you list more than one). Most security plugins have an allow list for exactly this; a snippet needs a line that lets requests whose route begins/bangcart/v1/pass. - Check
https://your-site.example/wp-json/bangcart/v1/webhookin a private window. It should now answer with a No route was found error (that address only accepts Stripe's POSTs, so a browser's GET is correctly refused with a 404) rather than the authentication message. - In Bang! Cart, open the Stripe tab and press Set up webhook automatically. If it reports that an endpoint for this site already exists, delete that endpoint in Stripe (Developers → Webhooks) and press the button once more, so the plugin can create a fresh one and keep its signing secret.
- Press Verify connection now. The box turns green when Stripe's test event arrives and its signature checks out. The failed deliveries listed in Stripe turn into 200s from that moment on.
Is it safe to allow? Yes. The plugin's routes were built to be public. The webhook accepts nothing that does not carry a valid Stripe signature, the basket routes price what they are sent and start a Stripe Checkout session - they cannot read orders, change settings or see keys - and every one of them is rate limited per visitor. Locking the REST API to logged-in users protects sites that expose data through it; this plugin exposes none.
If it still fails after that
A 401 or 403 that is not in the JSON shape above is something else: HTTP basic authentication on a staging site (Stripe cannot sign in), or a firewall or CDN challenging the request. For basic auth, Stripe supports it - put the username and password in the endpoint URL as https://user:password@your-site.example/wp-json/bangcart/v1/webhook. For a firewall, allow Stripe's published webhook IP addresses. In both cases the plugin's own check stays quiet, because it can only prove the WordPress case.
Still stuck?
Write to me and it is me who answers, not a ticket queue. Tell me what you expected and what happened instead.


