The browser passed the challenge twice

A hypothetical signup page displays a successful challenge. The backend trusts a browser boolean, so a scripted request sets that boolean directly. After you fix that, a network timeout during verification makes a legitimate retry fail as “token already used.”

The first bug trusted the wrong authority. The second forgot that verification is itself a distributed operation.

The browser carries evidence; the server evaluates it

Cloudflare documents Turnstile tokens as single-use with a 300-second lifetime and provides a validation idempotency_key for safe retries of validation. Google documents reCAPTCHA response tokens as single-use with a two-minute lifetime. Those limits are provider behavior, not your business-operation retention policy. Turnstile server validation, reCAPTCHA verification.

Managed challenges, interactive reCAPTCHA v2, and score-based assessments provide different evidence. A score is not permission by itself; choose thresholds per action based on observed outcomes. Do not claim knowledge of undocumented browser-fingerprinting internals or derive a universal bot probability from a vendor score.

A replay cache can create a new failure

A naive server marks a token spent before calling verification. The request times out. A retry finds the local marker and is rejected even if validation never completed. Moving the marker later permits concurrent attempts unless the rest of the protocol handles them.

Treat validation as a state machine tied to a stable signup intent:

Synthesizing vector architecture diagram...

Atomically claim work or join the existing intent; store the verified verdict and its scope so a retry can retrieve it. Bind token/verification evidence to that intent, not a global reusable “human” flag. Use the provider's validation retry mechanism where available. A verified token must not authorize unlimited new signup intents.

Then create the account and any local benefit under durable uniqueness. If email uniqueness matters across separate user records, enforce an authoritative unique email claim in the same transaction, not an eventually consistent secondary-index lookup. The challenge and the account's idempotency key solve different repetitions.

A provider outage must have a deliberate outcome

Bound verification time, connection use, and concurrency. A circuit breaker may protect local resources, but it does not decide the product's risk policy. Choose restricted access, deferred processing, an alternative verification path, or explicit refusal according to the action's risk. Unbounded fail-open behavior can turn the outage into free abuse; unconditional fail-closed can lock out everyone.

Do not log raw tokens or secrets. Restrict framing and origins appropriately, maintain server-side request validation, and consider token theft/replay independently of whether the browser UI looks secure.

Measure users, not just challenge passes

Test keyboard and assistive-technology flows, blocked scripts, privacy tools, low bandwidth, expiry while a user completes a form, and the alternative path. Avoid assuming a nonvisual or noninteractive check is frictionless for every user. Collect only necessary signals with a defined retention/use policy; legal conclusions require the actual deployment and jurisdiction, not a provider comparison table.

Track verification latency/error/unknown rates, replay attempts, retry recovery, legitimate completion, and downstream abuse after successful verification. Solving a challenge is evidence within a layered policy, not proof of a unique benign person.

Mental model: verification has an authority, a scope, a lifetime, and an uncertain-outcome path. Preserve all four through retries.

Transfer: one solved token, two accounts

Source trail: 28-cloudflare-turnstile-managed-challenges, 29-google-recaptcha-v2-and-enterprise-risk-analysis. See the source map for consolidation and reference-retained material.