Use an IP risk signal in signup without calling it identity verification

A signup handler receives an IP risk result and someone proposes rejecting anything above a threshold, or labeling low scores as verified users. Both moves treat a network signal as a verdict about a person. This article shows how to keep an IP risk check as one input to your own decision, using the synthetic contract sample for the registration_risk task, and lists what must be true before any real check runs.

The problem and the decision

Your SaaS or marketplace signup collects an IP address and you want to know whether the connection looks risky. The decision you face is not whether to trust the person; it is what your application does with a signal that describes a network origin. The product output is defined narrowly: IP risk signals and available explanatory evidence for the event, not an identity or fraud verdict. A risk score alone must not approve or reject a person. So the design question becomes: which branch of your signup does a signal move the user into, and which evidence does a human or a later step still need?

What the contract asks for and returns

Inputs are an authorized public IP address, a consent reference, a stable request UUID and an explicit trial or paid mode. The stable UUID lets a retried request be recognized as the same event rather than a second check. The explicit mode matters because paid mode requires confirmed prepaid credit; nothing should silently switch from trial to a charge. Real execution also requires current supplier readiness and an eligible merchant. The tested sample output in the supplied material is: status unavailable, ip_risk_score null, verified false, automatic_business_approval false. This is a synthetic contract example, not live acceptance, and no live provider request is performed by it.

A hypothetical worked scenario

Hypothetically, a developer wires the signup form so that after email entry the backend sends the authorized IP, the consent reference and a new request UUID in trial mode. The supplier is not ready, so the result matches the fixture: status unavailable, ip_risk_score null, verified false, automatic_business_approval false. A naive handler reads null as zero and lets the account through as low risk. A stricter naive handler reads unavailable as risky and blocks it. The proposed design does neither: it records the event as unscored, continues signup through your normal controls, and keeps the same request UUID so a later retry is not counted as a new event. The verified field stays false in every case, because this product never verifies identity.

Expected fixture outputs to assert

Write tests that assert exactly these values for the sample: status equals unavailable; ip_risk_score is null, not 0; verified is false; automatic_business_approval is false. Add assertions in your own code that a null score never maps to a low-risk label, that no branch sets an identity-verified flag from this result, and that automatic_business_approval false prevents your handler from granting or denying an account on the IP signal alone. These tests check your application logic against the contract shape. They do not prove a supplier answered, that a merchant is eligible, or that any real user was assessed.

Failure handling

Treat unavailable as its own state, separate from low risk and from high risk. If credit is not confirmed, do not attempt paid mode; surface a configuration problem rather than a user-facing rejection. If consent is missing, do not send the IP at all. On a timeout or retry, reuse the request UUID. When a real score does arrive, route it to a review or additional-check branch, together with any explanatory evidence, instead of a final approve or reject. Log what was asked, in which mode and what came back, without storing more personal data than your consent covers.

Acceptance checklist

Before enabling a real check, confirm: the IP is public and its use is authorized; a consent reference exists per event; each event has one stable request UUID; mode is explicit; paid mode is blocked without confirmed prepaid credit; supplier readiness and merchant eligibility are checked at run time, not assumed from documentation; unavailable and null are handled distinctly from low risk; no code path labels a user verified from this result; no code path approves or rejects a person on the score alone; tests assert the four fixture fields above. Passing synthetic tests is evidence about your handler, not live business permission.

Disclosure: this tutorial was drafted with AI and checked against executable local examples and an independent factual review. Sample values are test inputs, not verified people or accounts. Application policy remains the caller’s responsibility.