If you’ve ever set up Stripe webhooks and found yourself pulling your hair out over mysterious failures, you’re not alone. Many website owners who use Sucuri’s Web Application Firewall (WAF) have faced the same issue. Stripe keeps sending requests, but Sucuri keeps blocking them. This sounds like a showdown between two powerful security and finance giants – and spoiler alert: it’s all because of false positives.
TL;DR
Sucuri WAF sometimes mistakes Stripe’s webhook requests for malicious traffic. This results in blocked payments or failed backend processes. The problem can be fixed by whitelisting Stripe’s IP addresses in Sucuri’s dashboard. Once added, your webhook failures vanish like magic — no coding required!
The Headache of Broken Webhooks
Let’s say you’ve set up Stripe on your site. Everything is running smoothly. You’ve tested a few payments, and your confirmation emails are flying out like confetti.
Then, one day — your app stops updating. Maybe your orders aren’t getting processed anymore. Or a customer says they paid, but your admin dashboard knows nothing about it. The culprit? Webhooks are failing.
You log in to your Stripe dashboard, and there it is:
“Webhook failed: The endpoint returned a 403 Forbidden.”
Sounds scary, but we’ll break it down.
What is a Webhook Anyway?
A webhook is a way Stripe talks to your server. For example, when a payment is successful, Stripe sends a notification to your server with all the juicy details. Your server listens, drinks its coffee, consumes the data, and marks the order as ‘paid’.
But all of this depends on one key thing — Stripe being able to reach your server.
If something — like a firewall — slams the door shut, Stripe’s message never arrives.
Sucuri: The Security Superhero (With a Catch)
Sucuri WAF is awesome. It blocks shady characters, filters out brute force attacks, and stops known exploits before they do any damage. It sits in front of your website traffic like a digital bouncer, asking, “Are you on the list?”
But sometimes, it gets a little too paranoid.
Stripe’s webhook requests are sent from cloud servers, often using cURL or similar libraries. These can look suspicious — especially if they don’t include traditional browser headers. To Sucuri, they might resemble bots or scrapers.
So what does Sucuri do? It blocks them — completely unintentionally.
Why Does This Happen Randomly?
One of the weird things about this issue is that some Stripe webhooks go through, while others don’t. That’s because Stripe uses a huge pool of IP addresses to send requests. One day the request comes from IP A, which Sucuri is totally fine with. The next day it comes from IP B, which Sucuri blacklists or flags as high-risk. Boom — blocked!
That inconsistency is maddening.
Diagnosing the Problem
To confirm Sucuri is the issue, you can do this:
- Go to your Stripe dashboard.
- Click on Developers → Webhooks.
- Click to view failed events.
- Check the error code — if it’s 403 Forbidden or something similar, it’s likely a Sucuri block.
You can also check with Sucuri logs if you’re on a plan that gives you access to them. Look for blocked IP addresses around the time of the webhook failure. If the source matches Stripe’s known IP range, bingo.
The Fix: Whitelist Stripe’s IPs
Once you know Sucuri is the issue, you don’t need to ditch it — you just have to teach it to trust Stripe.
Stripe publishes a list of IP addresses that it uses to send webhooks:
These IPs change occasionally, so be sure to check the official list. At the time of writing, there are dozens of them.
How to Whitelist Them in Sucuri:
- Log into your Sucuri dashboard.
- Select the website that is receiving Stripe webhooks.
- Go to Access Control.
- Under Whitelist IP Addresses, paste the list of Stripe’s IPs.
- Click Save.
Note: Sucuri allows both individual IPs and CIDR ranges, so if Stripe gives you something like 192.0.2.0/24, you can enter it as-is.
Do You Need to Keep Updating It?
Unfortunately, yes — if Stripe changes their IP addresses, your whitelist needs to stay current. The good news? These changes don’t happen often. Maybe once a year. Bookmark the Stripe IP list and check it every few months just to be safe.
Bonus tip: Skip Sucuri For Webhooks Completely
There’s a sneaky workaround if you want to avoid whitelisting altogether.
If your site allows it, you can create a subdomain strictly for webhooks. Something like:
webhooks.yourdomain.com
Host this subdomain on a different server or behind a simple reverse proxy that doesn’t use Sucuri. Then, point Stripe to that path for webhooks. Since it’s away from the watchful eye of Sucuri, no firewall blocks will occur.
This is more technical, but it keeps your main site protected while letting Stripe play freely with your backend.
Some Real-World Weirdness
Here are a few fun examples of what people saw when Stripe got blocked:
- Webhooks working fine, but retrying endlessly.
- Only some types of events getting through.
- Erratic behavior depending on the time of day (due to changing IP origin).
This inconsistency made many users blame plugins, caching systems, or even Stripe’s own services before finding out the real issue was Sucuri. Trust us — you aren’t alone.
Final Thoughts
Sucuri and Stripe are both great tools. One protects your castle, and the other brings your gold. But sometimes, your bodyguard forgets to open the door for the treasure cart.
By adding Stripe’s trusted IP addresses to Sucuri’s whitelist, you get the best of both worlds — security without missed payments. Just keep that IP list updated, and you’re good to go.
Happy transacting — and may your webhooks be forever successful!