Passes and events are how Deskie sells access that isn't a full membership: a day pass, a punch card, a ticket to a workshop. This article traces what happens from the moment someone buys one, through how the charge is collected, to how (if you have Kisi connected) the right doors open at the right time. For the building blocks themselves, see passes and events. The mechanics here are deliberately close to how reservations work, covered in bookings, billing, and access.
What a pass and an event actually are
A pass type is a reusable product you define once: a name, a number of uses, a member price, a non-member price, an optional expiration in days, and toggles for who may buy it. Each individual purchase becomes its own record that tracks how many uses remain, when it expires, its payment status, and its approval status.
An event is a single dated occurrence with a start and end time, optional ticket caps (overall, and separate member and non-member buckets), a member price, and a non-member price. Each purchase becomes a ticket that records a quantity, the price paid, and a status.
Both can be sold two ways: from inside Deskie (a member buying from their dashboard, or an admin recording a sale on someone's behalf) and from your public website (a visitor with no account, or a signed-in member checking out publicly). Both can also enable door access and point at specific Kisi locks, which is what makes a pass or ticket open something.
Who is allowed to buy
Every pass type carries two independent switches: allow member purchase and allow non-member purchase. An event carries the same pair. These gate both visibility and the actual purchase, and they are enforced on the server, not just hidden in the interface.
- On the public website, a pass or event only appears if non-member purchase is allowed, with one exception: a signed-in member of the workspace also sees passes and events that allow member purchase, even when they are not open to the general public.
- Inside Deskie, a member can only be sold a pass or event whose member purchase is allowed. If that toggle is off, the purchase is refused.
- Events have two extra visibility controls, hide from member listing and hide from public listing, so you can keep an event purchasable by direct link while leaving it off the relevant list.
How the price is decided
Price is always resolved on the server and never trusted from the browser. The rule is the same for passes and events:
- A member who is allowed to buy at the member rate, and for whom a member price is set, is charged the member price.
- Everyone else, including guests and anonymous public buyers, is charged the non-member price.
On the public website this member-aware pricing is applied carefully. When a signed-in member views a pass or event, the price the purchase screen shows is the effective price they will actually be charged, so the quote and the charge stay in lock-step. A paused member is treated as a standard buyer for display and is blocked from checking out entirely, with a message to contact the venue. For events, the ticket count shown to a member reflects the member ticket bucket, and to a guest the non-member bucket, so the quantity selector matches what the purchase will accept.
For events, the per-ticket price is multiplied by the quantity to get the total. A coupon, if supplied, is validated against that specific pass or event and applied to bring the total down before anything is charged.
Ticket availability checks for events
Before an event ticket is committed, Deskie protects the caps in two layers:
- Overall cap. If the event has a total ticket limit, the requested quantity is checked against the sum of all confirmed tickets already sold. If it would exceed the total, the purchase is refused with the number remaining.
- Bucket cap. If the buyer is a guest and a non-member ticket cap is set, their quantity is checked against confirmed non-member tickets only. If the buyer is a member and a member ticket cap is set, their quantity is checked against confirmed member tickets only.
Allocation is by role, not by the price paid: a real member always consumes the member bucket and a guest always consumes the non-member bucket. Deskie also refuses tickets for an event that has already ended or been cancelled.
How the charge is collected
The payment status recorded on the purchase or ticket tells you how the money was handled. There are three main outcomes.
Public checkout: pay now, invoice and receipt after
On the public website, every paid pass or ticket charges a card through your connected Stripe account. The sequence is:
- Deskie resolves the buyer. A signed-in member buys against their existing profile. An anonymous visitor gets a guest member profile created automatically, anchored to the pass's or event's location, with a temporary password so they can log in later. A new guest is also captured as a lead in your CRM pipeline.
- The purchase record is written first. For a pass this captures the number of uses and the expiration date (calculated from the pass's expiration-in-days setting). For an event it captures the quantity.
- Workspace surcharges are applied on top of the subtotal. If you have tax or a card fee enabled, those amounts are computed and frozen into the payment so the receipt matches exactly what was charged. Public purchases are always card-paid, so the card fee applies when it is turned on.
- A Stripe payment intent is created and confirmed for the surcharge-inclusive total. If it does not succeed, the purchase record is removed and the buyer sees the failure.
- On success, Deskie creates a paid invoice and a matching payment record, then links both back to the purchase. The invoice stores the pass or ticket subtotal, with the tax and card-fee amounts captured alongside it; the payment record holds the surcharge-inclusive total to match Stripe.
- A confirmation receipt email goes to the buyer (event tickets email every named attendee, not just the purchaser), and owner notification emails, SMS, and push alerts go to your admins.
Free public passes and tickets ($0) skip Stripe entirely but still produce a paid $0 invoice and a confirmation email.
Inside Deskie: pay now or add to invoice
When a member buys from their dashboard, or an admin records a sale, there are two ways to settle:
- Pay immediately. Deskie creates an invoice for the purchase and processes payment now, the same way the public flow does. The purchase is recorded as paid immediately and linked to that invoice. A purchase made for a member who is paused is blocked on this path.
- Add to invoice. A member can add the charge to their billing instead of paying on the spot. This member-only path records the purchase and lets the charge roll up on the next billing run. It is refused for a guest: guests have no ongoing billing relationship, so Deskie blocks any attempt to add their purchase to an invoice, even if the request is manipulated.
Whoever pays is resolved up front. If the buyer belongs to a team that pays by default, the event ticket or pass and its invoice are tagged to that team so billing has a single source of truth. Public self-serve checkout always bills the purchasing member's own card directly and never routes to a team.
Member event tickets respect the same availability checks as the public flow. A free ($0) pass or ticket is recorded as paid immediately and still produces a paid $0 invoice for the records.
Approval, if you require it
A pass type can require approval. When it does, a purchase is created with an approval status of awaiting approval rather than approved. Admins see these in the pass purchase list and can approve or reject them, and an approval can later be revoked back to awaiting approval. An approval or rejection email goes to the buyer. A pass that is awaiting approval (or rejected) cannot be used: both checking in and scheduling a use are blocked until it is approved, so no usage that would open doors can be created. Events do not have an approval step; a confirmed ticket is usable immediately.
How a pass gets used
A pass purchase starts with its full number of uses. A use is consumed when the holder checks in. Each check-in writes a usage record dated to today (in your workspace timezone) and decrements the remaining uses by one, inside a transaction so two simultaneous check-ins can't double-spend. Deskie refuses a check-in if the pass has no uses left, is expired, is awaiting approval or rejected, or has already been checked in today.
A holder can also schedule a use for a future date. Scheduling reserves the date, writes a scheduled usage record, and decrements remaining uses immediately, with the same guards. A scheduled use can be cancelled, which returns the credit to the pass. Single-use passes can be set to require a date at purchase, in which case the purchase itself carries the scheduled date.
How passes and events grant door access
If you have Kisi connected and door access is enabled on the pass type or event, the purchase opens the configured Kisi locks only during the window it covers. This is automatic; there is no manual granting or revoking. Both passes and events store a door-access setting and a list of Kisi lock IDs, exactly like resources do for bookings.
When a guest views their doors, Deskie assembles their currently active access and merges all the resulting Kisi locks into one set. The pass and event sources are:
- Pass usages for today. Any pass usage dated today, on a pass type with door access enabled, that is scheduled or already checked in. The access window for a pass runs the full day, midnight to midnight.
- Date-scheduled single-use passes. A single-use pass whose scheduled date is today, on a door-access pass type, with a use still remaining. Its window is also the full day.
- Event tickets happening now. A confirmed ticket to a door-access event where the current moment falls between the event's start and end time. Its window is the event's own start-to-end times.
Because each source is bounded by its own window, a pass opens doors on the day it is used and an event ticket opens doors only while the event is running. The same merge also handles resource bookings, so one person can accumulate Kisi access from a booking, a pass, and an event ticket simultaneously, each with its own valid-from and valid-until window.
How those doors surface depends on the viewer's role. Guests (including the auto-created accounts from public purchases) see exactly the Kisi locks their active bookings, passes, and event tickets grant. Members additionally see the doors their assignments grant on an ongoing basis, across the access integrations you have configured. Admins and owners see every door across every configured integration. If a door integration is briefly unreachable, the doors screen falls back to an empty state rather than blocking, so an offline controller never stops the rest of Deskie from loading. For the wider picture, see door access overview.
Putting it together
A visitor finds a workshop on your public site, buys two tickets, and pays by card: a guest profile is created for them, a confirmed two-ticket record is written at the non-member price, tax and any card fee are added and frozen, Stripe is charged, a paid invoice and payment are produced, and every named attendee gets a confirmation email. If the event has door access enabled, those attendees can open its Kisi locks only between the event's start and end time. Separately, a member buys a ten-use day pass and adds it to their invoice: the purchase is recorded at the member price, the charge waits for the next billing run, and each day they check in one use is spent and the day's doors open from midnight to midnight. If the pass type required approval, none of that access begins until an admin approves the purchase.