Shopify handles a lot of this for you. Some of it, it doesn't. Here's what you can see, and what you can actually do about it, mostly with tools you already have.

1. What Shopify already does

Before installing anything, know what's on by default:

• Platform-level bot protection. Shopify sits behind Cloudflare and filters a lot of abusive traffic before it reaches your store.
• hCaptcha on forms. It's on by default for contact, comment, login and account-creation forms. Check it's still on under Online Store > Preferences > Spam protection.
• Checkout protection. Shopify runs its own checks on checkout. Extra bot protection during high-traffic sales is a Shopify Plus feature.
• Fraud analysis on orders. Eligible orders get a low, medium or high risk recommendation with indicators, and stores on Shopify Payments also get proxy detection. Shopify's own advice is to go by the recommendation, not by any single indicator such as the IP address.

That covers a lot of card fraud. What it doesn't give you is a clear picture of your traffic: how much of it is people, and how much is automated or anonymized.

2. Why the traffic picture matters

Bot and proxy traffic on a store costs you in quieter ways than fraud:

• Wrong numbers. Conversion rate, bounce rate and "sessions by country" all include traffic that was never going to buy.
• Wasted ad spend. Paid clicks from datacenter networks are rarely shoppers.
• Card testing. Waves of small payment attempts, often from rotating proxies, show up as failed payments before they show up as chargebacks.
• Scraping. Competitors and resellers pulling your catalog and prices.

The tell is usually the network the traffic comes from. Shoppers browse from home broadband and mobile carriers. Bots and scrapers run on cloud servers (AWS, DigitalOcean, OVH, Hetzner) and route through proxies.

3. What to look at

Whatever tool you use, these are the questions that matter:

• What share of page views come from hosting or datacenter networks?
• What share of checkouts started come from VPNs, proxies or Tor, and is that share higher than for page views?
• Do payment attempts from risky networks cluster in bursts? That's what card testing looks like.
• Do spikes in "sessions from country X" line up with a single hosting provider?

You'll usually find a few clear patterns (a scraper on one cloud provider, a burst of proxy checkouts on one night) rather than a general problem. Shoppers on VPNs are mostly real people, so a VPN on its own tells you little.

4. What you can do about it

On Shopify, the store front is yours but checkout is Shopify's, so the levers are:

The general rule holds here too: look before you block. A storefront that blocks every VPN user turns away real customers and still can't touch what happens inside Shopify's checkout.

Where FindIP Shield fits

Disclosure: we make FindIP Shield, which does the "what to look at" part for free.

• It uses Shopify's Web Pixels API and reports page views, checkouts started and payment info submitted, each scored for VPN, proxy, Tor, hosting or datacenter network and known malicious IPs, with the reasons, in a dashboard.
• It runs only when the shopper has given analytics consent, under Shopify's Customer Privacy controls.
• It's deliberately minimal: no names, emails, addresses, customer or order IDs, cart contents, search queries or payment details are sent, and page URLs are stripped of query strings.
• It reports; it doesn't block shoppers. Because it never sees order IDs, use Shopify's fraud analysis for individual orders and Shield for the traffic picture around them.
• Free up to 10,000 events per site per day.

It's on the Shopify App Store as FindIP Shield, and there's an example dashboard with sample data and a Shopify overview if you want to see what it shows first.

The short version

1. Use what Shopify already gives you: hCaptcha on forms, fraud analysis on orders.
2. Find out which networks your traffic comes from: residential, hosting, VPN, Tor.
3. Look for patterns (one cloud provider, one burst of failed payments) before blocking anything.
4. Act with Shopify Flow on risky orders and segment junk traffic out of your numbers.
5. Don't block VPN shoppers outright. Most of them are customers.

Detecting that is easy. Deciding what to do with it is where most setups go wrong: millions of legitimate people use a VPN every day, and a site that blocks all of them loses real customers.

Here's how to approach it on WordPress, in the order that keeps false positives low.

1. Know which network your visitors come from

Every request arrives from an IP address, and that address belongs to a network. The useful question isn't "which IP?" but "what kind of network?":

• Residential or mobile ISP: home broadband, phone carriers. This is almost everyone.
• Hosting or datacenter: AWS, DigitalOcean, OVH, Hetzner and friends. Real people rarely browse from these; scripts and cheap proxies do.
• Commercial VPN, open proxy, Tor: anonymized traffic. Common for privacy-minded users, also common for abuse.
• Known malicious IPs: addresses already seen scanning, spamming or attacking.

WordPress doesn't tell you any of this. You need an IP intelligence lookup: either a plugin that calls one, or a layer in front of the site (Cloudflare) that classifies traffic for you.

2. Look before you block

The most common mistake is installing a blocker, switching on "block all VPNs", and walking away. Two weeks later a customer emails to say they couldn't check out from their company laptop.

Run in monitor mode first, for a week if you can:

• What share of registrations come from hosting networks or VPNs?
• What share of orders, and do those orders get refunded or charged back more?
• Are your contact-form spam submissions concentrated on a few networks?

You'll usually find that the abuse sits in a few clear patterns (datacenter IPs on the registration form, say), while VPN users on checkout are mostly fine. That tells you exactly where to add friction and where to leave things alone.

3. Watch out for page caching

If you use a full-page cache (WP Rocket, LiteSpeed Cache, W3 Total Cache, or your host's built-in cache), a PHP check that runs when WordPress renders the page doesn't run on a cached page. The cache serves the stored HTML without WordPress ever looking at the visitor's IP. Server-side blocker plugins usually document this and ask you to exclude protected pages from the cache.

Two ways around it:

• Check at the edge: a Cloudflare WAF rule or Worker sees every request before the cache.
• Check in the browser and on submit: a small script on the page reports the visit and the form submit, so cached pages are covered too. The decision happens when the form is actually submitted.

4. Protect the forms, not the whole site

Blocking every page for every VPN user is a blunt tool. The forms are where abuse costs you money, so put the friction there:

"Risky" should mean several signals together (a datacenter IP plus a brand-new account plus a burst of attempts), not a VPN on its own.

5. Your options on WordPress

There are three common routes, and they combine well:

• Cloudflare WAF rules. If your site is behind Cloudflare, custom rules can block or challenge by ASN, country or Cloudflare's own threat signals, before the cache. Powerful, but you write and maintain the rules yourself, and you don't get a per-form view of what happened.
• A blocker plugin backed by an IP API. Plugins such as Proxy & VPN Blocker (proxycheck.io) or VPN Guard (vpnapi.io) check the visitor IP against an API and block or redirect on pages you choose. Simple and effective for hard blocking; mind the caching caveat above and the API's daily quota.
• A monitoring-first plugin with form protection. Score every visit and form submit, see the reasons in a dashboard, and add friction only on the forms and signals that turn out to matter.

Where FindIP Shield fits

Disclosure: we make FindIP Shield, a free plugin for the third route.

• Every visit, signup, login and WooCommerce checkout gets a risk score with the reasons: VPN, proxy, Tor, relay, hosting or datacenter network, or a known malicious IP.
• It runs on regular pages and on wp-login.php, in the browser, so full-page caching doesn't skip it.
• With WooCommerce active it adds cart, checkout, payment-failure and order-completion context, so you can see which orders came through anonymizing networks.
• It doesn't block anything by default. When you're ready, you switch on form protection from the dashboard and choose what a risky visitor sees: a message, a short wait, or a Cloudflare Turnstile check.
• It never reads form values, passwords, emails or payment details, and starts in strict privacy mode.
• Setup is install, click Connect, pick your site. Free up to 10,000 events per site per day.

It's on WordPress.org as FindIP Shield: VPN, Proxy & Bot Traffic Detection, and there's an example dashboard with sample data if you want to see what it shows before installing.

The short version

1. Find out which networks your visitors come from: residential, hosting, VPN, Tor.
2. Monitor for a week before blocking anything.
3. Remember that page caching skips server-side checks; check at the edge or in the browser.
4. Add friction on the forms where abuse costs money, when several signals stack up.
5. Never block VPN users outright. Challenge them when the rest of the picture looks wrong.

The usual fixes each have a hole. Email verification stops nobody with a disposable inbox. A card on the free tier stops the abuse and most of your signups with it. IP rate limits lock out a whole office behind one NAT.

What works is layers, each cheap on its own, ordered so the first ones protect your bill even before you catch anyone. This is the setup, in the order we'd build it.

1. Cap the blast radius first

Before you try to detect anything, make sure the worst case is a number you chose.

• A global daily budget for all free usage. When it's spent, free requests queue or wait until tomorrow. One bad night can't become a surprise invoice.
• A per-account daily cap that's lower than you think you need.
• Check both on the server, before the model call, not after.

// Before calling the model for a free-tier user
async function canSpendFree(userId: string, estTokens: number) {
  const today = new Date().toISOString().slice(0, 10);
  const [global, user] = await Promise.all([
    redis.incrby(`free:global:${today}`, estTokens),
    redis.incrby(`free:user:${userId}:${today}`, estTokens),
  ]);
  await redis.expire(`free:global:${today}`, 172800);
  await redis.expire(`free:user:${userId}:${today}`, 172800);
  return global <= GLOBAL_FREE_DAILY && user <= USER_FREE_DAILY;
}

This doesn't stop farming. It makes farming boring and bounded, which is most of the battle.

2. Make each account worth less

Farming is economics. Lower the payout per account and most farmers stop.

• Drip credits instead of one lump. "50 a day for a week" is far less worth farming than "350 now". An honest user barely notices.
• Start new accounts on a cheaper model. The good model unlocks after email verification and a bit of normal use. The farmer's cost per account goes up; yours goes down.
• Unlock more with trust: account age, normal usage, a verified email, or a card, but ask for the card only when an account looks risky (step 5).

3. Clean up the email layer

Not because it stops determined people, but because it's an afternoon of work and removes the laziest farming.

const DISPOSABLE = new Set(disposableDomains); // e.g. the open-source "disposable-email-domains" list

export function normalizeEmail(raw: string) {
  const [local, domain] = raw.trim().toLowerCase().split('@');
  const d = domain === 'googlemail.com' ? 'gmail.com' : domain;
  let l = local.split('+')[0];                 // drop +tags
  if (d === 'gmail.com') l = l.replace(/\./g, ''); // Gmail ignores dots
  return { email: `${l}@${d}`, disposable: DISPOSABLE.has(d) };
}

Store the normalized email with a unique index, and keep a hash of it when an account is deleted, so "delete and sign up again" doesn't reset the free tier.

4. Group accounts instead of judging each one

A single signal proves nothing. A VPN is common for privacy-minded users; a shared IP is every office and mobile carrier. What gives farmers away is that their accounts look alike:

• Network type, not just IP. An office NAT or a mobile carrier is a residential or mobile ISP. Ten accounts in an hour from VPN exits and cloud servers are not. This distinction is what keeps your false positives down.
• Network changes inside one session: the IP, ASN or country switching mid-signup is a strong sign of a rotating proxy.
• Timing: a new signup minutes after the previous account ran out of credits.
• Workload: the same first prompts, files or project shape as an older account.

Log these for every signup from day one. You can't cluster history you didn't keep.

5. Add friction only where signals stack up

Now use the signals, gently:

The honest majority never sees any of this. The farmer sees it on every account.

Where FindIP Shield fits

Disclosure: we make FindIP Shield, a free tool that does the network part of steps 4 and 5. It scores each visit and form submit from 0 to 100 with the reasons (VPN, proxy, Tor, hosting or datacenter network, known malicious IP, IP changes during the session), and can add a short wait, a Turnstile check or a stop message for risky submits only, off until you switch it on. It scores the network, not the device: there's no device fingerprinting, so on its own it won't recognize the same laptop on a fresh profile. It never reads form values.

The browser side is one script tag:

<script
  src="https://cdn.findip.net/shield/v1.js"
  data-site-key="pub_xxxxxxxxx"
  data-auto-track="true"
  data-privacy-mode="balanced">
</script>

Send the Shield session ID with your signup request (FindIP.getSession().sessionId), then let your server make the decision, because anything decided in the browser can be bypassed:

async function shieldVerdict(sessionId: string) {
  const res = await fetch('https://shield.findip.net/v1/shield/sessions/verify', {
    method: 'POST',
    headers: {
      Authorization: `Bearer ${process.env.SHIELD_SECRET_KEY}`, // sec_..., server only
      'Content-Type': 'application/json',
    },
    body: JSON.stringify({ session_id: sessionId, event: 'signup_attempt' }),
  });
  const v = await res.json();

  // Unknown is not safe: no session, or no IP intelligence for it.
  if (!v.verified || v.risk_status === 'unknown') return 'monitor';
  if (v.recommendation === 'block') return 'require_card';
  if (v.recommendation === 'challenge') return v.challenge_passed ? 'allow' : 'require_verification';
  return 'allow';
}

Combine that verdict with your own signals from steps 3 and 4, and feed it into the table in step 5. Shield is free up to 10,000 events per site per day; there's also a WordPress plugin, a Shopify app, a GTM template and a no-code Cloudflare integration if your signup page isn't hand-written.

The short version

1. Cap global and per-account free spend on the server.
2. Drip credits and start new accounts on a cheaper model.
3. Normalize emails, block disposable domains, remember deleted accounts.
4. Cluster accounts by network type, timing and workload.
5. Add friction only where signals stack up, and never block VPN users outright.

You won't stop every determined person. You don't need to: you need farming to cost them more than it saves, while honest users still get in with one click.