How a payments platform scores every user's signup IP with IPQualityScore, turning VPN, Tor, and bot signals into an anti-fraud gate within its automated trust score.
Key findings
A payments platform scores every user's signup IP with IPQualityScore, turning connection signals like VPN, Tor, and bot activity into an anti-fraud gate at onboarding.
The IP check is one weighted input in an automated user trust score, alongside a business-records check, an email-risk check, and a phone-reputation check.
The gate is binary at the edges: a VPN, Tor, or non-US IP hard-zeros the contribution, no matter how clean everything else looks; otherwise the score is the inverse of the fraud score, scaled to the check's weight.
The full IPQS response is persisted to a dedicated fraud-check record - fraud score, VPN and Tor flags, bot status, proxy, ISP, ASN, and full geolocation - so a rich picture survives for triage and audit.
The largest trade-off: the check is written to fail hard, but the caller swallows the exception, so an IPQS outage silently drops the whole fraud record and removes the IP check's contribution from the trust score.
When a user signs up, their IP address is one of the first things you learn about them, and it carries more signal than most people expect: whether they are hiding behind an anonymizing network, whether the traffic looks automated, and whether the connection has a recent reputation for abuse. This is a look at how a payments platform turned that signal into an automatic anti-fraud gate. Every onboarding IP gets scored by IPQualityScore, the full result is stored, and a small piece of gate logic decides whether that IP contributes to the user's trust score or zeroes it out. The writeup covers what IPQS checks, how the gate decides, how it behaves across real signups, and where the design makes deliberate - and a few accidental - compromises.
What does IPQualityScore actually check?
IPQualityScore returns a risk profile for an IP address, centered on a fraud score from 0 to 100 plus a set of flags that explain why. The core signals are whether the connection is a VPN, Tor, or proxy, whether it shows bot activity, whether it has a recent history of abuse, and where it geolocates. IPQualityScore's documentation describes its IP reputation and proxy-detection API as a real-time way to catch high-risk connections before they transact.
A few of those terms are worth defining plainly, because the whole gate turns on them. A VPN (virtual private network) routes a user's traffic through an intermediary server, hiding their real IP and location. Tor is an anonymity network that bounces traffic through several relays so the origin is very hard to trace. A proxy is any server that relays a request on someone's behalf, again masking the source. All three are legitimate privacy tools, but they are also the standard way a fraudster hides where they really are.
The fraud score itself is a single 0 to 100 read on how risky the IP looks, where higher is worse. A residential connection with no history scores near zero; a known abusive proxy scores near 100. Around that score sit the flags and the metadata - bot status, the internet service provider, the ASN (the network operator's ID), and a full geolocation down to city and coordinates - which together turn a bare number into an explanation.
Why does a user's IP matter for fraud?
A user's IP matters because it is the one signal you get for free, on the very first request, before the user has typed a single field. A business-records or phone check needs information the user has to supply; the IP is simply there the moment they load the signup page. That makes it the earliest possible read on intent, and a strong one: genuine users tend to sign up from ordinary residential or business connections in the country they operate in, while a meaningful share of fraud arrives from anonymizing networks and automated traffic.
The cost of ignoring that signal is fraud that clears onboarding and human time spent unwinding it later. A payments platform is a direct target - approve the wrong user and you have handed a fraudster a way to move money. So the platform needed a way to read the connection automatically, at the moment of signup, and to let a clearly bad connection pull a new user's trust score down before anyone spends effort on the account.
IP is also a good complement to the platform's other checks precisely because it looks at a different layer. Email risk, phone reputation, and business records all describe who the user claims to be. The IP describes how they showed up. A signup can have a clean-looking email and still arrive over Tor - and that mismatch is exactly the kind of thing an automated gate should catch.
How does the platform score an IP at signup?
The platform sends the user's IP to IPQualityScore during onboarding, stores the entire response as a fraud-check record, and then runs a small piece of gate logic to decide how much that IP contributes to the trust score. The check runs only when an IP is present on the onboarding input; if there is no IP, there is nothing to score.
One IP check at signup: the full IPQS response is stored, then the gate turns it into zero or a weighted contribution and the record surfaces in the leads view.
The integration is a small, self-contained NestJS service with one job: take an IP (and, optionally, the browser's user agent and language) and return a typed fraud-check response. It builds the request URL from a base URL and an API key loaded from a secrets store, calls IPQS, stamps the queried IP back onto the response so the record is self-describing, and returns it. Unlike the platform's email-risk check, this service is written to fail hard: if IPQS errors, it throws an HttpException rather than returning nothing.
interface FraudCheckResponse { fraudScore: number; // 0-100, higher is riskier vpn: boolean; tor: boolean; proxy: boolean; recentAbuse: boolean; botStatus: boolean; countryCode: string; // e.g. "US" ISP: string; ASN: number; ip?: string; // stamped back on so the record is self-describing}@Injectable()export class IpqsService { constructor( private readonly http: HttpService, private readonly config: ConfigService, // apiKey + baseUrl loaded from SSM at boot ) {} /** Score a single IP. Throws on any failure (fail-hard by design). */ async checkIp(ip: string, userAgent?: string, userLanguage?: string): Promise<FraudCheckResponse> { const baseUrl = this.config.get<string>('ipqs.baseUrl'); // .../api/json/ip/ const apiKey = this.config.get<string>('ipqs.apiKey'); try { const { data } = await firstValueFrom( this.http.post<FraudCheckResponse>(`${baseUrl}${apiKey}/${ip}`, null, { params: { user_agent: userAgent, user_language: userLanguage }, }), ); return { ...data, ip }; // stamp the queried IP back onto the response } catch (err) { throw new HttpException('IPQS fraud check failed', HttpStatus.BAD_GATEWAY); } }}
Two design choices are worth calling out. First, the API key and base URL are loaded from AWS Systems Manager Parameter Store at boot rather than committed to the codebase, so the key can be rotated without a redeploy rather than living in the repo. Parameter Store is AWS's managed store for exactly this kind of configuration. Second, the service stamps the queried IP back onto the response before returning it, so the stored fraud-check record is self-describing and can be read on its own without cross-referencing the request that produced it.
What gets stored from each check?
The platform stores the entire IPQS response, not just the number the gate consumes. Each onboarding writes a fraud-check record that captures the fraud score, the VPN and Tor flags (including the "active" variants), the proxy and recent-abuse flags, the bot status, the connection type, the ISP and ASN, an abuse-velocity signal, and a full geolocation block: country, region, city, latitude, longitude, and postal code.
Keeping the full response is a deliberate hedge against the thinness of a single score. The gate only needs the fraud score and a couple of flags, but a person triaging a suspicious lead - or an auditor reviewing a rejected user months later - benefits from the whole picture: not just that the score was high, but that the IP was a known proxy in a data center on the other side of the world. That richness is why the record is worth storing even though most signups never get a human look.
It is also worth flagging up front, because it cuts the other way: this record is a fair amount of personal and location data per signup. Latitude, longitude, city, and ISP are meaningful signals, but they are also the kind of data that carries retention and privacy obligations. That trade-off is covered in the risks below.
How does the gate turn a fraud score into points?
The gate is a short piece of logic that converts the stored response into a weighted contribution, and it is deliberately unforgiving at the edges. If the IP is flagged as a VPN or Tor, or if the country code is anything other than US, the contribution is hard-zeroed. Otherwise, the contribution is the inverse of the fraud score scaled to the check's weight.
The gate: a VPN, Tor, or non-US IP hard-zeros the contribution; otherwise it is the inverse of the fraud score at the check's weight.
/** Convert a stored fraud-check response into weighted trust points. */function ipqsPoints(check: FraudCheckResponse, weight: number): number { const isAnonymized = check.vpn || check.tor; const isForeign = check.countryCode.toLowerCase() !== 'us'; if (isAnonymized || isForeign) return 0; // hard fail return (100 - check.fraudScore) * weight; // inverse of fraud score, scaled to weight}
The math is easy to reason about. A pristine IP with a fraud score of 0 lands the check's full weight. A borderline IP scoring 40 lands a little over half of it. A high-risk IP scoring 90 lands almost none. But cross the VPN, Tor, or non-US line and none of that matters - the contribution snaps to zero. That binary behavior is the point of a gate: some conditions are treated as disqualifying regardless of the underlying score. It is also, as the risks section explains, where the design is most opinionated and most likely to catch a legitimate user.
The same fraud-check record that feeds the gate is also surfaced to people. It appears in the internal leads view as a fraud breakdown, so an agent looking at a user can see the VPN and Tor flags, the fraud score, and the geolocation behind the trust-score number, and there is a user callback flow that reads the same record. The stored response does double duty: an input to automated scoring and a human-readable explanation of it.
How much does the IP check weigh in the overall trust score?
The IP check is one ingredient in a larger automated trust score, contributing one weighted input, not the whole verdict. The composite blends four independent checks: a business-records check, an email-risk check, a phone-reputation check, and the IPQS fraud check. Each is normalized and weighted, then summed into a single figure that ranks how much automated confidence the platform has in a new user.
In practice the IP check contributes its weight in proportion to the fraud score. A clean US residential IP lands most or all of it; a user on a VPN, on Tor, or outside the US contributes zero from this input regardless of everything else. Because the four inputs are independent, a hard-zeroed IP drags the composite down on its own, which is what surfaces a suspicious signup for review even when the other signals look ordinary.
Keeping the IP weight modest rather than higher is deliberate. The connection is a strong signal but a blunt one - a privacy-conscious real user might genuinely sign up over a VPN. Capping its influence means the IP gate alone cannot sink an otherwise-solid user, while a cluster of weak signals across the four checks still adds up to a clear flag. The cap is the safety valve on an intentionally strict gate.
How does it behave across three real scenarios?
The design is easiest to understand through the signups it was built for. Three cases cover the range.
Scenario 1: a clean US residential IP
A user signs up from an ordinary home broadband connection in the US. IPQS returns a low fraud score - say 5 - with no VPN, Tor, or proxy flags and a US country code. The gate passes, the contribution is the inverse of that low score scaled to the check's weight - nearly the full amount - and the full record is stored showing a residential connection and a matching geolocation. Nothing interrupts onboarding; the IP signal simply reinforces the other checks, and an agent triaging the lead sees a clean fraud breakdown and moves on. Most legitimate sign-ups land here and never get a second glance, which is the point.
Scenario 2: a VPN, Tor, or non-US IP
A signup arrives over a VPN, over Tor, or from an IP that geolocates outside the US. The gate hard-zeros the IP contribution no matter how low the underlying fraud score is, and the full record is stored with the flags that explain the decision. On its own this will not block the account, but it removes the IP check's contribution from the composite and paints a clear reason in the leads view. This is the gate doing its job against an anonymizing fraudster - but it is also where a legitimate, privacy-conscious user on a VPN gets caught in the same net. The record preserves why, which is what lets a human override a false positive; the risks section returns to this.
Scenario 3: the IPQS call fails
If the IPQS request errors or times out, the service throws - fail-hard, as designed. But the onboarding caller wraps the check in a try/catch that swallows the exception so signup is never blocked. The unintended consequence is that no fraud-check record is written at all: the whole rich response is lost, and the IP simply contributes nothing to the trust score. From the outside this is indistinguishable from a user who scored zero for a real reason. The signup completes, but the IP check's slice of the trust math has silently gone missing, and there is no record to explain it after the fact. The trade-off this creates is covered next.
What are the risks and gotchas?
The design makes several deliberate compromises and one accidental one, and knowing them matters for anyone auditing the trust score or extending the integration.
A US-only assumption is baked into the gate. Any non-US country code hard-zeros the IP contribution. That is fine for a US-only product, but it silently penalizes every legitimate non-US user the moment the platform expands, and it does so through code rather than configuration - so growing into a new market means editing the gate, not flipping a setting.
VPN and Tor are treated as disqualifying, not as signals. A privacy-conscious real user who happens to sign up over a VPN gets the same hard zero as a fraudster hiding on one. Because the gate is binary, there is no room for "on a VPN but otherwise pristine" to net out to a small positive. The full record preserves the flags so a human can override, but the automated score gives the benefit of the doubt to no one.
Fail-hard plus a swallowed exception equals a silent hole. The service is written to fail hard, which is a reasonable stance, but the caller's try/catch swallows the thrown exception to keep signup resilient. The combination means an IPQS outage produces no fraud-check record and a silent gap in the trust score - and, because nothing is stored, an auditor cannot tell a genuine zero from a failed call without reading logs. Fail-hard was meant to make failures loud; the swallow makes them silent.
The fraud score is applied linearly, with no tiering. Every point of fraud score maps straight to a proportional loss of trust points. There are no bands - no "0 to 20 is clean, 80 to 100 is block" - so a score of 49 and a score of 51 are treated as nearly identical even if the platform would want to act very differently on them. A tiered mapping would let policy, not arithmetic, decide where the meaningful thresholds sit.
Each check stores a lot of PII and geolocation. The full response includes city, latitude, longitude, ISP, and connection details for every signup. That richness is useful for triage, but it also creates data-retention and privacy obligations that a bare score would not. Storing it should be a conscious decision with a retention policy behind it, not an accident of keeping the whole payload.
What would we do differently?
The most valuable change would be to make the country gate configurable and multi-region instead of a hard-coded !== 'us'. Driving the allowed countries from configuration turns market expansion into a settings change and removes an invisible penalty on legitimate foreign users.
Close behind is fixing the silent hole: persist a minimal fraud-check record even when IPQS fails - enough to mark the check as "attempted, unavailable" - so the trust score can distinguish unknown from clean and an auditor can tell an outage from a genuine zero. That is a small schema change with an outsized effect on how trustworthy the composite is.
Beyond those two, three enhancements are natural: treat VPN as a weighted signal rather than an automatic disqualifier, so a privacy-conscious real user is not zeroed for a legitimate choice; replace the linear fraud-score mapping with tiered bands so policy sets the thresholds; and pair the rich stored record with an explicit retention policy so the PII it holds is a deliberate choice. The gate blocks anonymized fraud today without any of these; what they buy is fairness to legitimate outliers and an honest audit trail when the check fails.
Frequently asked questions
What does IPQualityScore check on an IP address?
It returns a fraud score from 0 to 100 plus flags that explain it: whether the connection is a VPN, Tor, or proxy, whether it shows bot activity, whether it has a recent history of abuse, and where it geolocates. Together those give a fast, automated read on how risky a connection looks before a user transacts.
Does a high fraud score block a user from signing up?
No. The IP check never blocks onboarding on its own. It contributes one weighted input to an automated trust score and shows up as a fraud breakdown in the leads view, but the decision to slow down or reject a user stays with people and the composite signal, not with the IP score alone.
Why does a VPN or a non-US IP zero out the score?
The gate treats a VPN, Tor, or non-US IP as disqualifying: those conditions hard-zero the IP contribution regardless of the underlying fraud score. It is an intentionally strict stance against anonymizing fraud, but it is also the design's biggest source of false positives, since a legitimate user on a VPN or outside the US is caught by the same rule.
What happens if IPQS is unreachable during signup?
Onboarding continues. The check is written to fail hard, but the caller swallows the exception so signup is never blocked. The side effect is that no fraud-check record is written and the IP contributes nothing, so the IP check's contribution silently goes missing and a failed call looks identical to a genuine zero.
How much does the IP check influence the trust score?
It is one of several weighted inputs, and deliberately capped low. The composite blends four independent checks - business records, email risk, phone reputation, and the IPQS fraud check - with the IP check carrying one of the smaller weights. The cap keeps a single blunt signal from sinking an otherwise-solid user.
Does the platform store the full IPQS response?
Yes. The entire response is persisted to a fraud-check record: fraud score, VPN and Tor flags, proxy and abuse flags, bot status, ISP, ASN, and full geolocation. The gate only consumes a few of those fields, but the full record powers triage in the leads view and gives auditors a picture of why an IP scored the way it did.
DesignKey research: Email risk scoring at onboarding with ZeroBounce: /research/email-risk-scoring-zerobounce
What's next
The IP check does one well-defined job today: a fast, automated read on how a user showed up, one weighted input in the trust score, backed by a full record for the cases a human needs to look at. The clearest next steps are making the gate fair - configurable countries and a weighted VPN signal instead of a hard block - and making it honest - persisting a record even when the call fails, so unknown stops masquerading as clean. If you are building signup fraud scoring and want to talk through where a gate belongs and where a weight does, get in touch. For a look at the sibling signal in the same trust score, see how the platform handles email risk scoring at onboarding, and for the broader build work behind these checks, our SaaS development, API integration, and backend and cloud services.
