Cloudflare Turnstile
Enhance enrolment security with Cloudflare Turnstile to verify human traffic.
Cloudflare Turnstile can be enabled to reduce automated enrolments and scripted abuse. When enabled, the enrolment form includes a Turnstile check and validates the resulting token server-side.
The implementation stays mostly invisible. Turnstile runs in the background and only becomes interactive when Cloudflare requires extra verification.
Bot detection cannot be 100% accurate. Turnstile provides basic bot mitigation, not a guarantee. AI-assisted automation and human-in-the-loop services make abuse increasingly hard to fully control. Cloudflare documents Turnstile’s approach here: Cloudflare Turnstile docs.
How it works
When the enrolment form loads, Turnstile runs in the background.
When the form is submitted, Turnstile may ask for an interactive check.
The Wallet Crew validates the Turnstile token server-side before accepting the enrolment.
Configuration
Configuration requires a Turnstile widget in Cloudflare and the widget keys. The Wallet Crew uses the Site key and Secret key to validate enrolment submissions.
Create and configure a Turnstile widget in Cloudflare
Create a Turnstile widget in the Cloudflare dashboard. Cloudflare provides a Site key (public) and a Secret key (private) for each widget.
Official setup guide: Cloudflare Turnstile “Get started”
Cloudflare dashboard entry point: dash.cloudflare.com (then open Turnstile)
The default configuration is usually sufficient. Please consult the brand IT team for any additional adjustments.
Notes
Turnstile is usually invisible because it runs in the background. An interactive check is only shown when Cloudflare flags the session as higher risk.
Token validation is always performed server-side by The Wallet Crew when the extension is enabled.
Limits and expectations
Turnstile improves baseline protection, but it does not “solve bots”. Automated abuse evolves quickly and often relies on AI-assisted tooling, residential proxies, and human-in-the-loop services. This makes perfect bot detection unrealistic for most public enrolment flows.
Cloudflare positions Turnstile as a frictionless alternative to CAPTCHAs, not as a guarantee that every bot will be blocked. Combine Turnstile with other controls when enrolment is business-critical.
Official documentation: Cloudflare Turnstile docs
Challenge cookie
After a successful Turnstile verification, the application can set a short-lived security cookie. This keeps bot-protection state between requests and reduces repeated Turnstile challenges during the same enrolment session.
How this cookie works:
The customer submits the enrolment form with a valid Turnstile token.
The server validates that token with Cloudflare.
If validation succeeds, the server issues a signed proof cookie.
On the next enrolment-related requests, the server checks that cookie.
If the cookie is still valid, the server can skip a new Turnstile challenge for that short window.
This behavior is configurable in Back Office:
Cookie validity is set in seconds, common value is 600 seconds (10 minutes)
When disabled, the server does not issue this cookie and Turnstile verification is required for each submission path.
Legal requirement: security cookie
This cookie should be listed in the cookie policy (often under “strictly necessary” / “security cookies”).
Cookie name:
neo.<tenantId>.turnstile-proofwhere<tenantId>is the identifier of The Wallet Crew tenantPurpose: Keep bot-protection state between requests and avoid repeated Turnstile challenges
Category: Security cookie (generally considered strictly necessary)
Lifetime: Configurable (seconds). Set to 0 to disable.
Scope: Enrolment form submission
Technical attributes:
HttpOnlySecureSameSite=LaxPath=/
This cookie is used only for security and fraud prevention, not for analytics or marketing.