Chargeback Reduction: The Checkout Signals Shopify Misses

Shopify's built-in fraud analysis catches the obvious stuff. A CVV mismatch, an address that does not resolve, a card flagged on another Shopify store an hour ago, an IP sitting in the middle of a datacenter range in a country the billing address has never seen. The green, yellow, and red icons on the order page do real work, and the underlying model is trained on a data pool no single merchant could build alone.

What it does not catch is the stuff just outside the frame. Patterns that emerge only when you compare orders against each other, or when you enrich the order with data not shipped in the checkout payload, or when you recognise that the IP reputation world has moved on in ways Shopify's default stack has not kept up with. These are the signals that separate a chargeback ratio of 0.4 percent from one of 0.1 percent, and on a store doing two million a year the gap between those two numbers is the cost of a mid-level engineer.

This article walks through four specific signals Shopify's default analysis misses, how to capture each using the tools Shopify already gives you plus a small number of external APIs, and how to act on them without cancelling the orders of customers who happen to travel with a VPN or share an email with their spouse.

What Shopify flags, and what it silently lets through

The built-in analysis evaluates every order against a fixed set of inputs drawn from the checkout session and the card network response. It checks whether the CVV matched, whether AVS street and postal code matched, whether the billing country matches the IP country, whether the card has been tried from multiple IPs, and whether the email or card has been flagged on another Shopify store recently. A network-trained ML model contributes a general risk score on top. The output is the badge on the order page and the stacked list of indicators below it.

Notice what is absent. Nothing about the reverse direction of velocity, where one IP places many orders with different cards in a short window. Nothing comparing the name on the billing address to the name on the shipping address, a textbook reshipper pattern. Nothing that actively checks the email domain against a maintained list of disposable providers, only a general penalty for brand-new emails. And proxy detection was built for an era of datacenter IPs and does not reliably identify residential proxy networks, which is where most sophisticated card testers and fraud rings operate today.

Each gap is closeable with a small amount of engineering. The rest of this article shows how, with the specific trigger, data source, and action for each.

Signal one: velocity from a single IP inside an hour

The canonical card-testing pattern looks like this. A fraudster obtains a list of card numbers from a breach. To find out which still work, they run a script that places many small orders on a store with low-friction checkout, rotating the card but not the IP, because rotating IPs is harder and the fraudster is optimising for speed. Each order on its own looks fine. The card passes AVS because the fraudster bought the matching billing address along with the number. The CVV passes. The IP is a normal residential broadband connection. Shopify's default analysis does not see anything wrong because it looks at one order at a time. What it does not see is that this is the fourteenth order from the same IP in the last thirty minutes.

The rule is conceptually simple. On every new order, count how many orders in the last sixty minutes share the same client_details.browser_ip, and if that count is greater than three, flag the entire batch. Implementing it inside Shopify's default tooling is harder than it sounds, because Shopify Flow cannot natively query historical order data against the current order inside a trigger condition.

The clean implementation is a small serverless function that subscribes to the orders/create webhook and maintains a short-lived counter keyed by IP in a cache like Redis, Upstash, or a Shopify metaobject. On each order, increment the counter for its IP with a sixty-minute expiry, read the new value, and if it exceeds the threshold, call the Admin API to add a velocity-risk tag and place fulfilment on hold. A cheaper variant uses a scheduled job every five minutes that pulls the last two hundred orders, groups them by IP, and tags any IP with more than three orders in the window.

The threshold of three per hour is a starting point. A B2B supplier whose customers sit behind a single office NAT will need to raise it or whitelist specific IPs. Strictly consumer stores can drop it to two. The correct number sits just above the ninety-ninth percentile of your honest returning-customer behaviour.

Signal two: billing and shipping name mismatch

A legitimate order occasionally has a different shipping name from a billing name. A wife buys a gift for her husband, a colleague orders a sympathy bouquet, a procurement card pays for a delivery to a named employee. These exist, and an aggressive rule that cancels every name-mismatched order will wreck conversion on gift-heavy categories. But when you look at chargebacks that did not trip Shopify's default indicators, an overwhelming share have one thing in common. The shipping name is completely different from the billing name, and the shipping address is a reshipper hub, a hotel, a storage unit, or a residential address in a high-fraud postal code.

The rule compares billing_address.first_name concatenated with billing_address.last_name against the equivalent on the shipping address. Normalize both sides by lowercasing, stripping accents, removing punctuation, and collapsing whitespace. Compute the Levenshtein distance, or a simpler token-overlap score. If the distance is greater than three and there is no shared token of at least three characters, you have a mismatch.

On its own the mismatch should not cancel an order. It should tag and feed into the combined score. Where it earns its keep is in combination. Name mismatch plus first-order email plus a shipping postal code that has never ordered from you plus an IP country that differs from the billing country is four soft signals that together warrant manual review.

One implementation detail matters. Shopify's checkout sometimes ends up with the full name in the first-name field and the last-name field blank. Run the comparison against the full concatenated string, not field by field, or legitimate orders will falsely mismatch.

Signal three: disposable email domains at the order/create webhook

Disposable email services have multiplied to the point where maintaining a manual list is not viable. The big three that everyone recognises, mailinator, guerrillamail, and 10minutemail, are easy. The long tail of hundreds of rotating domains, many of which spin up for a week and disappear, is not. A fraudster using a disposable email is not guaranteed to chargeback, but the correlation is strong enough that it should be caught at the order level, not ignored.

The right place to run the check is in a handler subscribed to the orders/create webhook. Shopify Functions cannot make outbound network calls, so any real-time external lookup has to happen either in a Cart Validation Function using only data already in the cart context, which rules out third-party API calls, or as an asynchronous post-order enrichment via webhook. The 5-second webhook acknowledgement window means the handler should return 200 immediately and hand the actual work off to a background job, which then calls the email validation provider.

Kickbox, ZeroBounce, Abstract API, and Debounce all return a disposable: true/false field alongside syntactic and MX-level checks. At volume, the cost is under a cent per lookup. The handler takes the email field from the order, calls the provider, and on a true result writes a disposable-email tag via the Admin API. A Shopify Flow rule listening for that tag then decides whether to cancel, hold, or simply notify.

The correct action depends on your business. For a digital product, cancelling a disposable-email order outright is usually the right move. For a physical-goods store, holding the order and emailing the customer with a polite request for a reachable email catches the small number of privacy-conscious customers without shipping to the rest. A short, non-accusatory note along the lines of "we noticed the email on your order looks temporary, please confirm a reachable address so shipping updates can find you" converts a meaningful share of honest customers and wastes no energy on fraudsters, who simply disappear.

Signal four: residential VPN exit nodes via IPQualityScore

Shopify's built-in proxy detection is fine for obvious datacenter IPs. It is less helpful against the current state of the art, which is residential proxy networks. Services like Bright Data, Oxylabs, and Smartproxy route traffic through the home broadband connections of real users, sometimes with consent as part of a freemium app deal and sometimes not. The exit IP looks like a normal home connection. The browser fingerprint can be spoofed to match. Shopify does not reliably flag it, because at the IP level it does not look like a proxy.

IPQualityScore maintains its own honeypot network, behavioural database, and exit-node fingerprinting to identify residential proxies in a way raw IP reputation cannot. Its API returns proxy, vpn, tor, active_vpn, recent_abuse, and an aggregate fraud_score from zero to one hundred. The same orders/create webhook handler that does the email check calls IPQualityScore with the order IP, caches the result for twenty-four hours, and writes the score into an order metafield.

The action threshold is where most implementations go wrong. Legitimate customers use VPNs. Enterprise employees, travellers on hotel wifi, privacy-minded people on Mullvad or ProtonVPN. Blocking on vpn: true alone causes false positives in the low single digits, usually too many. The correct threshold combines signals. A fraud score above seventy-five, or active_vpn: true together with any other risk signal, is a reasonable starting hold condition. A residential proxy flag plus a name mismatch plus a first-time email is an almost-certain fraud order.

Feed the score into a Flow rule alongside the velocity tag and the disposable-email tag. The cumulative tagging approach lets you tune thresholds over time based on actual chargeback outcomes without rewriting code.

Turning signals into automated holds and manual review queues

Signals only matter if they produce action. The action layer should be split into three tiers. Automatic cancellation, automatic hold with human release, and silent tagging for reporting.

Automatic cancellation is reserved for cases where combined confidence is so high that a false positive is rarer than a chargeback. Disposable email plus residential proxy plus name mismatch plus velocity flag is the classic example. Cancellation fires through Shopify Flow listening for the aggregate tag set, refunds the payment, and sends a neutral cancellation email. Do not explain which rule triggered, because that is free intelligence for the attacker.

Automatic hold is the workhorse tier. Anything that hits two or three signals but not the full stack goes on fulfilment hold via Shopify Flow's Hold Fulfillment action, tagged with the relevant risk labels, and surfaced in a Slack channel for a human reviewer. The reviewer has a simple yes-or-no decision. A well-configured system puts fewer than two percent of orders into this queue, clearable in ten to fifteen minutes a day.

Silent tagging is for weak single signals. A name mismatch alone, or a moderate fraud score with no other red flag, gets tagged but ships normally. Over ninety days the tagging lets you correlate which single-signal orders actually became chargebacks, and tune composite rules accordingly. Without this feedback loop the system ossifies at its initial thresholds and drifts out of match with how fraud is actually hitting you.

The Shopify chargeback record is ground truth for tuning. Every time a dispute comes in, pull the order, check which tags it had, and ask whether your rules should have caught it. Over a quarter, composite thresholds sharpen, the review queue shrinks, and the chargeback ratio moves comfortably below the Visa VDMP threshold of one percent and far from the one-point-eight-percent line where the card networks start levying real fines.

Where this lives in a merchant's operating stack

The four signals and three action tiers together form a fraud layer that sits on top of Shopify's default analysis rather than replacing it. The built-in indicators keep doing their job on the cases they handle well. The extensions catch what the built-in model cannot see because the data is not in its inputs. Together they typically move a healthy merchant from a chargeback ratio of 0.3 to 0.5 percent down to 0.1 to 0.2 percent, which on a two-million-dollar store is four to six thousand dollars of recovered revenue plus fees plus the risk reduction on the merchant account itself.

The build is not large. One webhook handler, one external cache, two API integrations, four Flow rules, one review dashboard. A competent engineer delivers the whole thing in two to three weeks, with maintenance measured in single-digit hours per quarter plus the review queue. Most stores that need it do not have the in-house engineering bandwidth to build it cleanly, which is where the fraud-signal engineering work at WitsCode comes in. We deliver the webhook layer, the IPQualityScore and Kickbox integrations, the Flow rules, and the staff review dashboard as a bolt-on for Shopify Plus and Advanced merchants, tuned to the fraud profile of the specific store rather than a generic template.

→ WitsCode fraud-signal engineering closes the four gaps in Shopify's default fraud analysis, ties the signals into Shopify Flow, and keeps your chargeback ratio out of the zone where the card networks start paying attention. If your numbers have crept up and the built-in badge is missing things, that is the service to ask about.