If you see a dashboard notice titled “Donation form errors detected,” this guide explains what it means and how to resolve it.

The important thing to know first is that this single notice can point to two very different situations. One of them can stop real donors from paying by card and needs your attention. The other is Charitable noticing automated crawlers, and it is harmless. Before you change any settings, identify which one you are dealing with.

• What This Notice Means
• First, Identify the Cause
• Cause 1: An Optimization Plugin Is Blocking the Payment Script
• Settings Location by Plugin
• Cause 2: Search Engine and Social Crawlers
• Update to the Latest Version
• Dismissing the Notice
• Advanced: What Charitable Excludes Automatically
• Still Need Help

What This Notice Means

To take a card payment, your donation form relies on a small script loaded directly from your payment provider in the visitor’s browser. Stripe loads js.stripe.com, PayPal loads the PayPal SDK, and Square loads the Square Web SDK. That script is what draws the secure card fields and sends the payment to the provider. If it is missing, the card fields cannot appear and the donation cannot be completed.

Charitable watches each donation page as it loads. If the required payment script was not present, it records the event and, if enough are recorded, raises this notice. The notice also lists any caching or optimization plugins it detected on your site, which is your first clue to what happened.

There are two common reasons the script goes missing, and they call for very different responses.

• A caching or optimization plugin cached, combined, minified, or delayed the page’s JavaScript so the payment script never ran. This can turn away real donors and needs fixing.
• Search engine and social media crawlers visited your donation pages. They read the page but do not run payment scripts the way a real browser does, so the check records a miss even though no real donor was affected. This is harmless.

First, Identify the Cause

Charitable logs every recorded event so you can see exactly what happened. To view the log:

1. Click Review the log on the notice, or go to Charitable > Tools > Logs in your WordPress admin. You can also see a summary under Charitable > Tools > System Info in the Form Errors section.
2. Find the entries with the error code gateway_sdk_not_loaded. You can export the full log to a CSV file if you prefer to review it in a spreadsheet.
3. For each entry, look at the visitor’s user agent (the browser that loaded the page).

The user agent tells you which path to follow:

• A normal, current browser (Chrome, Safari, Firefox, or Edge on a phone or computer) means a real visitor may have been affected. Follow Cause 1.
• A search engine or social crawler (for example bingbot, Googlebot, meta-externalagent from Facebook, or OAI-SearchBot from OpenAI) means an automated bot tripped the check, not a donor. Follow Cause 2.

If every entry is a crawler and your donations are otherwise coming through normally, you are almost certainly looking at the harmless case in Cause 2.

Cause 1: An Optimization Plugin Is Blocking the Payment Script

If your log shows normal browsers, the cause is almost always a caching or optimization plugin. Three features in particular can withhold the payment script from a donation page:

• Full-page caching can serve a stored copy of the page that was built without the payment script.
• Minify and combine JavaScript can break the order the payment script needs to load in.
• Delay or defer JavaScript (sometimes called “load JavaScript on interaction”) holds scripts back until the visitor clicks or scrolls, so the payment script is not ready when the form needs it. This is the most common culprit.

The fix is to tell your optimization plugin to leave the donation pages and the payment scripts alone. Apply all three of these:

1. Exclude your donation pages from full-page caching. Add the URLs of every page that contains a donation form (your campaign pages and donation pages) to the cache exclusion or bypass list. If your host or CDN also caches pages, exclude them there too.
2. Exclude the payment scripts and Charitable’s scripts from minify and combine. Use the values listed below.
3. Exclude the same scripts from delay or defer JavaScript. This is the step most often missed, and usually the one that fixes it.

In most optimization plugins you can paste the following into the relevant exclusion or “do not optimize” fields. You do not need to be exact, matching any part of the script address is enough:

js.stripe.com
www.paypal.com/sdk
paypalobjects.com
web.squarecdn.com
js.squareup.com
charitable
charitable-pro
CHARITABLE_VARS

After saving, clear your optimization plugin’s cache, then open a donation page in a private or incognito browser window and confirm the card fields appear and a test donation works.

Settings Location by Plugin

Where these options live depends on the plugin. The common ones are below. For WP Rocket and WP-Optimize, Charitable already applies these exclusions for you, so you normally do not need to change anything there.

WP Fastest Cache

On the Settings tab, review Minify JS, Combine JS, and Render Blocking JS, and turn them off for testing if needed. If you use the premium Delay JS feature, add the values above to its exclusion list. Under Exclude > Exclude Pages, add your campaign and donation page URLs so they are never cached, and under Exclude > Exclude JS, add the values above. Clear the cache from the Delete Cache tab afterwards.

WP Rocket

Charitable automatically excludes the payment scripts and its own files from WP Rocket’s minify, combine, and Delay JavaScript Execution, so this usually needs no action. If you still see an issue, confirm nothing is manually re-adding the Charitable or payment scripts, and under Advanced Rules > Never Cache (URLs) add your donation page URLs.

LiteSpeed Cache

Under Page Optimization > JS Settings, add the values above to JS Excludes and, if you use it, to Guest Mode JS Excludes and the Localization or defer exclusions. Under Cache > Excludes, add your donation page URLs to Do Not Cache URIs. Purge all caches afterwards.

WP-Optimize

Charitable automatically adds the payment scripts and its own files to WP-Optimize’s minify and combine exclusions, so this usually needs no action. If needed, you can confirm them under WP-Optimize > Minify > JavaScript in the exclusions list, and exclude donation pages from caching under WP-Optimize > Cache > Advanced settings.

Autoptimize

Under Settings > Autoptimize > JavaScript Options, add the values above to Exclude scripts from Autoptimize. If you use the “Enable 100% JavaScript optimization” or any defer option, make sure these exclusions still apply. Autoptimize does not cache pages itself, so pair it with your page-cache plugin’s exclusions.

W3 Total Cache

Under Performance > Minify, add the values above to the JS Never minify the following JS files list, and under Performance > Page Cache > Advanced add your donation page URLs to Never cache the following pages.

FlyingPress

Under Settings > JavaScript, add the values above to the Exclude from Lazy Load and Exclude from Delay lists. Under Settings > Cache, add your donation page URLs to the exclusions. Purge the cache afterwards.

WP Super Cache

WP Super Cache does not minify or delay JavaScript, so the fix here is caching only. Under Settings > WP Super Cache > Advanced, add your campaign and donation page URLs to Accepted Filenames & Rejected URIs so they are not served from the cache.

Cache Enabler

Cache Enabler is a page cache only. Under Settings > Cache Enabler, add your donation page URLs to the Cache Exclusions (post IDs or page paths) so they are always served fresh.

Other tools follow the same idea. In SiteGround Optimizer, turn off or exclude the Charitable and payment scripts under the JavaScript options and avoid combining them. In Cloudflare, disable Rocket Loader for your donation pages (Cloudflare’s Rocket Loader defers JavaScript and can hold back the payment script), and if you use Automatic Platform Optimization (APO), exclude the donation pages.

Cause 2: Search Engine and Social Crawlers

If your log entries are all crawlers, the news is good. Search engines and social platforms fetch your donation pages to index them or build link previews, but they do not run the payment script the way a real browser does. The check sees the script missing and records it, even though no genuine donor was affected and nothing on your site is broken.

A steady trickle of crawler visits is normal for any public donation page, and it is enough to keep the notice showing. Your real donations are not affected, and no donor is being turned away.

You do not need to change any caching settings for this. The best step is to update Charitable, as described next. Newer versions recognise crawlers and stop counting them, so these entries no longer trigger the notice.

Update to the Latest Version

Whichever cause applies to you, updating Charitable to the latest version is worthwhile. Go to Plugins > Installed Plugins and update Charitable. Recent versions:

• Load the Stripe script across the site, so it is far less likely to be stripped from a cached donation page.
• Automatically exclude the payment scripts from popular optimization plugins.
• Recognise search engine and social crawlers, so they no longer trigger false alarms.
• Point this troubleshooting guide at the correct address (older versions linked to a page that no longer exists).

Dismissing the Notice

The notice can remain for a few days even after the cause is addressed. It clears on its own once there are no new recorded events for 24 hours, and you can dismiss it manually from the dashboard at any time.

Advanced: What Charitable Excludes Automatically

For WP Rocket and WP-Optimize, Charitable automatically excludes the payment SDKs and its own scripts from minify, combine, and delay-JavaScript, so you normally do not need to configure anything there. For other tools, exclude the following by hand.

• Payment provider script hosts: js.stripe.com, www.paypal.com/sdk, paypalobjects.com, web.squarecdn.com (and sandbox.web.squarecdn.com in test mode), js.squareup.com.
• Charitable’s own scripts: any file under /wp-content/plugins/charitable/ or /wp-content/plugins/charitable-pro/, and the script handles charitable-script, charitable-stripe, charitable-paypal, charitable-square, and charitable-universal.
• Inline configuration variables: CHARITABLE_VARS, CHARITABLE_STRIPE_VARS, CHARITABLE_PAYPAL_VARS, CHARITABLE_SQUARE_VARS.

Still Need Help

If your log shows normal browsers and donations still fail after excluding the scripts, contact Charitable support. It helps us if you include the error code from your log (gateway_sdk_not_loaded), the payment gateway you use, and the caching or optimization plugins listed in the notice. That tells us immediately where to look.