Skip to content

SAFE-105Beside the path

Checkout automation controls

Checks whether your checkout carries any anti-automation control — bot management, a captcha or turnstile widget, or a payment-provider anti-automation signal.

What we check

A presence check (not an enforcement test), run in the owner-requested safety test. We first use the bot-management and captcha fingerprints the crawl already recorded; only if there are none do we GET the checkout page once and look for a widget or header such as Turnstile, hCaptcha, reCAPTCHA, DataDome, PerimeterX, Kasada or Arkose, or a cf-mitigated / x-datadome header. It confirms a control is installed, not how strictly it is tuned.

Why it matters

Checkout is where money moves and where card-testing and automated fraud concentrate. Some control in front of it is the baseline defence; without one, automated abuse of the payment step is unhindered.

How we check

PASS: a bot-management or captcha control was fingerprinted passively, or found on the checkout page (a known widget in the first 8 KB of markup, or a control header). FAIL (MEDIUM): the checkout was read and no such control was detected. SKIPPED: there was no checkout page or passive fingerprint to inspect, or the checkout could not be read. One read-only GET at most.

How to fix it

  1. Put a bot-management or challenge control in front of checkout (for example Cloudflare Turnstile, hCaptcha or DataDome).
  2. Prefer an invisible or risk-based challenge so real shoppers and verified agents are not slowed.
  3. Confirm the control is actually served on the checkout route, not only on the marketing pages.

What good looks like

The checkout page includes a challenge widget:

<script src="https://challenges.cloudflare.com/turnstile/v0/api.js" async defer></script>
<div class="cf-turnstile" data-sitekey="..."></div>

or the response carries a bot-management header such as cf-mitigated or x-datadome.

Sources