Thousands of abandoned checkouts in Shopify: investigating bots without losing customers

A store owner opens a report and sees a sudden rise in abandoned checkouts. The first explanation is understandable: customers are reaching payment, but something is stopping them from completing a purchase. Perhaps delivery costs have increased, a payment method has failed, or an advertising campaign is attracting the wrong audience.

But the records reveal other patterns: repeated addresses, unusual phone numbers and large numbers of similar attempts involving a low-priced product. Orders barely increase while the customer database keeps growing. The question becomes broader: which events represent real shoppers, where is automation involved, and what has already happened to the store’s data?

That is where I would start. Otherwise, a merchant may change a working checkout, pay for an unnecessary app and continue sending messages to suspicious contacts.

What the discussion shows — and what remains unproven

The starting point is a Shopify Community thread about suspected card-testing bots. A Shopify Plus merchant reported more than 11,000 abandoned checkouts since the beginning of September, recurring details and little correlation with storefront visits. One participant said the stream stopped after installing an app. That is their observation; as of 6 October 2026, the original poster had not confirmed a resolution for their store.

See the Shopify Community discussion.

I see this as a reason to investigate. Installing an app remains a working hypothesis. The wave may have ended independently, changed in intensity or encountered another protection mechanism. Without comparing events before and after, we do not know what actually helped.

We also need to distinguish automated checkout creation from card testing: attempts to establish whether stolen cards are valid through payment activity. Shopify describes card testing as a specific form of abuse and provides built-in protection through Shopify Payments. A high abandoned-checkout count alone does not establish that card testing took place. See Shopify's guidance on preventing fraud.

The merchant has three separate problems to solve

The first is protecting payments. We need to establish whether payment attempts occurred, how they were handled, and whether they resulted in authorisations or actual orders. An absence of captured payments does not answer all those questions.

The second is reducing false checkout activity. A mechanism may stop payments without delivering the expected reduction in admin records in a particular configuration. That outcome needs its own verification.

The third is restoring control over data. Even if new suspicious events stop, existing contacts may remain in the CRM, customer segments and automated workflows. Their subsequent handling needs a separate decision.

Consider an illustrative store: 400 started checkouts and 80 orders produce a checkout completion rate of 20%. Add 3,600 false checkouts and the figure falls to 2%, even though orders remain unchanged. These are hypothetical numbers, not statistics from the discussion. They illustrate how a polluted denominator changes the conclusion. This is the checkout completion rate, rather than the conversion rate for all store visits.

I would therefore first ask the owner to define the outcome they need: fewer abusive payment attempts, fewer false records, more reliable reporting, or all three. Each requires a different way of measuring success.

Reconstruct events before choosing protection

Initially, we compare a normal period with the spike: checkout creation times, payment events, completed orders, available visit data and actions taken by connected services. We use a consistent time zone and comparable observation windows. In Shopify, payment attempts can be examined in a checkout’s Timeline; once an order is created, its events are reviewed in the order history. See Shopify's documentation on abandoned checkouts.

A repeated postcode or an unusual phone number can help identify a pattern. I would not block customers based on either alone. We first examine combinations of signals and alternative explanations, such as a campaign, a technical fault or a change in purchase conditions. Shopify also makes clear that bot activity alone does not establish a store breach or compromised credentials. See Shopify's guidance on identifying bot activity.

The investigation needs relevant records and agreed access. A specialist does not need full card details or passwords. Where evidence is unavailable, the findings should state that limitation.

This work can start with a Shopify store diagnostic. Once the issue has been defined, a focused root-cause investigation helps test explanations, establish what the evidence supports and prepare an action plan. Implementation scope follows the diagnosis.

Why the label “bot protection” is not enough

I would first review the platform’s native controls and those of the payment provider. For Shopify Payments, that includes available fraud-prevention settings and built-in card-testing protection. An additional app should address an identified gap rather than duplicate a function on the strength of its marketing description. See Shopify's fraud-prevention documentation.

The tools also serve different purposes. Fraud analysis helps assess eligible orders; it is not a complete log of every false checkout. Manual payment capture creates a review window after authorisation, but does not prevent the payment attempt itself. See Shopify's fraud analysis documentation and Shopify's payment authorization documentation.

Native Bot protection on Shopify Plus is designed for situations such as time-limited sales. Shopify explicitly distinguishes it from combating bot-related fraud, and a protection event is limited to 60 minutes. That matters when suspicious activity continues for weeks. See Shopify's Bot protection documentation.

Similarly, a storefront restriction can help only along a route the suspicious activity actually uses. Before changing a theme or network configuration, we need to establish the event path and confirm that the proposed measure is supported in the store’s setup.

If we consider an app using Shopify Functions, server-side cart and checkout validation is a supported platform mechanism, including for supported express checkouts. However, its rules depend on the available inputs and the particular implementation. We cannot automatically assume it knows IP addresses or the complete history of attempts. See Shopify's cart and checkout validation documentation.

Distribution also matters: Shopify App Store apps using Functions are available across plans, while Functions in custom apps require Shopify Plus; some capabilities have further restrictions. A proposal to build a dedicated solution therefore needs an applicability check too. See Shopify's Functions documentation.

How to test the app hypothesis

First, I would make the hypothesis specific: a selected rule should reduce a defined type of unwanted event while preserving purchases for the store’s ordinary customers. “Remove bots” is too vague to support a decision.

We then record the baseline, configuration, activation time and other changes made around the same time. If the app provides an observation mode, we use it. If it does not, we define a limited rollout, verification steps and a rollback procedure in advance.

We check the store’s usual purchase scenarios: mobile, desktop, the accelerated payment methods it uses, and the addresses and baskets of genuine customer groups. Technical tests use permitted test data and a suitable test environment. Reproducing abuse with stolen cards is unnecessary.

A decline in events after installation is a useful signal. If attack intensity or other settings also changed, confidence in a causal relationship is lower. We continue observing and describe the result as preliminary. We also need to preserve the Shopify customer experience: an overly broad rule can exclude customers along with unwanted activity.

Handling the CRM, messaging and existing records

I would separately establish which suspicious contacts actually reached external systems and which messages were sent. Not every abandoned checkout triggers an email: Shopify applies sending conditions, and its newer and legacy automations have different settings. We need to inspect actual workflow runs and delivery results, rather than infer sending from the presence of an email address. See Shopify's abandoned checkout documentation.

A practical step is to reversibly exclude a verified suspicious group from affected workflows and operational segments. If segmentation is insufficient, we assess temporarily pausing the particular automation and its effect on sales. Deleting all new customers in bulk could affect genuine buyers and remove useful evidence.

Cleaning Shopify and an external CRM should not be treated as a single operation either. We must check data transfers, subsequent synchronisation and the conditions that bring contacts back into workflows. This is where our work on Shopify integrations with external systems helps ensure that a correction survives the next exchange of data.

Checkout history has a limitation too: Shopify does not allow individual abandoned checkouts to be deleted manually and automatically removes records older than three months. We therefore cannot promise an instant app-driven cleanup of that section. Analysis may require a separate report that excludes suspicious events on a verifiable basis; this does not change the platform’s historical metrics. See Shopify's documentation on abandoned checkouts.

The work we take on

At IceStoreGroup, we take on the investigation: connecting events across the store and its systems, testing hypotheses, assessing native controls and evaluating whether an app is appropriate. The findings distinguish confirmed facts from uncertainty and identify changes worth implementing.

Once the scope is agreed, we configure protective measures, adjust integrations and automations, and verify customer purchase scenarios. Where an existing tool is insufficient, we consider developing a Shopify extension for the store’s requirements. If Shopify or the payment provider needs to participate, we prepare a timeline and supporting evidence for escalation.

The owner should receive an understandable result: an established or evidence-supported probable cause, implemented measures, verified purchases and indicators to monitor during an agreed period. Promising that every future form of abuse will disappear would be misleading. Investigating the situation and carrying agreed actions through to a verifiable result is work we take responsibility for.

For me, a solution starts with the owner being able to trust the store’s data and actions. An app can contribute when testing demonstrates its value for that particular business.