DEV Community: Hira

The billing job that ran green every night and billed nothing

Hira — Thu, 06 Aug 2026 10:54:49 +0000

We published a per-lookup overage rate on every paid plan from launch. None of it was ever charged to anyone.

The reporter existed. It ran nightly at 03:20, it selected the previous day's billable events, it sent them to the payment provider, and it exited zero. Every night. For weeks.

The 60-minute window

The provider rejects any usage event whose timestamp is more than an hour old:

events[0].timestamp: Timestamp cannot be older than 1 hour

A batch sent at 03:20 for the previous day had every single event refused. The job was not broken in any way a green checkmark could show you. It ran, it reported nothing, and it billed nothing.

The fix was the schedule, not the code: every 15 minutes instead of nightly.

The 200 that means nothing

The second one was worse. Reporting usage against a subscription whose product carries no meter returns 200. The events are accepted. The rows get marked reported. Nothing reaches the invoice.

That is indistinguishable from success at every layer you would normally check. We only found it by reading the meter's own count back, rather than trusting the response.

// reporting a 200 is not proof. the meter's count is.
const before = await meterTotal();
await report(events);
const after = await meterTotal();

The boundary nobody had tested

Overage is charged on the excess, not the allowance. At 20,001 lookups on a plan including 20,000, the customer owes for one lookup.

We had a function doing that arithmetic and no test executing it. The existing tests read the source as text and asserted on strings, which can prove a line exists but not that it returns the right number.

ok("20,001 charges for ONE lookup, not 20,001",
   projectedSpend(starter, 20_001), 49 + 0.004);

We injected the bug before trusting the test — replaced the excess with the full count, and it failed with expected 49, got 129. An $80 error, stated as money.

What I would take from it

A cron that exits zero is not a cron that worked
Read the state back from the system you are integrating with, not the response it handed you
Test the boundary where the arithmetic changes, and prove the test fails before you rely on it

None of these are clever. All three shipped anyway.

How to handle AI agents signing up to your product

Hira — Wed, 05 Aug 2026 11:39:59 +0000

Start from the uncomfortable part. Every fraud signal the industry has built is a proxy for "is a human here", and a capable AI agent genuinely has the things those proxies measure. It drives a real browser, so the fingerprint is real. It arrives on a residential connection, so the address is clean. It controls a real mailbox, so it receives the verification code. It is not defeating your checks; it is satisfying them. So detection is an arms race you lose slowly, and the useful question is a different one.

Stop asking whether it is a bot

"Is this automated" has become a bad question, because a growing share of legitimate traffic is somebody's assistant doing what they explicitly asked it to do. Refusing that refuses a customer who is standing right there. The question that still has an answer is: on whose authority is this acting, and can they be held to it?

Verify the agents that identify themselves

Web Bot Auth is the emerging standard for this — RFC 9421 HTTP Message Signatures, with an IETF working group chartered in early 2026 and Cloudflare, Google, Amazon and OpenAI behind it. The agent signs its request with a key its operator publishes at a well-known URL, and you check the signature. This is the one check in fraud detection with no false-positive rate, because it is arithmetic rather than judgement. Increasingly agents do sign, because operators want their traffic accepted.

curl -X POST "https://www.layercall.com/v1/agent/authorize" \
  -H "X-Api-Key: YOUR_KEY" -H "Content-Type: application/json" \
  -d '{
    "method": "POST",
    "url": "https://yoursite.com/signup",
    "headers": { "signature": "…", "signature-input": "…", "signature-agent": "…" }
  }'

Use trigger, not user agent, to tell them apart

An operator's Signature Agent Card declares a trigger with exactly two values: fetcher, meaning a person initiated this request, and crawler, meaning nobody did. That distinction is invisible to every classical signal — both are "a bot", and both may be perfectly signed — and it is the whole game. A customer's assistant filling in a signup because they asked it to is a customer. An autonomous crawler POSTing to the same endpoint on nobody's behalf is not, and never was.

const r = await score({ ip, email, device_id, agent: { method, url, headers } });

// proven is true for exactly one thing: a signature that verified.
if (r.actor.proven && r.actor.type === "verified_agent") {
  if (r.actor.trigger === "fetcher") return allow();   // a person asked for this
  if (req.method !== "GET")          return reject();  // nobody asked for this
}

Separate what you can prove from what you inferred

A verified signature is proof. Headless detection and automation markers are inference, and inference a capable adversary patches in an afternoon. Keep those apart in your own code, because the moment they are the same field you will start treating a guess like a certainty — and acting automatically on a guess is how you refuse real customers. Branch on a single boolean that means "this was settled cryptographically", not on a vocabulary.

Catch volume with linkage, not with identity

Signing does not make an agent harmless. Someone can tell their assistant to open fifty trial accounts and it will honestly declare itself user-initiated every single time, because it is telling the truth. The card cannot see that and does not claim to. What gives it away is the shape: one device across twelve addresses, fifty signups from one /24 inside an hour. Score the pattern, not just the request.

What a naive version of this gets wrong

Blocking all automation. That reflex gets more expensive every month as more real customers delegate to assistants, and it is invisible in your metrics — refused signups do not file complaints.
Treating an unsigned request as malicious. Most traffic is unsigned and most of it is fine. Absence of a signature says nothing; it is a missing claim, not a false one.
Trusting a user agent string. It is self-asserted plain text with no verification of any kind, which is precisely why the signature standard exists.
Believing a vendor who claims to detect any AI agent. A capable agent driving a real browser on a residential connection is indistinguishable from a person by construction — anyone selling certainty there is selling you an arms race.
Assuming a verified fetcher is safe. It means a person asked for this request, not that the person is honest. Pair it with velocity.

Originally published at www.layercall.com/guides/handle-ai-agent-signups.

How to add fraud checks without losing real customers

Hira — Tue, 04 Aug 2026 12:44:47 +0000

Every fraud check has two error rates, and only one of them is visible. You will notice the fraudsters who get through, because they cost you money in ways that show up on a dashboard. You will never notice the real customers you turned away, because they simply leave. That asymmetry is why fraud systems drift toward being too strict over time.

Never let a check fail closed

If your fraud provider is slow, down, or you have hit a quota, the signup must still work. A fraud check that takes signups offline during an outage has cost you more than the fraud it was bought to stop — and unlike fraud, it hits every legitimate user at once rather than a few bad ones.

let trust = { verdict: "allow", scored: false };
try {
  trust = await lc.scoreUser({ ip, email });
} catch (err) {
  log.warn("fraud check unavailable", err);  // proceed anyway
}

Use the middle option

Allow and block is a false choice, and it forces every uncertain case into one of two wrong answers. A third path — verify — resolves almost everything: a one-time code costs a real person a few seconds and costs an automated attack the whole run.

Log what you rejected, then read it

Store the score and the reasons for every signup you challenged or refused, then actually look through them weekly. This is the only way false positives become visible. If you find a category of real customer in there — a country, an email provider, a VPN — that is a rule to loosen, not a coincidence.

Start in observe-only mode

Run the checks and record the verdicts without acting on them for a week or two. You will see what proportion of your normal, healthy traffic would have been challenged before you inconvenience anybody. If that number surprises you, better to learn it from a log than from your support inbox.

What a naive version of this gets wrong

Turning the strictness up after an incident and never turning it back down. Ratchets only go one way, and nobody is measuring the cost.
Never distinguishing "low risk" from "we could not check". They are completely different, and collapsing them means an outage looks like a clean bill of health.
Judging accuracy by fraud caught alone. A system that blocks everyone catches all fraud. The number that matters is how many real customers it cost.
Trusting a vendor who never publishes their mistakes. Every one of these systems has false positives, including ours — a provider who will not talk about theirs has not stopped having them.

Originally published at www.layercall.com/guides/score-signup-without-blocking-real-users.

How to stop free trial abuse

Hira — Tue, 04 Aug 2026 12:39:36 +0000

Trial abuse is not usually a thousand people taking one trial each. It is a handful of people taking a thousand trials, which means the whole problem is linkage: recognising that the twelfth signup is the same person as the first. That is a different job from scoring a single signup in isolation.

Find what the accounts share

An abuser varies whatever is cheap and reuses whatever is expensive. Email addresses are free, so those change every time. Device fingerprints, IP ranges and phone numbers cost money or effort, so those repeat. Look for repetition in the expensive things.

Catch email aliasing before you catch anything else

Gmail ignores dots and anything after a plus sign, so user+1@gmail.com through user+400@gmail.com are all one mailbox. Normalising the address collapses a hundred trials into one visible account, and it costs nothing to implement.

curl "https://www.layercall.com/v1/verify/email?email=user%2Btrial7@gmail.com" \
  -H "X-Api-Key: YOUR_KEY"
# normalized_email collapses the alias back to the real mailbox

Add a device signal

A browser fingerprint survives a new email address and a fresh incognito window, which is exactly what a repeat trialist changes between attempts. It is not perfect and it should not be your only check, but it links accounts that otherwise look unrelated.

Raise friction in proportion, not uniformly

Requiring a card from everyone stops abuse and also stops your growth. Requiring a phone number or a card only from signups that already look linked keeps the front door open for the majority who are exactly who they say they are.

const trust = await lc.scoreUser({ ip, email, device_id });

if (trust.verdict === "block")  return requireCard();
if (trust.verdict === "review") return requirePhoneVerification();
return startTrial();

What a naive version of this gets wrong

Requiring a card from every trial. It works, and it will cost you more in lost signups than the abuse ever cost you in compute.
Blocking a whole IP range after one abuser. Shared addresses mean you will hit an office, a campus or a mobile carrier and never hear from the people you locked out.
Assuming a repeat device is always one person. Shared computers, family machines and library terminals are real.
Treating the second signup as abuse. People genuinely lose access to old email accounts and start again. Linkage is a reason to verify, not to accuse.

Originally published at www.layercall.com/guides/stop-free-trial-abuse.

How to detect VPN and proxy users at signup

Hira — Tue, 04 Aug 2026 12:34:25 +0000

VPN detection is genuinely hard, and most implementations quietly fail. The common approach — check whether the IP belongs to a hosting provider's ASN — misses the majority of consumer VPN traffic, because the large consumer VPNs rent capacity from ordinary hosting companies rather than running their own networks.

Know why the obvious method fails

ASN lookups tell you an address belongs to a hosting company. That catches servers, and it catches VPN operators who own their own network. It misses NordVPN, Surfshark, PIA and CyberGhost exits sitting on shared hosts, because the ASN belongs to the host, not the VPN. We measured this: fifteen real NordVPN exits, and three of them looked completely clean to an ASN-only check.

Ask the operators instead

Several major VPN providers publish their live server lists — the same endpoints their own apps call to pick a server. NordVPN publishes roughly 9,000 exit addresses; Mullvad publishes its relays. Reading those is exact rather than inferred, and it is public data, so there is no licence question. Providers who publish nothing still need the inferential approach.

Separate the categories in your response

"Datacenter", "commercial VPN", "public proxy" and "Tor exit" are four different facts with four different meanings. A Tor exit on a banking signup is a strong signal. A commercial VPN on a consumer app is Tuesday.

curl "https://www.layercall.com/v1/score/ip?ip=1.2.3.4" \
  -H "X-Api-Key: YOUR_KEY"

Fix your geolocation while you are here

A geolocation database maps a VPN range to where the operator registered it, not where the exit physically is. That is how a user connecting through Amsterdam gets reported as Switzerland. If you make decisions on country, a VPN silently corrupts them — so prefer the operator's declared location when the exit is known.

What a naive version of this gets wrong

Blocking VPN users outright. This is the single most costly overreaction in fraud prevention. Privacy-conscious users, remote employees on corporate VPNs, travellers and entire regions route this way, and they are disproportionately the technical customers who pay.
Trusting an ASN label without verifying who holds it. We had one ASN labelled as a VPN provider that actually belonged to Wake Forest University — every student looked like a VPN user.
Reading a VPN's registered country as the user's location. It is frequently a different continent.
Counting datacenter plus VPN plus proxy as three separate penalties. They are usually one fact about one connection; adding them up manufactures risk that is not there.

Originally published at www.layercall.com/guides/detect-vpn-at-signup.

How to block disposable email addresses at signup

Hira — Tue, 04 Aug 2026 12:28:32 +0000

Disposable-address detection is the highest-return check on a signup form, and also the one most often implemented badly. The naive version — a hardcoded list of a dozen domains — stops nothing, because throwaway providers add domains faster than you will update your array.

Understand what you are actually detecting

Throwaway providers operate thousands of rotating domains, not one. Public blocklists currently track around 8,000 of them, and the distribution is not what people expect: about a third sit on .com, which means blocking unusual TLDs is not a substitute for a real list. Our Trust Index publishes the current breakdown.

Do not write the regex

Every team tries /mailinator|guerrilla|10minute/ first. It fails on day one, because these providers publish hundreds of unrelated-looking domains specifically so that pattern matching does not work. A maintained list is the only approach that keeps working, and it needs updating continuously rather than once.

Check the address, get the reason

You want more than a boolean. Whether the domain accepts mail at all, whether the mailbox exists, and whether the handle looks machine-generated are separate facts, and they justify different responses.

curl "https://www.layercall.com/v1/verify/email?email=someone@example.com" \
  -H "X-Api-Key: YOUR_KEY"

Decide what a hit actually means for your product

For a paid product with no free tier, a throwaway address is close to meaningless — nobody pays with a card and then reads their receipts in a temporary inbox. For a free trial, it is the single strongest abuse signal you have. The right response depends on what abuse costs you, which is a decision only you can make.

What a naive version of this gets wrong

Blocking free providers along with disposable ones. Gmail, Outlook and iCloud are where most of your real customers are. These are completely different categories and conflating them is the most expensive mistake on this page.
Treating a role address as fake. admin@ or billing@ at a company domain is a real person doing their job — often the person who approves the invoice.
Assuming a role handle on a consumer mailbox is a role account. hello@gmail.com is somebody's personal address, not a shared inbox. We flagged those for weeks before catching it.
Blocking rather than challenging on a single signal. A disposable address plus nothing else is thin evidence; ask for a code.

Originally published at www.layercall.com/guides/block-disposable-emails.

How to stop fake signups

Hira — Tue, 04 Aug 2026 12:27:33 +0000

If fake accounts appeared overnight, you are almost certainly being hit by one script rather than many people. That is good news: scripted signups reuse infrastructure, and infrastructure is measurable. Here is the order to check things in, cheapest first.

Check the email domain before you check anything else

Disposable-address providers are the cheapest thing an attacker uses and the cheapest thing for you to detect. There are roughly 8,000 known throwaway domains, and a scripted signup run will lean on a handful of them. This single check typically removes most of the volume, and it never touches a real customer — nobody signs up for a product they intend to pay for using a ten-minute mailbox.

curl "https://www.layercall.com/v1/verify/email?email=test@mailinator.com" \
  -H "X-Api-Key: YOUR_KEY"

Then look at where the request came from

A datacenter IP address means the request did not come from a phone or a home broadband connection — it came from a rented server. Real customers occasionally arrive via VPNs, so treat this as a signal rather than a verdict. But a burst of signups from one hosting provider inside an hour is not a coincidence.

curl "https://www.layercall.com/v1/score/ip?ip=1.2.3.4" \
  -H "X-Api-Key: YOUR_KEY"

Check how old the email's domain is

Attackers who move past disposable providers register their own domains, and they use them immediately. A domain registered three days ago that is already signing up for your product is worth a second look. Be careful here: real founders launch on week-old domains too, which is why this should raise a challenge rather than a block.

Score the whole signup, not each field separately

The signals matter together. A disposable email is worth a challenge. A disposable email from a datacenter IP on a domain registered yesterday is not ambiguous. One call scores every field and returns a single verdict, so you write one branch instead of five.

const trust = await fetch("https://www.layercall.com/v1/score/user", {
  method: "POST",
  headers: { "X-Api-Key": process.env.LAYERCALL_API_KEY, "Content-Type": "application/json" },
  body: JSON.stringify({ ip, email, phone }),
}).then(r => r.json());

if (trust.verdict === "block")  return reject();
if (trust.verdict === "review") return sendOneTimeCode();
return createAccount();

Send a code — do not slam the door

This is the part most teams get wrong under pressure. Blocking outright turns every false positive into a lost customer who never tells you why they left. A one-time code costs a real person eight seconds and costs a script the entire attack, because the script has no mailbox to receive it. Reserve outright rejection for the cases where several strong signals agree.

What a naive version of this gets wrong

Blocking every VPN user. Plenty of privacy-conscious people, remote workers on corporate VPNs, and entire countries browse this way. VPN use is a reason to verify, not to refuse.
Treating an unmeasured signal as a negative. If a domain's registration date could not be determined, that is unknown — not "old and therefore fine". We shipped this bug ourselves and wrote it up.
Blocking shared IP addresses. University networks, mobile carriers and offices put thousands of unrelated people behind one address. Punishing that address punishes all of them.
Scoring the wrong device. If you fingerprint the browser, make sure you are reading the end user's user agent and not your own server's HTTP client — we made exactly this mistake and every request looked identical.

Originally published at www.layercall.com/guides/stop-fake-signups.