Selling a live event sounds simple until you build it. A payment has to become a seat, the seat has to show up in the buyer's dashboard, and the meeting link should be useful at the right moment and not before. In VeloxonHub events are just another product type, so they go through the same cart and checkout as courses and memberships. The 30-second reel shows the flow. Here's what happens under the hood.
1. An event is a product with settings, not a separate system
The host creates an event in a 6-step drawer: details, type, schedule, registration, pricing and notifications. Under the hood it's a scheduling product with event settings (type, recurrence, capacity, replay) and one or more occurrences (start, end, time zone, meeting provider, join URL). If the host picks the built-in live room, the live session is created from the event's name and date, so there's no link to paste.
Prices are attached after the first save, through the same pricing model every other product uses. That keeps the Product List widget and the cart unaware of what an "event" is.
2. The widget and the cart don't special-case events
The Product List widget the host drops on a page reads the public products endpoint and renders events next to everything else, with their active prices, search, filters and an Add to Cart button. The cart and checkout work the same way for every product type.
3. Fulfilment happens on the paid order item
When an order is paid, an access service walks its items and grants access per product type. For a scheduling item, it creates the buyer's booking for that event. If the event needs approval (the waitlist option), the booking stays pending and the host is notified. The approval notice is sent after the payment is recorded, so a notification problem can never turn a successful payment into an error for the buyer.
4. Join is a time window, not just a link
The buyer's dashboard shows the booking in a calendar. The Join button only unlocks when two things are true:
- the booking is
confirmed,approvedorrescheduled, and - it's no more than 10 minutes before the start. For a recurring event, that means the next upcoming occurrence.
Before that, the card shows the date and time in the buyer's own time zone. Showing the link too early mostly produces people sitting alone in an empty room.
What we'd tell someone building the same thing
- Model events as products. Your cart, coupons, checkout and receipts then come for free.
- Fulfil per order item, after payment, and make side effects (emails, notifications) unable to fail the purchase.
- Treat "join" as a window with a status check, not a URL you hand out at checkout.
Try it with a free trial: https://veloxonhub.com. I'm happy to go into the booking or time-zone logic in the comments.
Top comments (3)
The 10 minute join window is a nice touch. One thing I'd watch on the free side: when the order total is zero, a seat costs nothing to grab, so a capped free event can fill up with bookings from throwaway or +tag addresses that never show. Counting one booking per event per normalised email (lowercased, +tag stripped) and only holding the seat once the buyer has confirmed their email keeps the capacity for real people. For paid events the payment already does that job. What happens to a free booking that's never confirmed, does the seat go back after a while?
Thanks! You're right that a free seat costs nothing to grab, so capacity needs protecting differently there. Here's how it works for free events:
One person, one account. You need a signed-in account to book, and it's one booking per account per occurrence. At signup, addresses are normalised: lowercased, +tag stripped and Gmail dots ignored. So jane+1@ and j.ane@ can't open separate accounts to take extra seats.
Confirmed email before booking. Creators can turn on "Require email verification" for their site. A new account then stays pending until the emailed link is clicked, and a pending account can't sign in, so it can't book.
On your question: with verification on, an unconfirmed booking can't happen, because a seat is only ever held by a confirmed account. If a creator leaves verification off, the booking is confirmed straight away and the seat stays taken until it's cancelled or the creator removes the attendee. Bookings don't expire on their own.
And agreed, for paid events the payment does that filtering.
That covers it well. Normalising at the account level is cleaner than doing it per booking. For creators who leave verification off, one option is a reminder a day before that asks people to confirm they're still coming and releases the seat if they don't, so a capped free event doesn't end up half empty on the day. Thanks for the detailed answer.