How the attack works
Card fraud against a D2C store is a logistics problem for the attacker, not a payments one. The card details are already bought. What has to be solved is arriving at checkout looking like a customer the risk engine wants.
Residential proxies solve most of it in one purchase. The order exits through a real consumer connection, ideally geographically near the billing address on the card, so:
- IP reputation returns clean, because a subscriber line has no history of abuse.
- IP-to-billing geolocation matches, which is a positive signal in most scoring models — the attack turns one of your defences into evidence in its favour.
- Velocity rules see nothing, because each order has its own address.
- AVS passes, because the billing address is the real one from the stolen card. AVS was never a fraud control; it is an address-match control, and it does exactly what it says.
3DS is the genuinely effective layer, and its coverage is uneven: exemptions, out-of-scope regions and frictionless flows all leave gaps, and the liability shift only helps where the challenge actually ran.
Why the usual defences miss it
Nearly every control in a standard stack is asking about the card or the address. Both are genuine. The stolen part is the authority to use them, and no amount of validating the details surfaces that.
The IP is the one field that could carry the signal, and it is the field the proxy was bought to neutralise. A datacenter check is not enough: the entire product being sold to the attacker is "our exits are not datacenters". If your risk engine treats not datacenter as clean, the proxy vendor is being paid specifically to exploit that assumption.
What the verdict returns
One request at checkout, before the authorisation:
{
"decision": "block",
"risk_score": 88,
"reasons": [
"residential_proxy",
"automation_detected"
],
"network": {
"vpn": false,
"proxy": true,
"datacenter": false,
"tor": false,
"provider": "residential pool"
},
"device": {
"antidetect": false,
"automation": true,
"linked_accounts": 6
}
}proxy: true with datacenter: false is the residential signature, and it is the field combination the rest of your stack cannot produce. Everything else on the order — card, address, email, geolocation — is designed to look correct, and does.
Where to put the decision
Before the authorisation, not after. A declined authorisation still costs a gateway fee and still tells a card tester which numbers are live, which is the actual product they came for. Screening at the checkout request means a refusal is free and silent.
For the middle band, step up rather than refuse: force 3DS on review, or hold the order for manual release. A genuine customer on a VPN completes a challenge; an operation running volume does not find it worth the friction.
The arithmetic
A worked model. Replace the inputs with yours.
| Input | Model value | Yours |
|---|---|---|
| Monthly orders | 9,000 | — |
| Average order value | €72 | — |
| Dispute rate | 2.3% | — |
| Chargeback fee charged by your acquirer | €18 | — |
That is 207 disputes a month: €14,904 in lost goods and revenue plus €3,726 in fees, before any staff time. The compounding cost is the ratio itself — card scheme monitoring programmes are keyed to dispute rate, and entering one brings per-dispute fees and remediation requirements that dwarf the underlying losses. Check your acquirer's current published thresholds rather than any number quoted on a vendor page, including this one.
What the model is really for: it shows the dispute rate is the term to move, not the absolute loss. A store can grow its way out of a loss number and cannot grow its way out of a ratio.
Why residential proxies are hard to stop
A residential proxy network resells access to real consumer connections — sourced through SDK bundling in free apps, browser extensions, or outright compromise, with varying degrees of consent from the person whose line it is. The address genuinely belongs to an ISP subscriber, which is why the reputation answer is truthfully clean.
Detection therefore cannot come from the address's history. It comes from knowing the networks as operators: which ranges are being resold, how exits rotate, and what the routing looks like from the outside. That is a maintained intelligence problem rather than a list lookup, and it is the reason a static blocklist download will never solve this. More in the residential proxy detection guide.