The Hook

In 2024, the FBI's Internet Crime Complaint Center logged 859,532 complaints and $16.6 billion in reported losses — a 33% increase over 2023, according to IC3's annual report. Card-not-present fraud is a meaningful slice of that number, and the ones that hit your bottom line twice — once when you ship the product, again when the issuer claws back the funds plus a fee — are the chargebacks. A 1% chargeback rate is not just a number on a dashboard; it is a regulatory threshold that can end your ability to accept card payments. Getting that number down is not optional, and IP intelligence is one of the cheapest and most effective levers you have before the order ever hits Stripe Radar.

This playbook covers the specific IP-driven signals that actually move chargeback rates, how they interact with Stripe Radar and Shopify's native fraud analysis, when to trigger 3D Secure versus when to auto-hold, and what Visa's Compelling Evidence 3.0 rules mean for the disputes you still receive. It is written for operators running on Stripe, Shopify, WooCommerce, or any of the checkout stacks that ultimately land in one of those ecosystems.

TL;DR

• Visa's VAMP sets the 'Excessive' merchant chargeback threshold at 0.9% effective April 2026; Mastercard ECM triggers at 1.5% with 100+ monthly chargebacks. Your acquirer will panic at about half those numbers.
• Billing country vs. IP country mismatch is the strongest single pre-checkout signal. Step up to 3DS rather than hard-blocking to preserve travellers and corporate VPN users.
• Stripe Radar is strong but generalist. Layering IP intelligence (hosting ASN, Tor exit, proxy classification) on top catches the tail of attacks Radar's network-effect model is slower to adapt to.
• Visa Compelling Evidence 3.0 lets you win friendly-fraud disputes if you've logged IP address and device fingerprint across prior non-disputed transactions with the same customer — so collecting that data is a chargeback-prevention feature, not just an audit concern.

The Real Cost of a Chargeback

A chargeback does not cost you the price of the order. It costs you roughly three to five times that, and the multiplier gets worse the smaller the average order value. Walk through the line items:

• Lost product. The goods shipped; you will not get them back. If the dispute hinges on "item not received" and the customer is committing friendly fraud, the goods are already with them.
• Lost revenue. The card network reverses the charge. That's a direct debit against your settlement account.
• Chargeback fee. Acquirers charge the merchant a processing fee on each disputed transaction — typically in the \$15 to \$25 range for U.S. card-present Visa/Mastercard, often higher for card-not-present and international.
• Manual review cost. If you fight the dispute, you pay staff time (or a dispute-management vendor's per-case fee) to compile evidence, format it to the acquirer's submission template, and track the response window.
• Program-threshold risk. And this is the one that ends businesses: cross a card network's chargeback-rate threshold and you get enrolled in a monitoring program with escalating fines, mandatory remediation, and — if you don't get out — termination of your merchant account.

The program thresholds are not folklore. Visa's Acquirer Monitoring Program (VAMP) fact sheet, which consolidated VDMP and VFMP on April 1, 2025, sets monitoring thresholds at the acquirer-portfolio level with merchant-level identification when individuals exceed limits; the "Excessive" threshold for North America, EU, and Asia-Pacific merchants tightens to 0.9% effective April 2026. Mastercard's Excessive Chargeback Merchant (ECM) program triggers at 1.5% chargeback ratio plus more than 100 chargebacks in a single month; its High Excessive Chargeback Merchant (HECM) tier triggers at 3% and 300+. Your acquirer — not the network — sets your account-level policy, and they will suspend you well before you hit network thresholds because it is the acquirer who pays the network fines and absorbs the reputational exposure.

If your average order value is \$60 and a single chargeback costs you the product (\$20 COGS) plus revenue (\$60) plus a \$20 fee plus an hour of ops review (\$40 loaded cost), you have just lost \$140 on a \$60 sale. The math is why chargeback prevention is not a nice-to-have.

Why Stripe Radar Alone Isn't Enough

Stripe Radar is one of the best general-purpose fraud engines in the payments industry. According to Stripe's own product page, Radar's AI scans payments using "hundreds of signals from across the Stripe network" and reduces fraud by 38% on average for merchants who enable it. It integrates TC40 and SAFE reports from the card networks, early-dispute notifications from issuing banks, and rich signals across the checkout flow. On Stripe, every transaction goes through Radar whether you opt in to customization or not.

But Radar has structural limits that no amount of model improvement can close. First, it is a generalist. Radar's training data is the aggregate of every Stripe merchant, which means its baseline is great for average patterns but slower to adapt to the specific attack you're facing today — the one that is hammering your checkout right now because your product (a gift card, a high-dollar digital download, a direct-to-consumer luxury good) has a specific fraud profile. Custom rules help, and Stripe's Radar rules documentation shows how rich the available signals are: card country, IP country, risk level, BIN characteristics, custom metadata. But writing effective rules requires ground truth about your own fraud patterns, and that ground truth takes time to accumulate.

Second, the standard Radar tier does not expose the custom-rules dashboard at all. You need Radar for Fraud Teams — a paid upgrade — to write custom rules on top of the default model. Every team that cares about chargebacks ends up on this tier. That is fine; budget for it.

Third, Radar's IP signals are relatively coarse by IP-intelligence standards. Radar will tell you the card country and the IP country, and it does proxy detection (Stripe's Radar page lists 'proxy detection' explicitly), but it does not expose per-ASN reputation, Tor-exit flags, datacenter-vs-residential classification, or residential-proxy fingerprinting at the level a dedicated IP-intelligence service does. Those signals live one layer down and you have to call them explicitly.

The architectural pattern that works best: run an IP-intelligence check pre-checkout (on cart view, on the "proceed to payment" click, or in your backend before you hand off to Stripe's client-side SDK), attach the resulting risk score and classification flags to the payment intent's metadata, and write a Radar rule that reads from metadata. Now Radar's ML model is combining your IP signal with its network-effect signal, instead of either running alone.

Signal 1: Billing Country vs. IP Country Mismatch

This is, by some distance, the strongest single pre-checkout fraud signal for card-not-present merchants. The pattern: stolen card → billing address from the cardholder's actual country → attacker connects from wherever they happen to be. Billing-country vs. IP-country mismatch catches this pattern directly, and legitimate edge cases (travellers, corporate VPNs) are a small fraction of the volume.

Here is a minimal Node.js integration that reads IP country from the Predax API and compares against the billing country Stripe has collected:

import Stripe from "stripe";

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

async function preCheckoutRiskCheck({ ip, billingCountry, stripePaymentMethodId }) {
  const ipResp = await fetch("https://predax.io/api/v1/check/ip", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
      "X-API-Key": process.env.PREDAX_API_KEY,
    },
    body: JSON.stringify({ ip }),
  });
  const { classification = {}, network = {}, location = {} } = await ipResp.json();
  const country_code = location.country_code;
  const asn_name = network.as_name;
  const is_hosting = !!classification.is_hosting;
  const risk_score = classification.risk_score ?? 0;

  const countryMismatch = country_code && country_code !== billingCountry;
  const shouldStepUp = countryMismatch || is_hosting || risk_score >= 60;

  return {
    shouldStepUp,
    metadata: {
      predax_ip_country: country_code || "",
      predax_asn_name: asn_name || "",
      predax_is_hosting: String(is_hosting),
      predax_risk_score: String(risk_score),
      billing_country_mismatch: String(countryMismatch),
    },
  };
}

Then when you create the PaymentIntent, attach the metadata and request 3DS if shouldStepUp is true. A Radar rule can also read :metadata:['predax_risk_score']: and decide independently.

The nuance: do not auto-decline on mismatch alone. Travellers, dual-country residents, and anyone on a corporate VPN routinely transact with an IP country that doesn't match their billing country. The right response is a friction step — request 3DS so the issuer authenticates the cardholder, or send the order to manual review if the dollar value justifies it. Hard-blocks on country mismatch are one of the most common causes of false-positive complaints in customer support queues.

Signal 2: Order Velocity from the Same IP / Subnet

Card testing is when an attacker runs a freshly-stolen card through a merchant with small-dollar transactions (\$1 donations, cheap digital downloads) to verify the card is still live before selling it or using it for a big purchase elsewhere. The pattern is distinctive: many orders from the same IP, same subnet, or same browser fingerprint within minutes, with varying card numbers. Velocity detection catches this without needing to know anything else about the order.

Two complementary velocity windows:

1. Per-IP velocity. Count payment attempts from the same IP in the last 5 minutes, 1 hour, and 24 hours. Any more than 3 attempts in 5 minutes, 10 in 1 hour, or 30 in 24 hours is almost certainly card testing or coupon abuse.
2. Per-/24 subnet velocity. Attackers behind a mobile carrier NAT or a residential-proxy pool will rotate exit IPs within a subnet. Counting at the /24 level (roughly "same /24 = same physical network-edge") catches pool rotation that per-IP counters miss.

The Predax WooCommerce plugin ships an Order Velocity Detection feature that implements both of these at the checkout layer, letting you configure the window length and whether to match on IP, cart subtotal, email, or all three simultaneously. For Stripe direct integrations, you build the same logic with a Redis sorted set keyed on the IP (or /24) with a TTL matching your window and a counter check before handing off to PaymentIntent creation.

Velocity rules interact well with IP classification. A single order from a residential IP that has never been seen before is low-risk; 15 orders in 10 minutes from the same /24 on a hosting ASN is a card-testing attack in progress. The combination catches the pattern with far fewer false positives than either rule alone.

Signal 3: Hosting-ASN Origin on a Consumer Purchase

Residential consumers do not check out from Amazon Web Services. They do not check out from OVH, Hetzner, DigitalOcean, or Linode. When a "consumer" purchase arrives from a hosting ASN, the baseline prior should be "suspicious" — possibly not fraud (corporate VPNs, some mobile carriers route oddly, security-conscious users on Tailscale exit nodes), but strong enough to warrant friction.

The right response depends on dollar value. For small orders (\$20 and under) where the cost of a false-positive decline is low, you can hard-block. For anything larger, the correct response is step up to 3D Secure. Stripe's SCA documentation is specific about what this does for you: "If a cardholder disputes a 3DS payment as fraudulent, the liability typically shifts from you to the card issuer." You do not lose the sale if the cardholder is legitimate (they authenticate and the order goes through), and you shift fraud liability to the issuer if it turns out to be stolen-card abuse.

The detection call is straightforward. Every response from /api/v1/check/ip returns classification.is_hosting and classification.is_datacenter booleans, plus a top-level cloud block with provider / service / region when the IP belongs to a known cloud range, alongside network.as_name and network.asn. An order where classification.is_hosting === true and the product category is "consumer goods" is a step-up candidate. An order where the same flag fires on a B2B product with business billing address might be fine — corporate VPNs are common in enterprise SaaS purchases.

One tuning note: do not treat "datacenter ASN" as binary. A mixed-use ASN like Comcast or Cox Communications returns classification.is_hosting: true for its business IP ranges and false for its consumer ones — modern IP-intelligence services split this correctly per-subnet, but simpler GeoIP-only stacks do not. If you are building your own check, use a service that maintains per-subnet classification, not just per-ASN.

Signal 4: Disposable-Email + IP Reputation Combo

Disposable emails (mailinator, tempmail, guerrillamail, and the thousands of clones) are individually a weak signal — plenty of legitimate users use them for throwaway signups, and many ISPs' abuse departments will tell you that disposable email is under-represented in their actual fraud data. But pair it with a medium-risk IP and the signal sharpens considerably: legitimate users on disposable emails are typically casual signups, not checkout-completing ones, and a disposable email arriving at checkout on a VPN or hosting IP is a strong fraud indicator.

The combo logic is simple: if disposable_email AND (classification.is_vpn OR classification.is_hosting OR classification.risk_score > 50), auto-hold. If disposable_email alone or suspicious IP alone, pass through — or step up to 3DS on larger orders. The WooCommerce plugin's Advanced Fraud Signals ships with a disposable-email detection option that can be paired with an auto-hold toggle; the WP Security plugin can be configured on the signup-to-checkout flow to apply the same logic at an earlier stage.

Avoid absolute precision claims on this. The actual false-positive rate depends heavily on your customer base — a meme-merch store sees a lot of disposable emails from legitimate customers; a B2B software vendor sees almost none. Start with a review-queue action rather than an outright block, measure your false-positive rate for two weeks, then tighten or relax.

Auto-Hold Rules That Don't Alienate Good Customers

The goal is to triage orders into three buckets: ship immediately (low risk), route to manual review (medium risk), and decline or hard-hold (high risk). Shopify's native fraud analysis does exactly this — low / medium / high risk recommendation, with green/red/grey indicator icons exposing the specific signals (AVS status, CVV match, IP geolocation details) behind each. The underlying ML is, per Shopify's own documentation, "trained on historical transactions across all Shopify stores."

You can build the same tiered logic explicitly on top of Stripe or any other processor. A reasonable starting ruleset:

The percentages matter. If you are auto-holding more than 2-3% of orders, your rules are too aggressive and you are losing revenue. If your chargeback rate is above 0.5% and you are auto-holding less than 1%, your rules are too loose. Most operators land at somewhere between 1% and 2% of orders in manual review, and iterate from there.

For Shopify merchants specifically, Shopify Protect is relevant context: Shopify will cover chargeback costs on eligible Shop Pay orders (including the chargeback fee) when the order is fulfilled within seven days and handled through Shopify Payments. That does not mean you can ignore fraud screening — non-Shop-Pay orders, non-fraud disputes, and orders outside the eligibility window are all still on you — but it changes the calculus on marginal Shop Pay orders.

Winning Disputed Chargebacks with IP Evidence

Not every chargeback is preventable. Friendly fraud — where a legitimate customer received the goods and then disputes the transaction with their issuer, either deliberately or because they forgot about the purchase — accounts for a substantial share of card-not-present disputes. Until 2023 you had limited options to fight these: provide tracking, hope the issuer looked at it, and absorb most of the losses.

Visa's Compelling Evidence 3.0 (CE 3.0) changed the rules specifically for friendly-fraud disputes coded as Visa reason 10.4 ("Other Fraud: Card-Absent Environment"). The framework, documented in Visa's Compelling Evidence 3.0 merchant readiness guide, lets you submit evidence of two prior undisputed transactions from the same customer — where at least two data elements match across all three transactions (the current disputed one plus the two priors), and one of those matching elements is either the customer purchase IP address or the device fingerprint.

Stripe's CE 3.0 documentation lists the exact data elements: Customer Purchase IP and Customer Device Fingerprint (or Device ID) are the "main evidence elements," with shipping address, customer email address, and customer account ID as "secondary elements." The prior transactions must be between 120 and 365 days old and must not themselves have been disputed as fraud.

The operational implication is important: log IP address and device fingerprint on every successful transaction and retain that log for at least 18 months. If a customer completes three orders with the same billing address, card, and IP country, and then disputes the fourth as fraud, you have the data to submit a CE 3.0 case — but only if you kept the IP and fingerprint on the earlier transactions. Every /api/v1/check/ip response includes the classification fields you need; persist the full response against the order record so your dispute-response workflow can query it later.

Industry dispute-management vendors like Chargebacks911 publish detailed CE 3.0 implementation guides if you want to handle the submission workflow in-house, or you can route disputes to a managed-dispute vendor that handles formatting and submission.

How Predax Helps

Predax exists to be the IP-intelligence layer under your fraud rules — the thing you call pre-checkout to get structured answers about who is connecting, then combine with your existing payment processor's ML. Every call to /api/v1/check/ip returns country_code (for billing-country comparison), asn and asn_org (for hosting-provider identification), is_hosting / is_residential / is_cloud classification booleans (for the datacenter-origin signal), and an overall risk_score you can use as a single gate or break out by component. The response is a single JSON object; you read the fields you care about and attach them to your PaymentIntent metadata or your order's fraud-review record.

For WooCommerce merchants, the Predax WooCommerce plugin wraps the API into a checkout-layer fraud engine: Order Velocity Detection with configurable windows, Advanced Fraud Signals (billing-country vs IP mismatch detection, disposable-email flagging), Country Restrictions for shipping-policy enforcement, and a Refund & Chargeback Feedback loop that blacklists or flags IPs associated with past disputes. An auto-hold toggle routes medium-risk orders to manual review rather than forcing a ship-or-decline binary. For WordPress sites running custom checkout forms, the Predax Security plugin applies the same rules at the form-submission stage, before any payment processor ever sees the request. The platform dashboard aggregates every blocked, held, or flagged event into a threat-intelligence view with per-IP drill-down, so when you're investigating a spike in chargebacks you can trace back to the specific IPs, ASNs, or countries driving it.

None of this replaces Stripe Radar or Shopify's native fraud analysis — it layers underneath them, giving you network-level signals they don't surface directly and letting you apply them as custom rules. For a WooCommerce-specific walkthrough including plugin configuration screenshots and rule examples, see our WooCommerce-specific playbook. If you're ready to add an IP-intelligence layer, view pricing for the plan tiers — the free tier is enough to evaluate the signals end-to-end against your real checkout traffic before you commit to a paid plan.

Frequently Asked Questions

What's a good target chargeback rate for Stripe?

Under 0.9% is the line you want to stay clearly below, not the line you want to ride. Visa's consolidated Acquirer Monitoring Program (VAMP) — which replaced VDMP and VFMP on April 1, 2025 — sets the 'Excessive' merchant threshold at 1.5% for acquirers monitoring their portfolios, tightening to 0.9% effective April 2026 according to Visa's VAMP fact sheet. Mastercard's Excessive Chargeback Merchant program triggers at 1.5% with more than 100 chargebacks in a month. Practical targets: aim for under 0.5% as a healthy ceiling, under 0.3% as 'no one is worried about you.' Stripe will suspend accounts well before you hit the card network thresholds because acquirer fines kick in first and Stripe absorbs those exposures.

Does 3DS eliminate chargeback liability?

It shifts liability for fraud disputes (reason code 10.4 'card absent environment fraud' under Visa) from the merchant to the issuing bank — but only when the transaction was authenticated through 3DS and the issuer didn't apply an SCA exemption. Stripe's SCA documentation is explicit about this: 'If a cardholder disputes a 3DS payment as fraudulent, the liability typically shifts from you to the card issuer,' but 'when issuers apply SCA exemptions and the payment isn't authenticated through 3D Secure, liability shift doesn't apply.' 3DS also does nothing for non-fraud disputes — 'service not as described,' 'item not received,' friendly fraud claims, etc. Those remain fully on the merchant. Treat 3DS as one layer of a layered defence, not as a silver bullet.

Can I block a whole country to stop chargebacks?

You can, and for genuine sanctions obligations you have to — but for fraud-reduction, country blocking is usually too blunt. Fraud concentrates on specific hosting ASNs and abuse-heavy subnets, not on residential users in entire countries. Blocking Nigeria or Indonesia wholesale catches some real fraudsters and far more legitimate customers, and search engines index your pricing-page geo-availability. The better approach: layer an ASN-level hosting block (catches proxies and datacenters), a billing-country-vs-IP-country mismatch rule (catches the specific pattern), and a velocity rule. See our guide on how to block visitors by country for when country rules are the right tool and when they aren't.

Does Stripe Radar already use IP reputation?

Radar uses IP signals — Stripe's Radar product page specifically calls out 'proxy detection' and IP-related signals, and Radar rules can reference the IP country and whether the card country matches. But the depth of IP reputation you get from a dedicated service is higher: per-ASN risk scoring, VPN vs datacenter vs residential-proxy classification, real-time Tor exit lists, and hosting-provider tagging. Radar's strength is network effects from the billions of transactions it sees; a dedicated IP-intelligence service's strength is deep network-layer signals. They're complementary, not redundant. Teams that care about chargebacks run both and use Radar's rule engine (or a pre-checkout middleware hop) to combine the two.

Related guides

• WooCommerce fraud prevention — the same playbook, applied inside WooCommerce specifically.
• Account takeover prevention — many chargebacks trace back to a compromised account, not a stolen card.
• How IP risk scoring works — the score behind the auto-hold rules in this playbook.
• How to detect VPN users — the single most common red flag on a fraudulent checkout.

Selling on WooCommerce or Shopify? Drop the WooCommerce plugin or Shopify app in and pick a plan.