Protect free trials without making honest customers prove themselves

A free trial should remain easy for a new customer and expensive to repeat at scale. Device and network intelligence helps you reserve extra checks for attempts that resemble earlier redemptions instead of adding friction to every signup.

Create a free project Explore the API

Start with the free plan. No card required.

Trial abuse is a sequence, not one suspicious field

People repeating a trial can rotate email addresses and delete cookies in seconds. Blocking a domain or IP catches some attempts, but it also affects families, coworkers and mobile users who legitimately share infrastructure. The useful evidence sits in the relationship between the current attempt and earlier ones.

IPCheckHQ gives your backend a project-scoped device ID, browser component hashes, IP, ASN, network type and consistency observations at the moment a trial is requested. Combine those with your previous redemptions, payment fingerprint and promotion rules to decide whether to grant the trial, require a card or offer a different path.

What you can build with it

Keep the first trial fast

Normal attempts can continue without an additional challenge when the available evidence does not indicate a repeat.

Make repetition costlier

Recognize returning browser environments even when cookies are cleared or the visible IP changes.

Protect conversion

Escalate suspicious combinations instead of placing a CAPTCHA, phone check or payment requirement in front of every visitor.

A short path from browser to backend

1
Verify before granting access
Exchange the token before creating the entitlement so a late result cannot leave an unprotected gap.
2
Compare with redemption history
Check the device ID and independent account or payment evidence within the policy's defined lookback period.
3
Offer a fair next step
Ask for a card, switch to a limited plan or request review rather than showing a vague rejection.

Representative exchange response

POST /api/verify/v1/exchange

{
  "device": {
    "id": "dev_7da…",
    "visitor_id": "f8c…",
    "confidence": 0.97,
    "canvas_hash": "sha256:…",
    "webgl_hash": "sha256:…"
  },
  "network": {
    "asn": 13335,
    "network_type": "residential",
    "vpn": false,
    "hosting": false
  },
  "consistency": {
    "timezone_matches_ip": true
  }
}

Limitations worth designing for

A repeated device can represent another person in the same household or workplace.
Someone using a new device can still be a repeat customer, so absence of a match is not evidence of eligibility.
Aggressive hard blocks can cost more legitimate conversions than the trial abuse they prevent; measure the outcome of each rule.

Privacy is part of the implementation

Collect the verification when the trial decision is made, retain only what the eligibility policy needs, and describe the anti-abuse use in your privacy information. Keep an accessible path for customers who are incorrectly identified as repeats.

Read the IPCheckHQ privacy approach

Practical questions

Can users bypass this by clearing cookies?: Clearing cookies does not directly clear the browser signals used to derive a fingerprint, although browser updates and privacy tools can change them.
Should a repeat device always lose the trial?: No. Treat it as one part of the eligibility decision and account for shared devices, support cases and other independent evidence.

Test the workflow in your own application

Create a project, allow your development origin and complete the first token exchange before choosing an enforcement rule.

Create a free project