Operations & Hooks

Verification Outage Policy

Challenge allows a submission through when a token is present but the provider cannot verify it because of a qualifying server-side outage. This outage fallback is enabled by default for every provider and protected action.

Verification result	Default behaviour
Explicit connection failure, timeout or HTTP 500-599	Allow the token-bearing submission and record a fallback event
Missing or oversized token	Block
Rejected token, hostname/action mismatch or low reCAPTCHA score	Block
HTTP 4xx, TLS error, malformed response or unclassified failure	Block

Verification requests have a five-second timeout and do not follow redirects.

Browser-side outages still block submissions. Fallback requires a token: if the widget cannot load or issue one, the visitor cannot proceed.

Monitoring

Settings > Challenge shows the latest fallback event, not live provider health.

The PHP error log records each event's timestamp, provider, submission context and category (connection_failure or http_5xx). Tokens, credentials, provider messages and form contents are excluded. Use your usual PHP log collection and retention.

Filter Reference

challenge_allow_outage_fallback

Controls whether an otherwise qualifying transient verification outage may allow a submission. It has no settings-page switch.

Argument	Type	Description
$allow	bool	Defaults to true
$context	string	Protected action, such as gf_12 or wp_reset_request
$provider	string	cap, turnstile, recaptcha_v2 or recaptcha_v3
$reason	string	connection_failure or http_5xx

Disable fallback for the entire site from agency-managed plugin or theme code:

add_filter( 'challenge_allow_outage_fallback', '__return_false' );

Example: disable fallback for native WordPress registration only

add_filter(
	'challenge_allow_outage_fallback',
	static function ( bool $allow, string $context ): bool {
		return 'wp_register' === $context ? false : $allow;
	},
	10,
	2
);

This filter only controls qualifying outages. Returning true does not bypass rejected or missing tokens.

Troubleshooting

Symptom	Check
Setup notice or no widgets	The selected provider's required settings, including the Cap server URL
Cap widget cannot load or solve	Browser network errors, HTTPS, allowed origins, content security policy and Cap endpoint requirements
All verification attempts fail	Matching site/secret keys, correct endpoint, server connectivity and TLS trust
Turnstile/reCAPTCHA rejects an apparently solved widget	The returned hostname must match the WordPress home URL; v3 must also match the action and score threshold
Older browsers cannot solve Cap instrumentation	Ask the Cap administrator to provide the pako_inflate.min.js asset described below
A protected Gravity Form has no Challenge field	This is expected when automatic protection is enabled; the widget is inserted automatically
A custom form lacks a widget	Check supported forms. Creating WordPress users or orders does not automatically make a custom form compatible

After changing providers, purge relevant page/script caches and repeat the setup checks.

After updating Challenge, Gravity Forms or WooCommerce, retest the affected forms, including validation retries, Save and Continue and payment flows used on the website.

Cap Endpoint Requirements

Your configured Cap endpoint must provide the API and browser assets. If assets fail to load, share these requirements with whoever manages the service.

Cap server configuration

For Cap Standalone, enable asset serving in the Cap service's environment configuration, not WordPress:

ENABLE_ASSETS_SERVER=true

Recreate the Cap container after changing its environment. If asset serving is disabled, Challenge still requests the same URLs and they fail; it does not switch visitors to a CDN.

Requirement	Configuration
Browser assets	Serve /assets/widget.js, /assets/floating.js, /assets/cap_wasm_bg.wasm and /assets/hashwx.wasm
Asset versions	Pin WIDGET_VERSION and WASM_VERSION. HashWX needs WASM 0.0.8+
Older browsers	Host /assets/pako_inflate.min.js for instrumentation without DecompressionStream; Standalone does not supply it by default
Connectivity	Allow the website's origin and HTTPS access from both visitors and WordPress

Compatible hosted endpoints need the same assets. Cap Standalone's CACHE_HOST controls its server-side download source (default: https://cdn.jsdelivr.net); visitors fetch the cached assets from your configured Cap instance.

See Cap Standalone configuration for deployment and asset-cache troubleshooting.