Phone verification
Require an SMS-verified phone at checkout — accepted prefixes, the rate limits that stop abuse, and how it powers per-customer purchase limits.
Phone verification asks buyers to prove a working phone number by SMS before they can order. It does two jobs: it filters out bots and throwaway identities at the door of checkout, and it provides the stable identity that makes max per customer limits actually bite.
Turning it on
Under Event settings → Anti-scalping, enable Require a verified phone number — "Buyers verify a phone by SMS before they can order." It can also be triggered selectively as the Require phone verification step in the risk ladder, so only suspicious orders face the challenge while everyone else breezes through.
Accepted phone prefixes
Accepted phone prefixes limits which dialing codes can be verified
— "Only numbers with these dialing codes can be verified." Add codes
like +420, +421. The event setting overrides your
organization default; leaving it empty inherits that
default. (An empty list at both levels refuses all verification —
configure prefixes before you require verification.)
This is a quietly powerful anti-scalping lever: a Czech ball that only
accepts +420/+421 is instantly harder for an overseas bulk-buyer to
automate.
The buyer's flow
Enter the number
The buyer types their phone at checkout; Bookitive normalizes it and checks it against your prefixes.
Receive and enter the code
An SMS code arrives. Entering it mints a single-use verification token that unlocks the order submission.
The checkout shows precise, non-leaky errors for each failure — bad number, wrong code, expired code, too many attempts, blocked — so genuine buyers recover and abusers learn nothing.
The limits that stop abuse
Verification is rate-limited so it can't itself be weaponized:
- a 30-second cooldown between sends,
- 5 sends per phone per hour, 8 per day,
- 10 sends per IP per hour,
- the verified token is valid for 30 minutes.
Why it matters for limits
A ticket type's max per customer cap counts tickets across all of a buyer's orders — but a verified phone is the most stable identity to count against. When the event doesn't require one, the cap still enforces by email, which a determined buyer can slip with throwaway addresses — splitting a 20-ticket grab into ten 2-ticket orders the per-order limit never notices. A verified phone closes that gap: the twentieth ticket is refused. It's the firmest foundation the per-customer limit stands on.
Related
Allow and deny lists
Manual overrides on checkout — trust a buyer past every risk action, or refuse one outright, keyed on email, domain, phone, IP, or device.
Attendee names
Require one name per ticket — printed on tickets and shown at check-in — plus the backfill action for tickets sold before you turned it on.