🌟 Event Checkout Validation Webhook (Synchronous / Blocking)

[Sipioteo]

🔒 Blocking Webhook on Event Checkout (Pre-Payment Gate)

Problem / Motivation

For some events, ticket purchases must be conditionally allowed based on external rules (e.g. email whitelist, membership checks, invitation lists, corporate domains, age verification, fraud scoring, etc.).

iEvents currently does not provide a blocking (synchronous) webhook during checkout that can approve/deny a purchase before payment is initiated.

We need an Event-level “pre-payment gate” webhook that is called right after the user completes the checkout form and clicks “Continue/Pay”, but before creating/confirming the payment intent / redirecting to payment.

---

Goals

1. Add an event-level webhook that is blocking/synchronous in the checkout flow.
2. The webhook can approve (allow payment) or deny (block payment) with a controlled user-facing message.
3. Provide a secure, low-latency, reliable integration mechanism with strict timeouts and clear failure behavior.

---

Key Use Cases

1) Email whitelist / invite-only events

Only users whose email is whitelisted in an external system can proceed to payment.

2) Membership / entitlement checks

Allow purchase only if the user is an active member in a third-party system (e.g. association membership, employee directory, course enrollment).

3) Fraud / risk scoring

Call an anti-fraud endpoint to decide whether to allow payment.

---

Proposed Feature

A) New Webhook Type (Event-level)

Webhook event name: checkout.validate (or checkout.pre_payment, payment.authorize)

Trigger timing (critical):

• User fills checkout form (name/email/fields required)
• User clicks “Continue” / “Pay”
• Before payment is started (before payment intent confirmation / before redirect)

---

B) Expected Behavior

• Hi.Events sends an HTTP request to the configured webhook endpoint.
• If webhook returns HTTP 200, checkout proceeds to payment.
• If webhook returns HTTP 4xx, checkout is blocked and a user-facing error message is shown (message optionally provided by webhook).
• If webhook returns HTTP 5xx or times out, default behavior should be configurable, but the safe default is block purchase with a generic message.