Skip to content

PATTERN Cited by 1 source

Bot score on checkout

Pattern

Emit a per-payment bot-likelihood score at the checkout surface, leaving enforcement policy (block, throttle, queue, require human verification, allow) to the merchant. The score itself is the deliverable; the merchant decides what to do with it given their inventory / promotional / business context.

This is distinct from bot-blocking patterns that hard-block detected bots — those work for the human-vs-bot frame but break in the agentic-commerce era when some non-human checkout traffic (legitimate AI agents acting on a buyer's behalf) is wanted, not unwanted.

Canonical wiki instance

systems/stripe-radar at 2026-05-27 on systems/stripe-checkout (sources/2026-05-27-stripe-expanding-stripe-radar-to-protect-more-of-your-business):

"Radar now assigns a bot score to payments made on Stripe Checkout, evaluating the likelihood that they were made by a malicious bot. You can use this score to enforce anti-scripting or anti-bot policies. For example, you could block automated purchases of limited-edition items or flag high-velocity orders for review."

Why score-not-decision

The agentic-commerce era's hard problem is that legitimate AI agents and malicious bots are both nonhuman traffic — see concepts/agentic-commerce-bot-score. A merchant's desired enforcement policy depends on context the fraud-detection system can't see:

  • Limited-edition inventory — block all bots, since an authorised agent buying a limited drop on a customer's behalf is acceptable to some merchants and not others.
  • Promotional pricing — flag for review but don't block, since the merchant may want to allow agentic purchases at promotional prices.
  • Routine restocking — ignore the score, since bot traffic here is harmless or even desirable.

The score-not-decision shape lets merchants calibrate enforcement to their inventory and promotional context without the fraud-detection vendor having to model every merchant's policy.

Action surface

The post enumerates two example actions:

  • Block automated purchases of limited-edition items — hard-block on high bot scores at limited-inventory products.
  • Flag high-velocity orders for review — soft-flag for human investigation.

The merchant can compose any policy: if score > 0.9 AND product.is_limited then block; if score > 0.7 AND order_velocity > N then queue; if score < 0.3 OR has_authenticated_agent_identity then allow.

Sibling patterns

  • concepts/adaptive-bot-reclassification — bot-detection feedback loop that evolves classification as new bot populations emerge. This pattern is the emit-side; adaptive-reclassification is the calibrate-side.
  • Hard-block-detected-bots — the pre-agentic alternative; appropriate when bots are uniformly unwanted.

Required substrate

  • Real-time bot-classification model at the checkout surface — must score every payment as it's submitted.
  • Method-orthogonal signal collection — IP, device, behavioural signals captured at checkout.
  • Score-exposing API to merchants — the score is a prediction, not a decision; merchants need to read it.
  • Authoring tools for merchant policies — given the score, merchants need a way to express if X then Y on it.

Caveats

  • Disambiguation signal mix not disclosed in the canonical instance. What separates legitimate agents from malicious bots when both are non-human?
  • Score calibration not described — is 0.5 the decision boundary? The post just says "likelihood."
  • No quantitative outcome disclosed for the new pattern at the canonical instance.

Seen in

Last updated · 542 distilled / 1,571 read