Overview
Your public site lets anyone buy and book without an admin in the loop. There are four self-serve checkout flows: booking a resource, buying a pass, buying an event ticket, and signing up for an asset or plan. Each one is opt-in per item, so you control exactly what appears publicly. The flows share a common backbone: they resolve who is checking out, charge the correct price server-side, create the underlying record (booking, pass purchase, ticket, or signup), generate a paid invoice (plus a payment record when money actually changes hands), and send confirmation emails.
Two kinds of buyer can reach these pages. An anonymous visitor (or someone whose account is only a guest) goes through the standard non-member experience. A signed-in member of your workspace gets a member-aware experience: they see and are charged member pricing where it applies, and the purchase attaches to their existing member profile rather than creating a new guest account. To get member pricing, a member must log in first. For more on how members appear on the public site, see Public website.
Guests versus signed-in members
When an anonymous visitor checks out, Deskie creates a lightweight guest account behind the scenes so the purchase has somewhere to live. It looks up the email entered on the form. If no user exists for that email, it creates one and a credential account with a randomly generated temporary password (using unambiguous characters), and flags the account so the person must change their password on first login. A guest member profile is created with active set to false and the workspace role set to GUEST. The new guest profile is anchored to the location of the item being purchased (the resource's, pass's, or event's location), not the workspace default, so it shows up in that location's roster.
If the email already belongs to an existing person who has a login but no member profile in this workspace, that existing user is reused and a guest profile is created for them. The temporary password and a login link are included in the confirmation email only when a new credential account was actually created.
A signed-in member skips all of this. The flow reuses their existing member profile and user, so no duplicate guest record is created. Because guest profiles are stored as inactive and with the GUEST role, the member-pricing resolver intentionally excludes them: a guest never receives member pricing.
One protection applies to the guest path on resource bookings: if the email entered already belongs to a real member (any role above GUEST) in the workspace, Deskie refuses the guest booking and asks the person to log in and book through their member dashboard to get member pricing. This is because the public flow cannot verify the person is really that member.
How member-aware pricing works
Member pricing is driven by a single resolver that runs on every public page render and at checkout. It identifies the signed-in member behind the request by finding their active member profile in the current workspace. If the viewer is anonymous, is not a member of this workspace, or holds only a GUEST role, the resolver returns nothing and the person gets the standard non-member experience. When it does find a member, it also reports whether that member's access is paused.
Using the same resolver for both the price shown and the price charged guarantees they always match. The display pages surface an effective price: for a signed-in, non-paused member who is eligible for the member rate, that is the member price; for everyone else it is the non-member price. At checkout, the server recomputes the charge authoritatively and never trusts the amount sent by the browser.
Eligibility for the member rate on a given item requires three things together: a non-paused signed-in member, the item must allow member purchase or member booking, and a member price or rate must actually be set. If the member rate is not configured for a particular item or interval, the flow falls back to the non-member price for that item or interval.
Paused members
If a signed-in member's account is paused, they cannot complete any public checkout. The booking, pass, event, and asset flows all refuse the purchase with a message asking them to contact the venue. Because a paused member cannot check out, the public pages show them standard (non-member) pricing rather than member pricing. See Pausing and disabling members.
Booking a resource
Resources that allow non-member bookings appear to anyone. A signed-in member additionally sees resources that allow member bookings, so the public listing matches what they are actually allowed to book. Resource visibility also respects access rules: an anonymous visitor only sees resources with no whitelist, while a signed-in member sees resources whitelisted to them (or their assets) and is hidden from any they are blacklisted from. For the rules themselves, see Resource access rules.
Resources can be booked by the hour or by full day, week, or month, depending on which intervals are enabled on the resource. Hourly availability is generated from the resource's non-member booking hours when those are configured, otherwise from a default window. Availability filtering accounts for existing confirmed bookings and, when the workspace enables a cooldown, for the cooldown buffer around each booking. If a resource allows overlapping bookings, every slot stays available.
At checkout the server resolves the price for the chosen interval. For a signed-in member it recomputes the amount at the member rate when the resource allows member bookings and that rate is set, otherwise the non-member rate. For a guest, the non-member rate is used, and non-hourly amounts are validated against the expected rate. Hourly bookings also enforce the resource's minimum and maximum duration limits, and an optional per-day maximum. Member bookings are additionally checked against the resource's access rules and against a team kill-switch that can disable resource bookings for members on certain teams.
Public self-serve booking always charges the card entered on the form, so billing is never routed to a team even for members whose dashboard bookings would normally be team-billed. Workspace tax and the credit card surcharge are applied on top of the subtotal when enabled, and the exact breakdown is recorded on the resulting invoice and receipt. A booking that comes to zero (including after a coupon) skips payment entirely and is recorded as paid. The booker always receives a confirmation email. For a paid booking, admins are also notified by email, SMS, and push. For the broader booking model, see Booking a resource.
Buying a pass
Passes that are marked to allow non-member purchase and are active appear publicly. Each pass shows its name, image, total uses, expiration window, and price. The price shown is member-aware: a signed-in, eligible member sees the member price when the pass allows member purchase and a member price is set, otherwise the non-member price.
At checkout the server resolves the price again from the pass record (never the client value). A coupon can be applied and reduces the amount due. A pass that comes to zero skips Stripe entirely and is recorded as paid. Otherwise the card is charged through your workspace's public Stripe instance, with tax and card surcharge applied when enabled. The flow creates the pass purchase, a paid invoice, and a payment record, and assigns remaining uses equal to the pass's total uses. Expiration is set from the pass's expiration window when configured. If the pass requires approval, the purchase is recorded as awaiting approval; otherwise it is approved immediately.
After purchase, Deskie sends a receipt email to the buyer (including the temporary password and login link for brand-new guest accounts, and any custom email content configured on the pass) and notifies admins. For a paid pass, admins are notified by email, SMS, and push; for a free pass, admins are notified by email. For more on passes, see Passes.
Buying an event ticket
Events that allow non-member purchase, are active, published, hidden-from-listing turned off, and have not yet ended appear publicly. A signed-in member additionally sees events that allow member purchase, including member-only events. Each event shows its details, host, price, and the number of tickets remaining.
Events support two separate ticket allocations: a non-member bucket and a member bucket, in addition to an overall cap. The tickets-remaining figure shown to a viewer reflects the bucket that applies to them (member or non-member, by role) bounded by the overall cap, so the quantity they can select matches what checkout will accept. Allocation is determined by role: a real member consumes the member bucket and a guest consumes the non-member bucket, independent of which price is paid.
A buyer can purchase several tickets at once and enter details for additional attendees. The purchaser becomes one attendee, and each additional attendee gets their own guest account and attendee record anchored to the event's location. At checkout the server computes the per-ticket price (member or non-member) times the quantity, then validates availability against both the overall cap and the buyer's bucket. A coupon can be applied. Free events (including after a coupon) skip payment and are recorded as paid; paid events are charged through public Stripe with tax and card surcharge applied when enabled, and produce an invoice and payment record.
Confirmation emails go to every attendee. The purchaser receives a full confirmation with payment details; additional attendees receive a simpler notification. Brand-new guest accounts get a temporary password and login link. For a paid event, admins are also notified by email, SMS, and push. For more on events, see Events.
Signing up for an asset or plan
Assets and plans marked to allow public signup, that are active, and that have no current active assignment appear publicly. Flex-type assets can take unlimited members, so they remain available regardless of existing assignments. The listing shows the asset's name, type, size, image, effective rate, and billing cadence. The effective rate is the public signup rate when one is set, otherwise the asset's standard rate. The asset signup flow does not use the member-pricing resolver: pricing comes from the asset's configured rates.
Asset signup is more involved than the other flows because it sets up a recurring commitment. The buyer enters their details, agrees to the workspace agreement (a location-specific agreement is preferred when one exists for the asset's location, otherwise the workspace default), provides a signature, and enters a payment method. The first charge is prorated for the remaining days of the current billing cycle, computed in a cadence-aware way (daily, weekly, monthly, quarterly, or yearly) using the workspace's billing anchor. A coupon can be applied to the prorated amount.
Unlike the guest flows above, a public asset signup creates a full member account: a new user (with the password they chose), a workspace membership with the MEMBER role, and a member profile anchored to the asset's location. If the email already has a member profile in this workspace, the signup is refused. The signup is also captured as a website lead in the CRM. See Assignments and Plans and memberships.
With and without approval
If the asset requires approval, the signup is recorded as awaiting approval, the member profile stays inactive, and the buyer's payment method is stored but not charged yet. Admins are notified, and the buyer receives a submitted-confirmation email. An admin then approves or rejects the signup from the admin area. On approval, Deskie charges the stored payment method for the prorated amount (skipping the card surcharge automatically if the stored method is a bank account rather than a card), creates the paid invoice and payment, creates the active asset assignment with the correct billing interval and next billing date, activates the member, and emails the customer that they are approved. A rejected signup notifies the customer and is not charged.
If the asset does not require approval, payment is taken immediately. Tax and card surcharge are applied when enabled, and the flow creates the paid invoice, payment record, active asset assignment (carrying the asset's billing interval and seeding the next billing date), and an approved signup record. The member profile is active right away, and the customer receives a welcome email with a login link.
Payments, invoices, and receipts
All public checkouts charge through your workspace's public Stripe configuration, so a working Stripe connection is required for any paid item. See Connecting Stripe. Every successful paid purchase produces a paid invoice and a payment record tied to the buyer's member profile, and free purchases still produce a paid invoice; either way, public sales flow into the same billing and reporting views as everything else. See Invoices and Payments and ACH.
When workspace tax or the credit card surcharge is enabled, the surcharge is added on top of the item subtotal and frozen onto the payment intent, the invoice, and the receipt, so the breakdown the buyer paid is preserved exactly. See Tax and card fees. Coupons can be applied in every public flow and reduce the amount due; an item reduced to zero (or free to begin with) skips payment and is still recorded as paid. See Coupons.
New guest accounts created at checkout
Because anonymous buyers get a guest account, public checkout doubles as a soft onboarding step. Brand-new guest accounts receive a temporary password and a login link in their confirmation email, and are required to set a new password on first login. Guest profiles start inactive and with the GUEST role, so they do not receive member pricing or member-only listings until you convert them into a full member. Self-serve guest signups also create a CRM lead so the person enters your pipeline. See Guests, CRM pipeline, and Inviting and onboarding.