Consider a hypothetical limited-release launch. A footwear retailer sells its online allocation within minutes, the launch page records its highest traffic of the year, and the merchandising team calls it a success.
Later, the team finds orders going to near-identical addresses, a burst of declined payment authorisations, and complaints from loyalty members who couldn’t buy. The product appears on resale marketplaces at a markup.
The sales dashboard recorded the purchases correctly. It couldn’t show whether the launch reached its intended customers or what the retailer would spend on payment fees, order reviews, and support.
Ecommerce bot management helps retailers investigate and control the automated activity behind those costs.
Key takeaways
- Manage automation by its actions. Permitted crawlers, approved integrations, and authorised shopping agents need different treatment from scrapers and scalpers.
- Keep order-risk checks. Payment screening, account protection, and order review remain necessary after a request passes a bot check.
- Investigate unusual traffic before blocking it. Check which legitimate customers a proposed rule would affect.
- Measure legitimate sales retained. Track completed orders, fraud losses, and customer friction alongside blocked requests.
What Ecommerce Bot Management Protects
hCaptcha defines bot management as detection, decision-making, response, and monitoring. That means recognising automated requests, deciding what each request may do, applying a proportionate response, and checking whether the policy worked.
Identifying automation and permitting an action are separate decisions. A price-comparison crawler, a marketplace integration syncing stock, and a script buying out a launch are all automated. Their purpose, permissions, and behavior should determine what they can do.
The 2026 Thales Bad Bot Report attributes 40% of internet traffic to bad bots in its full-year 2025 analysis. That vendor research provides context, not an estimate of what reaches a particular storefront. A limited-release checkout can face different traffic from a catalog page, so retailers need their own measurements.
Useful automation. Search crawlers, affiliate feeds, approved comparison engines, and order-management integrations can support discovery and sales. Shopping agents may also act for customers. These requests should be allowed within their approved scope; recognising an agent’s identity alone doesn’t establish that every action is safe.
Abusive automation. Scraping can extract catalog data against store policy. Cart hoarding can hold stock away from paying customers. Credential stuffing targets accounts, while card testing abuses the payment endpoint. Each calls for a different response.
Revenue protection. Set policies that allow approved activity, verify uncertain requests, and stop abusive actions before they take stock, data, or money. Monitor the effect on legitimate orders as well as the traffic stopped. A rule that catches more automation while preventing customers from checking out needs adjustment.
Map Bot Abuse to Revenue at Risk
Abuse takes different forms across the shopping journey. The table connects common patterns to signals a revenue team can investigate and the costs it should measure.
| Journey stage | Abuse pattern | Observable signal | Business consequence |
| Catalog and search | Scraping of prices, stock, and product data | Heavy page requests with little add-to-cart activity | Competitor repricing; infrastructure cost without sales; distorted demand data |
| Cart and inventory | Cart hoarding and automated buying of limited releases | Rapid stock reservations; carts abandoned at expiry; clustered delivery details | Stock held from paying customers; sales diverted to resellers |
| Account and loyalty | Credential stuffing against customer logins | Repeated login attempts across accounts with a low success rate | Stolen loyalty balances; misuse of stored payment methods; recovery costs |
| Payment | Card testing at checkout | Bursts of small authorisations, mostly declined, often from new or guest accounts | Authorisation and dispute fees; payment-processing workload |
Separate cart hoarding from completed scalping when investigating a launch. Hoarding reserves inventory without a purchase, potentially keeping it unavailable until interested customers leave.
Scalping produces completed orders but can prevent intended customers from buying. Its longer-term effect on repeat purchases and loyalty requires evidence beyond the launch’s sales total. Netacea’s retail materials identify automated inventory hoarding as a distinct protection use case.
Credential stuffing has a specific meaning. OWASP defines it as using known, breached username-and-password pairs against other websites. It differs from random password guessing and can threaten loyalty accounts that hold stored value.
Card testing uses checkout to test stolen card details. Stripe’s documentation notes that this activity can create authorisation fees under some pricing arrangements and dispute fees, apart from goods lost.
Declined attempts can therefore create costs even when no order ships, which is why the payment infrastructure behind checkout needs as much attention as the storefront.
Marketing data. Non-human sessions can inflate traffic and distort conversion rates and campaign reporting. Treat this as a data-quality issue alongside order fraud. Filtering reports doesn’t prevent store access, and blocking new abuse doesn’t repair historical reports.
Each signal in the table warrants investigation. Before enforcing a rule, check whether approved integrations, promotions, or legitimate customer behavior could produce the same pattern.
Set Policies by Journey Stage and Action
A single human-or-bot verdict applied across the site can create unnecessary friction or leave sensitive actions exposed. Choose a response based on what the request is trying to do and the evidence available.
| Response | Apply when | Example |
| Allow | Permitted crawler, approved integration, or agent acting within its authorised scope | Search indexing; a marketplace stock sync |
| Observe | Unusual activity without evidence of abuse | A new client browsing the catalog at a steady pace |
| Rate limit | Request volume exceeds the permitted pace for that action | Repeated product-page requests beyond an agreed limit |
| Verify | A sensitive action requires more confidence in the actor | Reserving a limited release; changing account details |
| Block | Evidence supports an abusive classification | A pattern tied to card testing or account takeover |
Request scores can help inform these decisions. Cloudflare’s Bot Management for Enterprise assigns requests scores from 1 to 99; its documentation says scores below 30 are commonly associated with bot traffic.
That association is product-specific. Retailers should test thresholds against their own traffic rather than copy them into another system. Checkout and catalog policies may also need different thresholds.
Protect discovery. Keep catalog access available to approved search crawlers, comparison engines, and integrations. Set rate limits around their expected activity, then check that the limits distinguish unwanted bulk collection from legitimate browsing. A traffic spike alone doesn’t establish scraping.
Protect scarce stock. An actor permitted to browse prices may need verification before reserving a limited item. Check reservation volume, account relationships, and whether carts convert to orders. Releasing abandoned reservations and limiting repeated attempts address a different problem from reviewing completed reseller purchases.
Verify sensitive actions. Logins, stored-payment updates, and high-value checkouts deserve policies suited to their risk. Apply additional checks where the evidence supports them, and monitor whether those checks prevent legitimate customers from completing the action.
Authorised shopping agents also need action-specific permissions. Visa introduced Trusted Agent Protocol on October 14, 2025, making it available through its Developer Center and GitHub as a framework for agent verification.
That announcement doesn’t establish support by every retailer. DataDome’s Agentic Trust documentation cautions that even strongly authenticated agents can be used for fraud. Verify identity, define permissions, and assess transaction risk separately.
CHEQ describes classifying bots by entity type and intent, which can support policies like those above. Its Retail ecommerce overview is one commercial option to evaluate for distinguishing permitted browsing from actions that require limits or verification; test whether its classifications give the team enough information for those decisions.
Keep Fraud Controls Behind the Checkout
A bot check assesses automation, not whether an order is legitimate. A person can use a stolen card, while an authorised shopping agent can place a valid order. Payment-risk decisions need their own controls, with bot signals contributing context.
Review the available controls with your payment provider. Discuss limits on repeated payment attempts and account creation, the provider’s risk signals, and restrictions on endpoints experiencing abuse.
Confirm what customer, session, and device context your integration supplies. Treat these as options to assess for your store rather than settings to copy without testing.
Account protection belongs in the same review. OWASP advises using an independent authentication factor: adding a security question to a password doesn’t constitute multifactor authentication.
A credential-stuffing attacker may already possess the correct password, so another knowledge-based secret offers a different level of protection from an independent factor.
Some checks will be unavailable for legitimate buyers. Stripe notes that address verification isn’t supported by every card issuer or country. For an international retailer, an unavailable check is missing information rather than evidence of fraud. Test how a proposed rule would affect customers across markets before declining orders on that basis.
Define which order attributes trigger manual review, who reviews the order, and how quickly they must respond. Support staff also need a recovery process for customers caught by a control, including a way to release a held order and record why the rule misfired.
CHEQ also describes transaction-fraud capabilities that address automated and human-driven threats across the customer journey. That scope makes it relevant to a combined bot and payment-risk assessment.
Evaluate how its signals would support your existing review process and payment-provider tools; a capability description doesn’t establish a measured prevention rate.
Choose Coverage That Fits Your Store
Begin procurement by documenting existing controls and the abuse they leave uncovered. Compare vendors against those gaps, including who will run the controls after deployment.
Start with existing controls. Shopify’s documented bot-protection feature is restricted to Plus merchants. It supports scheduled events lasting up to 60 minutes, covering up to 500 individual products or all products, with one event scheduled at a time.
Those limits apply to that feature, not every security protection on the platform. Check whether event-based coverage meets the need or whether protection must also operate between launches.
Infrastructure products also differ. Cloudflare distinguishes Bot Fight Mode, Super Bot Fight Mode, and Bot Management for Enterprise. Confirm the controls included in the product and plan you’re assessing rather than assuming all bot-protection options provide the same scoring and policy features.
Check the relevant surfaces. Ask vendors to demonstrate coverage on your storefront, public and partner APIs, mobile experience, and payment integration. Record any gaps and how they would be covered. Protection demonstrated on a browser storefront doesn’t establish compatibility with every other route into the business.
Require explainable decisions. Ask how the system identifies approved crawlers and integrations, defines agent permissions, and reports allowed, challenged, and blocked activity. Your team needs enough detail to investigate a decision and adjust a rule when legitimate traffic is caught.
Confirm deployment and ownership. Establish where the control runs, who maintains the policy, and who can change or disable a rule during an incident. Include support staff in the escalation process.
CHEQ’s retail ecommerce overview describes surfacing the requesting entity, authenticity signals, and an intent classification. Those capabilities can inform different policies for shoppers, permitted agents, and abusive automation. CHEQ’s integration catalog also lists deployment within Cloudflare, providing a specific integration route to assess against your architecture.
Use CHEQ’s demo process to review deployment needs and request a scoped quote. The reviewed sales page doesn’t establish a public monthly price or tier schedule. For any vendor, confirm plan eligibility, regional availability, and costs for the traffic and surfaces you need covered before comparing proposals.
Measure Legitimate Sales and Customer Impact
Blocked-request counts rise and fall with attack activity, even when customer purchases don’t change. Use them alongside outcome measures. The following scorecard is a practical starting point, not an industry standard.
- Checkout completion for sessions assessed as legitimate. Completed orders divided by checkouts started, using a documented classification method. Unflagged sessions are an estimate, not proof of legitimacy.
- Payment approval and decline patterns. Approvals per payment attempt, split by new and returning customers. Report identified card-testing bursts separately from the normal baseline.
- Confirmed fraud and disputes. Count and monetary value for each order cohort, grouped by when the orders were placed.
- Inventory reservations that convert. Units reserved in carts that become completed orders, divided by units reserved, for each limited release.
- Customer complaints about challenges. Support tickets citing a verification step or block, measured against a consistent session or order denominator.
- Traffic quality. Share of sessions classified as non-human, by channel, with the classification and reporting definitions recorded.
Keep counts, rates, and monetary values separate. Falling fraud counts can conceal increasing losses if the remaining fraudulent orders are more valuable. Name the denominator for every rate and record changes to it so reporting shifts aren’t mistaken for performance gains.
Match disputes to the orders that produced them. Disputes can arrive after the reporting period in which an order was placed. Comparing only current disputes with current orders can give a misleading picture of a new control’s results.
Shopify’s September 21 to 23, 2026 analytics rollout illustrates the measurement risk. It began filtering identified bot sessions from session-related reports by default, while its documentation states that orders, sales, and customer counts were unaffected.
Session-based conversion reporting can therefore change without a corresponding sales change. Analytics filtering also doesn’t demonstrate that bots were prevented from accessing the store.
CHEQ describes sending detection data into web analytics and business-intelligence systems, supporting traffic-quality reporting. Use that data to examine channel performance alongside order and payment records. Establish additional sales through those business outcomes rather than infer them from a cleaner session count.
Roll Out Protection Before the Next Sales Peak
Plan the rollout around observed abuse and customer impact. The time required depends on your traffic, platform, and coverage needs; avoid committing to enforcement before the team has reviewed the evidence.
Establish a baseline. Record the scorecard metrics over a representative period that includes promotional traffic. Document the crawlers, integrations, and shopping agents you intend to allow, along with the actions each is permitted to take.
Pilot a sensitive journey. Choose a costly abuse pattern you’ve observed, such as checkout card testing or limited-release hoarding, and configure rules for that journey. Salesforce’s B2C Commerce guidance recommends testing protective rules in log or monitor mode before enforcement to confirm that they match the intended traffic. This is a useful approach to discuss with whichever provider operates your controls.
Review false positives. Have support and security staff examine the monitor-mode results together. Look for legitimate customers and approved integrations that would have been caught. Agree on the acceptable customer impact and the evidence required to proceed.
Expand with a rollback plan. Enforce the pilot rules, review the results for an agreed period, and extend coverage only after resolving problems. Record who can disable a rule and how support escalates a mistaken block during a live event.
If the pilot includes a classification layer such as CHEQ, check whether its entity and intent signals support the planned responses at each stage. Include permitted agent and integration activity in those tests.
Assign a business owner to monitor legitimate sales and a technical owner to maintain the rules. Before the next peak event, have both approve the policy, confirm the rollback process, and make sure support staff can reach the person authorised to release a held order or disable a faulty rule.
