Cutting card-not-present fraud at the checkout edge
How a fast-growing payments startup used Predax to block high-risk traffic before it hit their risk engine.
Audience
Payments startup
Fintech / Payments
Reference stack
Python • FastAPI • PostgreSQL • Kafka • Redis
Material reduction in card-not-present fraud after enabling pre-decision IP filtering
Lower manual-review volume by routing low-risk traffic past the analyst queue
Sub-150ms latency impact on checkout decisions
A fast-growing payments startup was scaling quickly across new markets and card schemes. Fraud losses were growing faster than volume, and the risk team was spending more time on manual reviews than on improving models.
They already had a rules engine and a basic device fingerprinting setup, but they lacked reliable network-level signals. VPNs, proxies, and high-risk networks were slipping through, especially on mobile.
The team introduced Predax as a lightweight pre-check before their existing risk engine. For each checkout and signup, they called the Predax /v1/check endpoint with the client IP and attached the resulting score, risk flags, and network metadata to the event.
Within two weeks, they had enough data to build targeted rules: blocking traffic from known bad ASNs, adding friction for high-risk VPN ranges, and fast-tracking low-risk repeat customers. Because Predax runs as a separate, low-latency call, they were able to tune thresholds without touching their core payment logic.
Results with Predax
- Card-not-present fraud rates fell materially over the first deployment window, with no measurable increase in false positives.
- Manual review volume dropped, as analysts could quickly triage cases using IP risk scores and network history.
- The additional network call added under 150ms to the 95th percentile checkout latency, well within their SLOs.