Mutation

Price a basket, mint the order, and — when money is owed — the PaymentIntent to pay for it. The single entry point that replaces registerForActivity, purchaseProduct, bookActivityTime, signUpTeam and signUpIndividual: one mutation, any mix of items, one order.

Two phases. This one writes a pending purchase and its lines, holding no capacity and spending no credits, and returns a CheckoutSession for the client to confirm with Stripe Elements. completePurchase (or the webhook backing it up) then fulfills it. A free or fully credit-funded basket skips Stripe entirely and comes back already completed, with a null checkoutSession — the same free-versus-paid contract the mutations it replaces had.

Works signed-out when the business allows guest checkout: pass buyer with the buyer's email and a bot-challenge token.

Fulfill a minted purchase once its payment has been confirmed: books the sessions, mints the entitlements, spends the credits, and records how the order was funded, all in one transaction.

Idempotent, and safe to race — the Stripe webhook calls the same routine, so a buyer who closes the tab mid-confirm still gets their booking exactly once.

Authorized by possession of the unguessable purchase id, so a guest can finish their own checkout. A signed-in caller must additionally own the purchase, so a leaked id cannot be completed by a third party.

Cancel a booking and, under the activity's cancellation policy, return the money and the credits it consumed. Booking.cancellationPreview says what this will do before it is called.

Join the queue for a full session. Writes a waitlisted booking with no order behind it — nothing is charged until a place is offered and accepted.

For a card-paid activity, pass a confirmed SetupIntent so the vaulted card can be charged off-session if the place is offered automatically.

Accept an offered place. Re-enters checkout for the amount owed, so the result carries a CheckoutSession exactly as checkout does; the existing waitlisted booking is confirmed rather than a second one inserted.

Request an email containing a 6-digit code to confirm a new account. Always returns success regardless of whether the email is already in use (anti-enumeration). If an account already exists for the email, a sign-in code is sent instead.

When businessHandle is set, the issued code is pinned to that business and the resulting token is scoped to it (does not set a cross-account cookie). Used by the business-pinned embed sign-in flow.

When name is set and the email resolves to a brand-new account at redemption time, that name is applied to the inserted user row. Ignored for emails that already have an account.

Request a sign-in email containing a 6-digit code. Always returns success regardless of whether the email matches an existing account (anti-enumeration).

When businessHandle is set, the issued code is pinned to that business and the resulting token is scoped to it (does not set a cross-account cookie). Used by the business-pinned embed sign-in flow.

Redeem a 6-digit auth code and sign the user in. Returns the created or signed-in user, the JWT token, and the redirect URL stored on the code. Sets the auth cookie on success — except for codes that were issued with a business pin, which return a business-scoped token without touching the cookie session.

Create the account a social sign-in stopped short of creating, and sign in as it. token is the pending sign-up handed to a popup opener; omit it and the pending cookie is used instead (the popup-blocked flow, which has no opener to hand anything to). name is the viewer's chosen display name, falling back to whatever the provider shared.

Resolution is re-run from scratch, so an account that appeared in the meantime — another tab, an email sign-up — is linked rather than forked. Sets the auth cookie, or returns a business-scoped token for an embed.

Discard a pending social sign-up without creating anything. Clears the pending cookie so a later page load doesn't ask again.

Register for an individual activity session. Use productPurchase to pay with an existing pass/membership, or omit it for direct purchase. Pass guest to register on behalf of someone else; the caller is recorded as the booker and pays. The activity's participant policy must allow guest registrations.

Pass buyer when the caller is not signed in to perform guest checkout. Requires the business's guestCheckoutEnabled setting.

Books an open time range on a structure: booking activity. Validates [startAt, endAt) is a contiguous run of the activity's open increments whose increment count is within [minIncrements, maxIncrements], then creates the booking — an activityId-tied appointment session + registration. Free bookings confirm immediately; activities set to request mode create a pending request the business approves or declines. Paid bookings charge bookingPricePerIncrement × increments and create the booking only once payment succeeds (via completeCheckout). buyer supplies guest details when the caller is not signed in.

productPurchase redeems one of the caller's passes/memberships (as surfaced by Activity.bookingPaymentResolution) against the booking: a pass spends the activity's creditCost (default 1) per booked increment, so a covering purchase settles the whole booking for creditCost × increments, confirming immediately via the free path — no charge, no checkout (unless a tip is added; see tipAmount). It's all-or-nothing — the purchase must belong to the buyer, be active, cover the activity, and (for a finite session count) have enough sessions for the whole booking; otherwise it's rejected and the caller pays by card.

formData carries answers to the activity's registration blocks — intake questionnaires and consent/waiver signatures collected before the appointment — persisted as block metadata + an agreement PDF on the resulting registration, exactly like registerForActivity.

tipAmount adds an optional gratuity (cents). On a paid booking it rides the same charge, added after tax; on a pass/membership-covered booking it mints a tip-only checkout instead of confirming immediately — the booking (and the pass debit) then commits only once the tip payment succeeds, so an abandoned checkout books nothing. A tip is always excluded from both the tax base and the platform-fee base, and ignored for free bookings. Tipping is per-activity — a booking activity accepts tips by default, but one whose operator turned tipping off rejects a non-zero tipAmount outright.

emailMarketingConsent records the participant's optional opt-in to the business's marketing email, exactly like registerForActivity — honoured only when the booked activity carries an emailMarketing registration block and the business has consent collection enabled.

Cancel an existing activity registration.

Complete a checkout after Stripe confirmation, then fulfill the underlying entity (pass purchase or registration). Idempotent — safe to call multiple times.

Two flows converge here:

• Guest (pay-only): the client already confirmed a PaymentIntent on the

business's connected account; this verifies it succeeded.

• Signed-in (save-and-pay): the client confirmed a SetupIntent that

vaulted the card on the viewer's platform wallet and passes the resulting paymentMethod; the server clones it onto the connected account and runs the (off-session) direct charge here, so the card joins the unified wallet and the business is merchant of record.

Purchase a product (pass, membership, gift card, or physical product). Returns a checkout session if payment is required, or the purchase directly for free products.

Pass buyer when the caller is not signed in to perform guest checkout. Requires the business's guestCheckoutEnabled setting. Passes and memberships always require a signed-in user.

Mint a SetupIntent on the business's connected account so the buyer can authorize a bank-debit mandate before the subscription they're paying for exists.

For rails that cannot collect a mandate from a deferred-intent Payment Element — Canadian pre-authorized debit, which Stripe refuses there outright — this is what the bank form mounts against. Confirm it with confirmSetup, then hand the SetupIntent id to purchaseProduct as bankDebitMandate.

Re-runs the gates behind Membership.bankDebit server-side, plus the connected account's capability, and returns an error rather than a mandate when any of them says no — unlike the charge-time gate, there is nothing to silently fall back to here: the buyer asked for a bank form.

Add a business, staff member (instructor), or activity to the authenticated user's favorites. Idempotent — adding an existing favorite is a no-op.

Remove a business, staff member, or activity from the authenticated user's favorites. Idempotent — removing a favorite that isn't set is a no-op.