Anti-abuse

Bots stopped at the honeypot.
Suspicious humans flagged, not rejected.

Every registration form has a hidden honeypot input, per-IP rate limiting, and 6 more heuristic checks — disposable email domains, repeating mobile numbers, IP burst detection, gibberish names. Bots silently drop. Suspicious registrations get an admin flag so you can review, not a rejection that turns a real attendee into an angry email.

Book a demo See all features
Filter · Registrations
3 flagged today
out of 187 registrations
🚩 disposable_email · repeating_mobile
🚩 gibberish_name · ip_burst
🚩 duplicate_email_x3
Four layers

Cheap defences that catch 95% of the noise.

No hCaptcha friction, no Cloudflare interstitial. Real attendees never notice.

1
Hidden honeypot
A field called website is rendered in the form but positioned off-screen with tabindex="-1". Real users never see it. Bots that submit every input fill it. If filled, we silently drop the submission.
2
Per-IP + per-event rate limit
10 requests per minute per (IP + event) on registration and checkout endpoints. Attackers can't test 100 stolen cards / spam 500 fake attendees from one IP.
3
Heuristic scoring
After the record is saved, we analyse — disposable email domain, repeating mobile (9999999999), sequence mobile (1234567890), duplicate email on the same event, IP burst, gibberish name. Each signal recorded as a "reason".
4
Flag for admin, don't reject
Suspicious registrations get is_suspicious = true + a list of reasons. Admin filters "Suspicious" on the registrations page and reviews. Real attendees who tripped one heuristic never get an angry error message.
Signals we look for

The seven current heuristics.

More can be added. All fire independently — one signal is a hint, two signals is a probable bad actor.

🍯
honeypot_tripped
Hidden field filled — submission silently dropped, not saved at all. The bot thinks it worked; nothing hits the database.
📧
disposable_email
Known throwaway domain — mailinator, guerrillamail, tempmail, 16+ providers. Real attendees rarely use these.
📱
repeating_mobile
Number is 10 of the same digit — 9999999999, 0000000000. Never a real Indian mobile.
🔢
sequence_mobile
1234567890, 9876543210 — obvious placeholder patterns bots reach for.
🔁
duplicate_email_x3
Same email registered 3+ times for the same event — someone is retrying with variants, likely automated.
💥
ip_burst
Same IP submitted 5+ registrations to this event in the last hour. Even legit ISP shared IPs rarely do this on one event.
🎲
gibberish_name
Name is five or more repeats of the same character — "aaaaaa", "xxxxxx". Bots that don't bother with a plausible name.
Why we built it this way

Because false positives are worse than false negatives.

The obvious answer to "we're getting spam" is to bolt on hCaptcha, Cloudflare Turnstile, or a "please prove you're human" popup. And it works — spam drops. But a percentage of real attendees fail the challenge, close the tab, and never register. On a free meetup that percentage might be 2%. On a paid ₹10,000 conference, that's real revenue walking out.

Then there's the CAPTCHA fatigue tax: every extra step in the form kills conversion. Baymard's checkout research is unambiguous — every field, every popup, every "extra step" bleeds paying customers.

So we went the other direction. Invisible defences — honeypot, rate limit, heuristic scoring — that real attendees never see. When we're 99% sure something is a bot (honeypot tripped, rate limit exceeded), we silently drop it. When we're uncertain (disposable email, one gibberish signal), we save the registration and flag it for admin. The organiser opens the registrations list, filters "Suspicious", reviews the 3 flagged rows, deletes the fakes, welcomes the real attendees.

Nothing turns a real attendee into an angry email faster than "your registration was rejected: suspicious activity." So we don't reject. We flag. Admin decides.

Pairs with

Where the fraud signal shows up.

👥
Admin Dashboard
Registrations list gets a "Suspicious" filter. One click shows only flagged rows for review.
📜
Audit Log
When admin deletes a flagged registration, the audit log records who did it. Everything traceable.
💳
White-Label Ticketing
Paid checkout has the same honeypot and rate limiting. Bot testing stolen cards gets rate-limited to 10/min per IP.

Questions we get

Does this add friction for real users?
Zero. No CAPTCHA, no puzzle, no popup. Everything runs server-side after the form is submitted, or invisibly in a hidden input.
Will it block real attendees using Yahoo or Gmail?
No. Only 16 known temp-mail providers trigger the disposable_email flag — mailinator, guerrillamail, and similar. Gmail, Yahoo, Outlook, ProtonMail all fine.
What happens when the honeypot trips?
The submission silently returns a 302 to the confirmation-shaped URL. The bot thinks it worked and stops retrying. No record is created, no email sent, nothing.
Can I add hCaptcha on top for paid events?
Yes — it's on the roadmap as an optional per-event toggle. High-value events with a history of card testing may want the extra layer.
What's the rate limit exactly?
10 POSTs per minute per (IP + event) on registration and checkout endpoints. Configurable per tenant if you need it tighter or looser.
Bots stopped. Real attendees not annoyed.
See the honeypot + fraud scoring flow in 10 minutes.
Book a demo See other features