Checkout
The buyer's checkout — details, promo code, attendee names, phone verification, captcha, consent, and the confirmation, under-review, or payment-instructions outcomes.
The checkout is where a cart becomes an order. It runs on Bookitive's own origin (even when the event page is embedded on your site), so payments, captcha, and verification happen safely no matter where the buyer started.
The steps
A buyer moves through, as applicable to your event's settings:
- Their details — name and email (and phone where required).
- Promo code — the discount field, which previews its effect on the total before ordering.
- Attendee names — one name per ticket, when the event requires them.
- Phone verification — an SMS code step when the event requires a verified phone (or when risk rules challenge this order).
- Bot protection — an invisible-where-possible captcha.
- Consent and legal — your terms and privacy links, and the optional marketing opt-in checkbox if you've enabled it.
The outcomes
Submitting lands on one of three screens, matching the order's first status:
- Confirmation — for pay-now orders: "you're in", tickets on the way.
- Payment instructions — for bank-transfer reservations: your bank account, the amount, the variable symbol, and the deadline. The scannable QR payment code arrives in the email and PDF, not on this screen. This is the reservation flow.
- Under review — for orders your protection rules held: a neutral "we're reviewing your order", no payment details yet.
When things go sideways
- A seat was taken mid-checkout — the buyer gets a clear conflict message and returns to re-pick, never a cryptic error.
- Verification problems — wrong code, expired code, too many attempts — each has its own precise, non-leaky message so genuine buyers recover.
The whole step runs in a Bookitive-hosted frame, which is why a developer embedding a fully custom checkout still gets Turnstile and phone verification handled for them — the host site never configures captcha. See Embedding the widget.