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 cloud-server (datacenter) check is not enough: the entire product being sold to the attacker is "our exits are not cloud servers". If your risk engine treats not a cloud server as clean, the proxy vendor is being paid specifically to exploit that assumption.
What the verdict returns
One server call to POST /v1/evaluate at checkout, before the authorisation. Example response for a scripted checkout through a residential proxy (excerpt):
{
"decision": "block",
"risk_score": 90,
"reasons": [
"proxy_detected",
"automation_detected"
],
"network": {
"vpn": false,
"proxy": true,
"datacenter": false,
"tor": false,
"residential": false,
"service": "<proxy service name when known>"
},
"device": {
"antidetect": false,
"automation": true
}
}There is no separate "residential proxy" reason: a residential exit shows up as proxy_detected, with proxy: true and datacenter: false. residential reads false whenever proxy is true — the line may belong to a consumer ISP, but the visit is not coming from the shopper's own connection. A proxy is a block by default, with or without the automation flag; a VPN on its own would be review. That field combination is one that IP reputation, AVS and geolocation checks 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.
Start in watch mode: log the decision next to each order and let every checkout continue, then enforce once the log matches what your disputes say. If you change actions on the console's Rules tab, a rule changes the decision only for the signal it names, so a review rule on another signal leaves this proxy block in place.
What this layer does not do: Maskbreak scores the visit, not the order. It has no chargeback guarantee, no card or issuer data and no order-level scoring. Keep 3DS and your payment processor's fraud tools; this sits in front of them as the network and device check.
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, which is why Maskbreak's network intelligence can flag the proxy on a live visit (and names the service when known), while a static blocklist download cannot. More in the residential proxy detection guide.