Why does this protect my site?
When someone buys on your site, the payment processor (Stripe, PayPal, etc.) sends an automatic notice to your server confirming the payment (this is called a webhook or IPN). That notice doesn't come from a browser — it comes from a robot belonging to the processor itself, and your firewall, unable to tell it apart from an automated attack, can block it by mistake. If that happens, the customer already paid, but your site never finds out: the order stays pending forever.
How it protects you, step by step
- On every visit/request to your site, SeenSecure checks the real IP of whoever is making it.
- If that IP matches one you've added (e.g. a real Stripe IP) → that specific request is let through without applying the rest of the firewall.
- If it doesn't match any → it's treated as normal traffic, with no special treatment or privilege.
This IP check happens before any other firewall rule is evaluated — geo-blocking, rate limiting, blacklists, anti-injection protection, and so on. That's intentional: the payment notice shouldn't have to compete with those rules or depend on them being configured correctly. If the request's IP matches one of your processors, that specific request is exempted from the rest of the firewall pipeline for that single request; the rest of your traffic remains subject to exactly the same rules as always, with no changes.
Setting up your payment processors
✅ Automatic: Stripe, PayPal, Braintree, Razorpay
For these 4 widely-used processors we've already filled in the official IPs — you don't have to do anything, just click their button. Clicking the same button twice doesn't duplicate it, it updates the existing row.
✍️ Other processor (manual)
For the rest we deliberately preload nothing: no payment processor publishes a 100% complete and permanently stable IP list, and an incomplete or outdated list could leave a real payment blocked without you noticing — exactly the opposite of what we want. Add the IPs yourself, checking the processor's official documentation.
🚫 Square, Adyen, Mercado Pago, Authorize.net, GoCardless
Not offered here on purpose: these processors recommend in their own documentation verifying via cryptographic signature or dynamic DNS instead of fixed IP lists (their IPs change without notice). Checkout.com publishes IPs, but in a format that couldn't be safely verified — add it manually if you need it.
🛒 Who is each processor for?
You don't need to enable all four automatic buttons: it only makes sense to add the processor(s) your store actually uses. If you use WooCommerce, Easy Digital Downloads, or another WordPress e-commerce plugin, the processor you configured there is very likely one of these four — check your active payment gateway in your store plugin's settings before adding IPs here.
Stripe
Widely used in WooCommerce stores and SaaS businesses selling internationally. If your checkout shows the Stripe logo or you use the official "WooCommerce Stripe Payment Gateway" plugin, this is your processor.
PayPal
The most recognizable to end buyers, used by both small and large stores. It sends IPN (Instant Payment Notification) messages that your firewall may mistake for automated traffic if not on the trust list.
Braintree
Owned by PayPal, aimed at higher-volume merchants who need to accept card, PayPal, and digital wallets (Apple Pay, Google Pay) from a single integration. Common in larger WooCommerce stores.
Razorpay
Leading processor in India, widely used by stores and SaaS businesses selling to Indian customers who need local payment methods (UPI, wallets, local cards) in addition to international cards.
What it does NOT do (honest limitations)
- It does not replace the cryptographic signature verification ("webhook secret") your payment processor already offers — it's an additional layer, not the only defense.
- IPs can become outdated if the processor changes its servers without notice. SeenSecure does not control or guarantee that this data stays accurate over time — check your processor's official documentation from time to time.
❓ FAQ — Frequently Asked Questions
🔹 Do I need this if I don't sell anything on my site?
No. If your site doesn't process payments, this section doesn't apply — leave it disabled.
🔹 Does this make payments less secure?
No. It only affects whether the firewall blocks the request based on IP — it never touches the cryptographic verification your payment processor performs on its own (webhook secret), which remains your main defense against forged payment notices.
🔹 How do I know if a payment was blocked by this before enabling the bypass?
Check the firewall's Incidents section: if Stripe, PayPal, or another processor tried to notify a payment and got blocked, it will show up there with its source IP, the URL it tried to reach (usually your webhook endpoint, e.g. /wc-api/wc_stripe/ or similar), and the block reason. If you see repeated blocks from IPs matching the ones your processor's automatic button offers, that's a clear sign you need to enable this feature.
🔹 I use Redsys, iZettle, or another local processor not listed — what do I do?
Use "Other processor (manual)": create a row, name your processor, and paste the official IPs found in its technical documentation for developers (look for terms like "webhook IPs", "notification server IPs", or "server-to-server IPs"). Many regional processors like Redsys publish these ranges in the integration manual they gave you when you signed up as a merchant.
🔹 Do I need to re-check the IPs over time?
Yes, it's good practice. For the 4 automatic processors, if you notice payment confirmations starting to fail after a long time, click the corresponding button again — doing so updates the row with the latest list loaded in the plugin. For manual processors, check your processor's official documentation every few months or whenever you notice payments getting stuck for no apparent reason.