Ask ten payment teams what stops fraud and you will hear ten different single answers: rules, machine learning, 3-D Secure, manual review. The honest answer is a stack. Every working payments defense is layered, because every layer has a blind spot and attackers aim at whichever one you skipped. This guide maps the stack end to end and focuses on the layer that fires first and costs least: the network. Used correctly, IP intelligence removes whole attack classes before they ever reach your payment processor, and it quietly improves every layer behind it.
The problem, sized honestly
Card fraud is not shrinking. The Nilson Report puts worldwide card fraud losses at $33.45 billion in 2022, projected to pass $43 billion by 2028, with US losses overwhelmingly a card-not-present problem (Nilson Report). And the cost asymmetry is brutal in both directions: every $1 of fraud costs US retail and ecommerce merchants $4.61 once labor, investigation, and recovery are counted (The Paypers), while over-blocking legitimate orders leaks revenue silently. A payments defense has to cut fraud and false declines at the same time, which is precisely what graduated, layered systems are for.
Know your attacker: the four payment attack families
OWASP's automated-threats catalog names the industrial versions (OWASP Automated Threats):
| Attack | OWASP ID | What happens | The tell |
|---|---|---|---|
| Card testing | OAT-001 Carding | Bots run small authorizations through bulk stolen cards to find live ones | High attempt velocity, datacenter or proxy origins, tiny amounts |
| Card cracking | OAT-010 | Bots brute-force missing expiry dates and CVVs for partial card data | Many declines per card, systematic parameter variation |
| Cashing out | OAT-012 | Validated stolen cards used for real purchases or gift cards | Geo mismatch, anonymizers, rush shipping, digital goods |
| Checkout ATO | (account layer) | A hijacked customer account pays with the stored card | New network and device on a trusted account |
Friendly fraud, where the real cardholder disputes a genuine purchase, sits outside this table on purpose: no network signal sees it coming, which is a stack lesson in itself.
The stack, layer by layer
- Network layer (pre-authorization). Score the IP on every checkout, card update, and payment attempt. This is where datacenter scripts, anonymized sessions, and high-velocity origins get filtered before they cost you anything.
- Velocity layer. Attempts per IP, per /64 prefix, per card, per account, per campaign. Cheap counters catch what reputation misses.
- Device and behavior layer. Fingerprints and session behavior recognize returning customers and spot automation that survived the network filter. The division of labor is covered in device fingerprinting vs IP intelligence.
- Issuer authentication layer. 3-D Secure risk-based authentication, where the issuer approves low-risk orders frictionlessly and challenges the rest, and authenticated fraud liability shifts to the issuer (Visa on 3-D Secure).
- Review and evidence layer. Manual review queues for the genuinely ambiguous, and logged evidence for the disputes you fight later, as covered in reducing chargebacks with IP detection.
The order matters because cost rises with depth. An IP lookup is milliseconds and fractions of a cent. A 3-D Secure challenge costs conversion. A manual review costs minutes of a human analyst. A chargeback costs the goods, the fees, and your dispute ratio. Every attack you stop at layer one never bills you at layer five.
What the IP layer contributes before authorization
Infrastructure honesty. Real customers pay from residential and mobile connections. A checkout from a datacenter or hosting range is automation until proven otherwise, and connection type plus ASN type is the cheapest first-pass filter you can run.
Anonymization at the payment step. VPN and proxy flags on browsing are weak evidence on their own. The same flags appearing specifically at the card entry step, or a Tor exit at checkout, deserve friction. The detection mechanics are in how VPN and proxy detection works.
Geographic consistency. Three countries should usually agree: the IP's location, the card BIN's issuing country, and the shipping or billing address. One mismatch is a traveler or a VPN. All three disagreeing on a first order with rush shipping is a pattern worth challenging.
Velocity keyed correctly. Card testing runs hundreds of attempts per origin. Key your counters on the IP and, for IPv6, on the /64 prefix rather than the full address, or a single ring will look like thousands of users (rate-limiting IPv6 by /64).
The dampeners. Carrier-grade NAT parks thousands of legitimate customers behind one address, and roughly one in four internet users runs a VPN (Security.org). A CGNAT flag should soften your response to shared-IP velocity, not sharpen it.
Card testing deserves its own paragraph
Card testing affects about a third of ecommerce merchants globally (card testing statistics), and it is the purest example of an attack the IP layer should simply delete. The bots validate stolen cards with small authorizations, you pay the authorization and decline fees either way, and every card they validate becomes real fraud somewhere else. The traffic profile is unmistakable: datacenter and proxy origins, machine-speed attempt rates, tiny or zero-dollar amounts. Score the IP before the request reaches your processor, rate-limit per address and per prefix, and quietly reject or sandbox what fails. Stopping card testing at the network edge is the highest-ROI fraud control most payment teams have not fully deployed.
Feed the issuer, do not fight it
3-D Secure is not a rival to your own detection; it is a layer that runs on signals. The issuer decides frictionless versus challenge based on the risk picture it can see, and you decide which orders to send into that flow at all. The working pattern mirrors per-action fraud score thresholds: allow the clean band frictionlessly, route the medium band into a 3-D Secure challenge so authenticated fraud liability shifts to the issuer, and block the corroborated-bad band before authorization so it never touches your approval rate. IP intelligence is what sorts those bands cheaply and explainably.
What the IP layer cannot see
Be precise about the blind spots, because they define the rest of the stack. The IP cannot see friendly fraud, where the legitimate cardholder on their usual home network disputes a purchase they made. It cannot flag a stolen card used from the victim's own neighborhood. It cannot tell two customers apart behind one CGNAT address without help. Those gaps are why device recognition, issuer authentication, and post-transaction review exist, and why IP risk scoring is designed to be one explainable input into a decision rather than the decision itself.
How GeoIPHub answers it
One lookup per payment attempt returns the pre-authorization picture: connection_type and asn_type separate residential and mobile customers from datacenter and hosting scripts; the detection block flags VPN, proxy, Tor, and relay exits with the proxy_type and anonymity_level behind each flag; the geo block gives you the IP-side country for BIN and address consistency checks, with a geo_confidence so you know how hard to lean on it; is_cgnat marks shared carrier addresses so you dampen instead of decline; and the explainable 0-100 fraud score arrives with a recommended_action (allow, review, step-up, or block) that maps directly onto the frictionless, challenge, and block bands of your 3-D Secure routing. Every field ships on the free tier at 1,500 lookups per day, and you can check any IP's fraud score without an API key before wiring it into your payment flow.
Where this fits in your fraud stack
This post is the map; the neighboring guides are the terrain. The threshold numbers live in what IP fraud score to block at, the account-security door is covered in detecting account takeover and credential stuffing, the dispute-side payoff in reducing chargebacks with IP detection, and the ten-minute integration in adding IP fraud detection with a free API. Build the network layer first. It is the only layer that gets cheaper the earlier it runs.
Frequently Asked Questions
What is payment fraud detection?
Payment fraud detection is the set of checks a business runs before, during, and after a transaction to catch unauthorized or deceptive payments: stolen card use, card testing, account takeover at checkout, and friendly fraud. Mature systems are layered rather than monolithic. Network and IP checks run first, velocity and device signals corroborate, issuer authentication like 3-D Secure handles the medium-risk band, and post-transaction review plus chargeback evidence closes the loop.
Which IP signals matter most at checkout?
Four families do most of the work: connection type and ASN type (a consumer checkout from a datacenter or hosting range is a script until proven otherwise), anonymization flags (VPN, proxy, Tor, or residential proxy at the payment step), geographic consistency (IP country versus card BIN country versus shipping address), and velocity keyed on the IP and its IPv6 /64 prefix (many card attempts from one origin is card testing). Each needs context, since carrier-grade NAT and mainstream VPN use are normal.
What is card testing and how do I stop it?
Card testing (OWASP OAT-001 Carding) is bots running small authorizations through bulk stolen card numbers to find which cards are still live. Each attempt costs you authorization fees, and each success later becomes real fraud somewhere. It is the most IP-solvable payment attack: the bots run from datacenter ranges and proxy pools at rates no human matches, so scoring the IP and rate-limiting per address and per /64 prefix before the request reaches your processor removes most of it.
Does 3-D Secure replace fraud detection?
No. 3-D Secure is an authentication layer that shifts fraud liability to the card issuer for authenticated transactions, and its risk-based flow works best when it receives rich signals. Challenge everything and you lose conversions; challenge nothing and you keep the liability. The practical pattern is to use your own risk scoring, including IP intelligence, to decide which transactions to route into a 3-D Secure challenge, which to allow frictionless, and which to block before authorization at all.
Should I block VPN users at checkout?
Not automatically. Roughly one in four internet users runs a VPN, mostly for legitimate privacy, so a hard block on any VPN flag rejects real revenue. Treat an ordinary VPN flag as a reason to add verification, such as routing the order into a 3-D Secure challenge, and reserve hard blocks for corroborated cases like Tor exits or known-abuse IPs combined with other risk signals such as geographic mismatch or high velocity.
