WP Simple Pay Not Working? Here’s What’s Actually Breaking It (And How to Fix It)
WP Simple Pay is a solid plugin, but when it breaks, it’s rarely random. Almost every recurring issue traces back to one of three things: caching interfering with security tokens, JavaScript optimization stripping out required scripts, or a server that doesn’t meet the plugin’s baseline requirements.
The “Coupon Security Check Failed” and Nonce Errors
If you’re seeing “Coupon security check failed,” “Cookie nonce is invalid,” “Cookie check failed,” or rest_cookie_invalid_nonce, this isn’t a bug in the plugin. It’s a caching problem with a specific cause.
WordPress security tokens (nonces) are only valid for 12 hours. If a caching plugin or your host’s server-level cache stores a page containing a WP Simple Pay form and serves that cached version to visitors past the 12-hour mark, the form submits an expired token and Stripe rejects it.
The fix is to exclude any page containing a payment form from caching entirely, or set your cache expiration to under 12 hours. If your host manages caching at the server level (common with managed WordPress hosts), you’ll need to ask them to exclude your payment and checkout pages specifically — a caching plugin setting alone won’t override host-level caching.
WP Simple Pay Forms or Buttons stop working after an update
This is almost always a JavaScript optimization conflict, not a plugin conflict in the traditional sense. Speed plugins that minify, combine, or defer/async-load JavaScript can break WP Simple Pay’s frontend scripts because the plugin depends on specific files loading in a specific order.
If you’re running any of these, check their JS optimization settings first: Autoptimize, WP Rocket, SG Optimizer, WP-Optimize, or W3 Total Cache. The following files need to be excluded from minification, combination, and deferred loading, regardless of which plugin you use:
js.stripe.com/v3/simpay-public-shared.min.jssimpay-public.min.jsaccounting.min.jssimpay-public-pro.min.js
Add these as exclusions in your caching plugin’s JS optimization settings before assuming you have a plugin conflict. This alone resolves a large share of “the button doesn’t do anything” and “the form won’t submit” reports.
WP Simple Pay Payment Succeeds in Stripe But the Customer Sees an Error Page
This one causes panic because it looks like the payment failed when it actually didn’t. A customer completes a payment, Stripe shows it as successful in your dashboard, but instead of landing on your confirmation page, the customer sees a “NOT ACCEPTABLE!” error stating that an appropriate representation of the requested resource could not be found, generated by mod_security.
This is a server-level security rule (mod_security) blocking the redirect to your confirmation page after a successful charge — it has nothing to do with whether the payment worked. Check your host’s mod_security logs (most hosts expose these in cPanel or your hosting dashboard) for the specific rule ID that triggered, then ask your host to whitelist your confirmation page URL. Don’t refund or void the transaction based on this error alone; check Stripe first to confirm the charge actually went through.
“Works in Test Mode But Breaks in Live Mode”
This is common enough that it deserves its own troubleshooting path — see our dedicated guide on test mode vs. live mode issues for the full breakdown. The short version: WP Simple Pay lets every individual form override the global test/live setting, so a form can silently stay in test mode (or flip to live) independently of what your account-wide setting shows. This causes two very different symptoms depending on direction: forms that freeze or won’t accept card input when switched to live, or test transactions that unexpectedly charge real money.
Does WP Simple Pay Support PayPal?
No — WP Simple Pay processes payments through Stripe only, and only accepts card-based payment methods (plus Stripe’s supported wallets like Apple Pay and Google Pay). If you need PayPal as a payment option, WP Simple Pay isn’t the right tool; you’d need a plugin like Stripe for WooCommerce with a WooCommerce PayPal add-on, or a dedicated multi-gateway forms plugin instead.
Automation and Loyalty Plugin Integrations Not Firing
If you’re connecting WP Simple Pay to an automation tool (AutomatorWP) or loyalty/points plugin (myCred), and the integration silently does nothing after a successful payment — no points added, no automation triggered — this is a known integration gap rather than a WP Simple Pay bug. Both AutomatorWP and myCred rely on WP Simple Pay firing specific action hooks after a charge completes, and version mismatches between the addon and WP Simple Pay’s core have caused these hooks to stop firing correctly in the past.
Confirm you’re running the latest version of both the addon and WP Simple Pay itself, then test with a single simple form (no conditional logic) before troubleshooting further — narrowing to one form isolates whether it’s a hook issue or a form-specific configuration issue.
Connecting a Custom Button Instead of the Default “Pay Now”
If you already have your own call-to-action button and want it to trigger the WP Simple Pay form instead of using the plugin’s default “Pay Now” button, you don’t need custom code for the text itself — the button label is editable directly in the form builder’s Payment Button settings. If you want an entirely separate, pre-existing button element to open the form (an overlay-style trigger rather than an embedded form), that requires setting the form to Overlay type and linking your custom element to the form’s trigger class, which is a slightly different setup than a standard embedded form.
Finding the Real WP Simple Pay Error Instead of Guessing
Before deactivating plugins one by one, turn on WordPress debug logging. Add this to wp-config.php:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
This writes errors to /wp-content/debug.log without showing them to visitors. Reproduce the issue, then check the log for a PHP fatal error pointing to a specific file. If the issue is on the frontend (a button not responding, a form not loading), open your browser console (F12 → Console tab) instead — caching and JS optimization conflicts usually show up there, not in the PHP log.
Server Requirements Worth Checking First
A surprising number of “plugin conflicts” are actually server limits being hit. WP Simple Pay needs PHP 7.4 or higher (PHP 8.1+ is the safer target going into 2026), and while WordPress core runs on 64MB of memory, plugins like WP Simple Pay are more comfortable with 256MB or more available. Check your PHP version under Dashboard → Tools → Site Health. If memory looks tight, add this to wp-config.php:
define( 'WP_MEMORY_LIMIT', '256M' );
Test Changes on Staging, Not on the Live Checkout
If your site takes payments, testing plugin updates or new settings directly on the live site is a real risk — a broken checkout page means lost revenue, not just a cosmetic bug. Managed hosts like Kinsta, WP Engine, and Cloudways include one-click staging environments. If yours doesn’t, WP Staging or Duplicator Pro can build one manually. Make the change on staging, confirm forms still submit correctly, then push it live.
FAQ
Can cache plugins actually break WP Simple Pay, or is that overstated? No, it’s the single most common cause of nonce and coupon-check errors. It’s not occasional — it’s the default failure mode if payment pages aren’t excluded from caching.
Is it safe to deactivate and reinstall WP Simple Pay to fix a bug? Deactivating and reinstalling removes plugin files but typically leaves your form configurations and database entries intact, so reconnecting usually works without rebuilding forms from scratch. Back up first regardless — don’t skip this step on a site that processes payments.
What should I check before contacting WP Simple Pay support? Have your PHP version, WordPress version, active plugin list, and relevant debug.log entries ready. This is the information support will ask for first, and gathering it upfront usually cuts resolution time significantly.
Are the caching conflicts and support wait times worth switching plugins over? Based on user feedback across review platforms, the most common friction points are caching conflicts (fixable, as covered above), test-order setup confusion, and slower support response on complex issues — not fundamental reliability problems. For most sites, fixing the caching exclusions resolves the majority of reported “the plugin is broken” complaints without needing to switch tools.
Related Reading
Read our full WP Simple Pay review for pricing tiers, feature breakdown, and how it compares to alternatives before you commit. If a form works in test mode but breaks the moment you go live, our test mode vs. live mode troubleshooting guide covers that specific failure pattern in depth. If WP Simple Pay’s Stripe-only approach doesn’t fit your setup, SureCart and Stripe for WooCommerce solve the same problem with different tradeoffs. If your checkout pages are slow independent of these issues, WP Rocket is worth evaluating on its own caching merits (once configured with the exclusions above). And if odd behavior persists after ruling out caching and JS conflicts, it’s worth running a Wordfence scan — malware and unauthorized file changes occasionally masquerade as plugin bugs.
