Prevent multiple free trial accounts without blocking teams

Prevent multiple free trial accounts by connecting a new entitlement request to the relevant account and grant history. Inspect device and network relationships alongside that history, then apply the product's actual eligibility rule. Shared infrastructure and multiple accounts are common in legitimate B2B use, so preserve those cases in evaluation.

The first implementation decision is the unit of entitlement. A trial per organization, per workspace and per person creates different rules for invitations, account changes and team evaluations. Recognition evidence is useful only when the team knows which rule it is supporting.

Map the account to the benefit it requests

Keep the authenticated account separate from the organization, workspace and trial grant. A new account may join an existing trial without receiving a new introductory benefit. Another request may create a separate workspace under a policy that permits a fresh evaluation.

Use a grant record that can explain the outcome. It should locate the eligible owner, the product scope, earlier grants and the current state. Do not let a browser flag silently become the record of whether a customer has used a trial.

Stytch's account-abuse article describes free subscription tiers, trials and credits as related account-abuse contexts. Its Fraud & Risk documentation distinguishes device information, verdicts and application enforcement. Those distinctions are useful when integrating an account relationship with a grant.

Use account links with their documented meaning

A relationship can connect visits, devices or application accounts. Ask how it was formed and what the returned confidence means. A support reviewer needs more than a statement that several accounts “match.”

Verisoul returns probabilistic account matches and related evidence. Castle's multi-accounting coverage addresses account relationships within its fraud workflow. Inspect the connection that the selected product actually supplies and how it attaches to your current event.

ShieldLabs includes ready-made multi-accounting alongside current device/network intelligence. Its High-Risk Events and their Medium or High confidence are separate from the numerical risk score. Preserve both forms of context without relabeling the score as a count of prior trials.

Protect legitimate colleagues and shared resources

Include shared office networks and permitted shared devices among the controls. Two users behind one address do not automatically share an identity. A family computer or a customer-success demonstration can also create a device relationship with a legitimate explanation.

The purpose of the table is to make the product's rules inspectable. It is not a recommendation that every business adopt the same entitlement policy.

Investigate the current request before expanding the cluster

Begin with one flagged activation. Locate its account, entitlement scope, trusted provider reference and the prior grant under review. Expand to related records only after confirming those associations.

Record timestamps and relationship types. Device observations separated by a long period can support a different conclusion from coordinated repeat grants within one promotion. A product's available history and retention window also matter to the investigation.

Preserve unknown outcomes. If the evidence does not establish that the requested entitlement is ineligible, retain the unresolved state. A device connection can still be useful without being proof of a policy violation.

Prevent duplicate grants during retries

A repeat request can come from a normal retry, not another participant. The application should distinguish replaying the same activation from requesting another entitlement. Keep the grant state and supported request references inspectable.

Follow the provider's documented backend delivery contract. Do not trust a client-submitted claim that a device is new or a result is low risk. The API integration guide covers collection, association, delivery and the provisioning boundary.

For AI products, connect the grant to the actual balance and consumption record. Even when the account is eligible, a duplicate credit grant can create a separate resource problem. The AI credit guide addresses this operating layer.

Give support a correction path

When a genuine customer is affected, support should be able to locate the relationship and entitlement used in the decision. Retain a reason for correction and a record of restored access. Avoid asking the customer to explain a hidden score with no supporting context.

Track incorrect denials separately from extra review and unresolved cases. Paid conversion is a useful business outcome, but it does not independently prove that every flagged participant was legitimate. The false-positive guide explains how to build the labeled control set.

Before purchasing, run an authorized repeat-entitlement case and a known genuine team case through the complete flow. Use the comparison to shortlist tools and the methodology to inspect how the editorial scores organize their different capabilities.

FAQ