What happens when merchants block all automated checkout flows?

Why blocking every automated checkout flow backfires

Automated checkout is not one thing. A blanket block treats high-risk bots and legitimate agentic traffic as the same class, so merchants may reduce some fraud pressure while also interrupting price comparison, delegated purchasing and repeat-order automation that customers increasingly expect. That usually shifts the problem from abuse prevention to conversion loss, support friction and poorer customer experience.

The practical issue is trust segmentation. If the policy cannot distinguish an unknown scraper from a verified purchasing assistant acting on a customer’s behalf, it becomes too blunt to support modern commerce flows. The better pattern is to define which automated sessions are allowed, under what consent, and with what limits on cart, payment and fulfilment scope.

What changes when you allow verified agent sessions

Verified agent sessions let merchants keep automation where it is useful and constrain it where it is dangerous. A verified session can be bound to a specific user, intent, merchant policy and transaction scope, so the automation is accountable instead of anonymous. That makes it possible to support repeat purchasing, travel booking, reordering and comparison workflows without opening the door to unrestricted abuse.

This is also where scope matters. A session that may browse inventory is not automatically entitled to place an order, change a shipping address or reuse payment credentials. Merchants should separate discovery, recommendation and purchase authority, because the security failure mode is usually not the bot itself, but the oversized privilege attached to the flow.

A useful reference point is Agentic Commerce for Merchants, which covers verified agents, scoped tokens and merchant controls for agent orders.

How merchants should set policy instead of using a total block

Risk-based policy works better than a universal deny rule. The merchant should decide what to permit based on identity confidence, intent signal, transaction value, velocity, device or session reputation, and whether the action is reversible. Low-risk actions can be allowed with lighter friction, while high-risk actions can require explicit confirmation, step-up checks or tighter limits.

The key design choice is consent plus containment. If a customer authorises an assistant, the merchant can still constrain the assistant to a narrow scope, short-lived session and observable transaction trail. If the merchant cannot verify the session, the safe response is to reduce capability, not necessarily to block all automation outright.

For the authentication and session layer, RFC 8693: OAuth 2.0 Token Exchange is relevant because delegated or on-behalf-of flows are often the cleanest way to express limited agent authority without handing over a full user session.

Risk and Threat Considerations

Blocking all automation can suppress abuse, but it can also drive legitimate customers toward less efficient workarounds while giving merchants a false sense of control. The harder problem is that automated checkout is attractive both to benign assistants and to attackers trying to mask fraud, accelerate card testing or exploit weak session handling.

Failure mechanism: If the merchant uses one undifferentiated rule for every automated request, it cannot tell trusted delegated activity from hostile automation, and the policy either overblocks or overpermits.

Impact: Overblocking reduces conversion and legitimate adoption, while overpermitting can expose inventory, payment, account and fulfilment workflows to abuse at machine speed.

Practitioner Guidance

What to prioritise: Separate browsing, ordering and payment authority in policy. The merchant should be able to say which automated action is allowed, which requires explicit user consent, and which must always be denied.

What to verify: Verify that the session is attributable to a specific customer or approved agent, that the scope is narrow, and that the transaction trail is preserved for dispute handling and abuse review.

Common mistake: Do not use bot blocking as a substitute for checkout governance. A block rule may reduce noise, but it does not create trust, consent or least privilege.

Practitioner takeaway: The right control is not “allow all bots” or “block all bots”, it is to make automated commerce explicitly scoped, observable and revocable so legitimate agents can operate without inheriting full purchase authority.

Related resources from NHI Mgmt Group

• How should merchants decide when to use 3D Secure in online checkout flows?
• What happens when merchants rely on guest checkout without strong fraud controls?
• What happens when merchants use only checkout-level checks and ignore account and network relationships?
• What happens when merchants try to stop policy abuse with too much checkout friction?