If you see a dashboard notice that reads “Charitable has noticed some recent donation attempts via the donation form have failed due to invalid security checks,” 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 block real donors and needs your attention. The other is Charitable correctly blocking automated spam and is usually harmless. Before you change any settings, identify which one you are dealing with.

• What This Notice Means
• First, Identify the Cause
• Cause 1: Caching and Security Tokens (nonce_failed)
• Cause 2: Spam Bots Caught by the Honeypot (honeypot_failed)
• Dismissing the Notice
• Still Need Help

What This Notice Means

Every time your donation form loads, Charitable adds hidden security checks to make sure the submission is genuine. Two of those checks are:

• A security token (nonce) – a unique, time-limited code that proves the form was loaded normally and submitted from your site.
• A honeypot – a hidden field that real visitors never see or fill in. Automated bots routinely fill in every field they find, so a completed honeypot is a reliable sign of spam.

When either check fails, Charitable blocks that submission and records it. If enough blocked submissions happen in a short window, the dashboard notice appears. Because the notice uses the same wording for both checks, the only way to know what is actually happening is to look at which check failed.

First, Identify the Cause

Charitable logs every blocked submission so you can see the exact reason. To view the log:

1. In your WordPress admin, go to Charitable > Tools > System Info.
2. Find the Form Errors section, which shows the number of errors today and this week. You can also export the full log to a CSV file.
3. Look at the error code on each entry.

The error code tells you which path to follow:

• nonce_failed – the security token did not match. This is almost always a caching problem, and it can turn away real donors. Follow Cause 1.
• honeypot_failed – the hidden anti-spam field was filled in. This means an automated bot was blocked, not a real donor. Follow Cause 2.

Two context clues in each log entry help confirm the honeypot case: the submission usually comes from a logged-out visitor, and the user agent is often an outdated or automated browser rather than a normal, current one.

Cause 1: Caching and Security Tokens (nonce_failed)

If your log shows nonce_failed entries, the cause is almost always caching. When a page that contains a donation form is cached, visitors can be served an old copy of the page with an expired security token. The form then fails verification, and the donor sees: “Unfortunately, we were unable to verify your form submission. Please reload the page and try again.”

Other, less common causes are a conflicting plugin or theme, or an aggressive browser cache.

Work through these steps:

1. Check for caching plugins. Review whether caching is active, either through a plugin or through your hosting provider or CDN (such as Cloudflare).
2. Exclude your donation pages from caching. In your caching plugin or host settings, add the URLs of any page that contains a donation form (such as your campaign and donation pages) to the cache exclusion or bypass list. Exclude server-level and CDN caching as well, not just the plugin.
3. Test for plugin conflicts. If caching has been ruled out, temporarily deactivate other plugins (after taking a backup) to check whether another script is interfering with the form.
4. Clear your browser cache. This is separate from server-side caching and worth ruling out.

As a last resort, if your host cannot bypass caching on specific pages, a WPCode snippet can relax the form’s security check. This is not recommended and should only be used if the steps above are not possible: https://library.wpcode.com/snippet/7oq3yl5w/

Cause 2: Spam Bots Caught by the Honeypot (honeypot_failed)

If your log shows honeypot_failed entries, the news is good. These are automated spam bots that probed your donation form and were caught by the hidden honeypot field. Charitable blocked them before they ever reached your payment gateway. Your real donations are not affected, and no genuine donor is being turned away.

A small, steady trickle of blocked bots is normal for any public donation form, and it is enough to trigger the dashboard notice. In this case the notice is simply letting you know the protection is working.

You do not have to do anything. If you would like to cut down on the bot attempts, and how often the notice appears, add another layer of protection in front of the form:

1. Enable a CAPTCHA. Go to Charitable > Settings > Security and turn on one of the CAPTCHA options, such as Google reCAPTCHA or Cloudflare Turnstile. A CAPTCHA stops most bots before they can submit, which reduces these blocked attempts.
2. Turn on additional bot protection. In the same Security settings, you can enable extra measures such as the honeypot and time-trap bot protection, rate limiting, and email validation for stronger coverage.

Dismissing the Notice

The notice can remain for several days even after the underlying cause is addressed. It clears on its own once there are no new failures, and you can dismiss it manually at any time from the dashboard.

Still Need Help

If you have identified the error code and worked through the matching steps above and donations are still failing, contact Charitable support. It helps us if you include the error code from your Form Errors log (nonce_failed or honeypot_failed), since that tells us immediately which cause we are dealing with.