Amenity bookings on URBI mobile

Members can now browse amenities, create and edit bookings, and pay directly from URBI in their phone's browser. On the kore-web side, staff continue to manage every booking in the same list and drawer; mobile-created records are fully indistinguishable from staff-created ones.

What members can do on mobile

From the amenity profile page on URBI mobile, members see all the same context staff sees: hours, capacity, type (Reserve, Drop-In, or both), pricing, deposits, occupant restrictions, and any active maintenance closures. From there:

• Browse availability. Members pick a date and time on a live calendar. Slots already booked at capacity (based on max_colliding_bookings) are disabled. URBI re-checks availability immediately before confirming so two members cannot grab the same slot.

• Create a booking with upfront pricing. When the amenity has paid items, the page shows a full breakdown (hourly rate, flat fees, and refundable deposit) and totals it before the member confirms.

• Pay with a saved card, Apple Pay, or Google Pay. Free bookings confirm optimistically. Paid bookings run through Stripe (including 3D Secure when required) on the property's connected account before success is shown.

• Edit an existing booking. Members can change the date or time of their own bookings. URBI re-validates rules (open hours, max duration, collisions) and saves the new times.

• Cancel their own booking. A confirmation prompt is required. Cancelling a paid booking follows the property's standard refund rules.

• Add to calendar. After confirmation, members can add the booking to their device calendar.

• See status at a glance. Confirmed, awaiting confirmation, awaiting payment, and cancelled states are all reflected in the member's feed and on the amenity page.

What staff sees in kore-web

Nothing about staff workflow changes. Every mobile-created booking shows up in the existing amenity bookings list and opens the same Edit Amenity Booking drawer with all four tabs:

• Overview: booking details, unit, member, status badges, and rule violations.

• Payment & Refunds: full Stripe transaction state, refund tools, kept deposits, and the same multi-select refund flow.

• Edit Date & Time: staff can still move any booking; the same validation (open hours, max continuous duration, collision capacity) applies.

• Audit Log: every change is recorded with actor, timestamp, and before/after values. Mobile actions appear here with the member as the actor.

Permissions, RLS, and property scoping behave exactly as before. A booking still belongs to one property, and access still flows through _v_property_membership plus role overrides.

Notifications

Members and staff receive the same notification mix they always have. Mobile-driven actions fan out the following events:

• Booking confirmed: push to the member; email if the property has email notifications enabled.

• Confirmation required: push to staff with the configured notification permission when confirmation_required is true on the amenity.

• Payment due: push to the member when a booking is held with an IN_PROGRESS transaction. Tapping the notification deep-links them straight back into the Payment Due sheet.

• Booking edited: push to the member; audit-log entry for staff.

• Booking cancelled: push to the member; audit-log entry. Refund notifications follow the existing Stripe refund event flow.

Payments

Paid bookings run through the same checkout edge function staff already use. A booking can land on mobile in one of three payment states:

• Paid: Stripe captured the charge; the booking is fully confirmed.

• Free: no paid items on the amenity; the booking is confirmed immediately.

• Awaiting payment: there is an IN_PROGRESS transaction on the booking but no captured charge yet. The member sees a Payment Due sheet with the booking summary, line-item breakdown, and a slide-to-pay control. This typically happens when staff create the booking on the member's behalf and leave payment to be collected by the member later, or when an earlier payment attempt failed at the 3DS step.

If a member dismisses a wallet sheet or fails 3DS, URBI rolls the booking back automatically. The row is soft-deleted and the in-progress transaction is marked VOID_TRANSACTION. No orphan bookings are left behind.

FAQ

Does editing a booking trigger an extra charge?

No. Today URBI mobile only allows the member to change the date and time of an existing booking; pricing items and totals are not re-quoted on edit. If a staff member needs to add a chargeable item to an existing booking, that still happens in the kore-web drawer.

Can a member cancel a paid booking?

Yes. The cancellation prompts them to confirm, then runs through the property's standard refund logic. Whether the charge is refunded, partially refunded, or kept as a forfeit follows the same rules staff sees in the Payment & Refunds tab; there is no separate mobile refund policy.

What happens if staff put the amenity into maintenance after a member has booked?

Existing bookings during the maintenance window are not auto-cancelled. The amenity profile shows a maintenance banner with the closure date range, and new bookings are blocked. Staff should review impacted bookings in the kore-web list and cancel or move them deliberately; every refund decision is captured in the audit log.

Why does a booking show "Awaiting payment" instead of "Confirmed"?

The Stripe charge has not been captured yet. The member should open the booking on their phone and complete the Payment Due sheet. If they received a Payment Due notification, tapping the link in it takes them straight there.