Student Discount Abuse Prevention: Beyond the .edu Check

Education pricing is one of the most generous offers a software company makes: a deep discount or a free plan for anyone who can prove they are a student. The usual proof is an email address on an academic domain. That check is easy to build and easy to beat, and once a discount is known to be beatable it tends to get shared in forums and resale channels.

This post covers how education plans get abused in practice, and how to add a second layer based on the device and network without making every real student upload a card scan.

How education plans get farmed

The patterns are less exotic than you might expect.

Bought or borrowed academic addresses. Some institutions issue addresses to alumni for life, to short-course participants, or to anyone who enrolls in a free online program. Those addresses circulate. A single person can hold several, and some are sold outright.

Forwarding and shared inboxes. One student verifies, then forwards the verification link or code. The account ends up used by someone with no link to the school.

Repeat sign-ups after expiry. Education plans usually expire after a year or require re-verification. The cheapest renewal is a new account with another address.

Paid-to-education downgrades. A paying customer cancels, then signs up again on the student plan from the same laptop. This is the one that hurts revenue most directly, because you lose a real subscription.

Resale. Someone verifies dozens of accounts and sells access. Here the device and network evidence is usually loudest, because one operator is doing all the work.

What the email check can and can’t tell you

Keep the domain check. It is a cheap, honest filter that stops casual abuse. But be clear about what it answers: “can this person receive mail at an academic domain?” It does not answer “is this one person?” or “have they done this before?” Those are the questions the abuse patterns above exploit.

Disposable-email lists don’t help here either, because academic addresses are real mailboxes. The checks in disposable email detection at sign-up remain useful for your general sign-up flow, just not for this one.

The second layer: the device

A stable device identifier answers the questions the email can’t. Prynt’s visitorId stays the same across cleared cookies and incognito windows, and every account you link to it shows up in accountsOnDevice on the next identification. At the moment someone claims an education plan, you can ask:

• How many accounts has this device already held? One student account and nothing else is the normal case.
• Was one of them paid? If the device’s earlier account is a cancelled paid subscription, the student claim is a downgrade, not a new student.
• How many education claims has this device made? More than one in a year is rarely legitimate.

import { PryntServer } from '@prynt/node';
const prynt = new PryntServer({ secretKey: process.env.PRYNT_SECRET_KEY });

async function reviewEducationClaim(userId, requestId) {
  const ev = await prynt.getEvent(requestId);
  const others = ev.accountsOnDevice.accounts
    .map((a) => a.linkedId)
    .filter((id) => id !== userId);

  const history = await db.accounts.findMany({ where: { id: { in: others } } });
  const priorEdu = history.filter((a) => a.plan === 'education').length;
  const priorPaid = history.some((a) => a.everPaid);

  if (ev.decision === 'block') return 'deny';
  if (priorEdu >= 1 || priorPaid) return 'verify';
  return 'approve';
}

The accounts array contains your own linkedId values with firstSeenAt and lastSeenAt, so you can join it against your billing data. That join is the part no outside service can do for you, and it is where the useful verdicts come from. Make sure each new account is linked with updateEvent(requestId, { linkedId }) after it is created, or the next claim has nothing to compare against. Note that accounts is capped and truncated tells you when a device has more than are listed, which is itself a strong signal.

The network layer

Network signals add context, but treat them carefully on education plans. Students sit behind campus NAT, VPNs required by their school, mobile carriers and shared housing networks. A campus IP with fifty student sign-ups is a university, not a fraud ring.

Signals that do carry weight here:

• Datacenter and residential proxy origins on a claim (DATACENTER, RESIDENTIAL_PROXY). Real students rarely verify from a cloud server.
• Velocity on one device (VELOCITY): several claims in an hour is a reseller.
• Automation (BOT, TLS_AUTOMATION): scripted verification flows are never a student.
• Country mismatch, when the school’s country and the device’s IP location differ every time, combined with other evidence. On its own it describes every exchange student.

A plain VPN result is weak evidence. Many universities require one for library access.

Respond in proportion

The goal is to protect the discount without turning education pricing into a paperwork exercise.

1. Approve silently for a device with no prior accounts and no strong signals. That is most students.
2. Verify for a device with a prior education claim or a prior paid account: ask for re-verification through your school SSO integration or a document check, or simply offer the regular trial instead.
3. Deny only for automation or a device clearly running a resale operation.

Keep the message neutral. “We couldn’t confirm eligibility for the education plan from this device; you can still start a standard trial” is honest and gives a real student somewhere to go. Never tell the user which signal fired.

Re-verification is a gift

Education plans expire, which gives you a natural checkpoint. At renewal, identify again and compare. If the device behind the account has since accumulated three more education accounts, you have learned something. If it is the same single-account device a year later, approve without friction.

The same approach covers other gated discounts, such as nonprofit, military or regional pricing. The underlying pattern is the one described in promo abuse prevention and multi-accounting detection: the offer is per person, the check is per email, and the gap between them is the device.

If you want to see the identification and reason codes for your own browser before you wire anything, open the playground. The free plan is enough to run the check on every education claim while you decide on thresholds.