Skip to main content
Owner: Product and Backend Engineering Last reviewed: 2026-09-23 Next review: 2026-12-23 Students purchase an available consultation, attend its sessions, and can later move an eligible session or purchase another consultation. Consultants can prompt students to reschedule missed sessions and approve replacement times.

Initial purchase and attendance

Initial purchase is not a consultant approval-then-payment workflow. Approval in the rescheduling flow below applies after a replacement time has been applied.

Recover a missed session

  1. The owning consultant sends a reschedule prompt for an eligible missed session.
  2. The student receives email and an in-app notification and opens that session’s rescheduling UI. The prompt itself changes no booking dates or payment state.
  3. The student selects a replacement time. Availability, fees, limits, minimum notice, and cooldowns still apply. The student can also start without a prompt.
  4. With no fee, the backend applies the replacement dates immediately. With a fee, dates are applied after successful backend payment processing.
  5. The consultant or an admin approves the rescheduled session, changing it to scheduled. Both participants attend the replacement session with fresh attendance tracking.
There is no reschedule-rejection endpoint in this flow. See the rescheduling and rebooking lifecycle for the exact responsibilities and state transitions.

Purchase the consultation again

  1. The student chooses the same consultation and a new available date/time.
  2. The frontend checks canPurchase, not just isEnrolled. Existing consultation enrollment does not block a repeat purchase, even if an earlier booking is active.
  3. The student completes a new checkout at current pricing. Rebooking creates a separate order, enrollment, booking, and session set; earlier records stay unchanged.
Rebooking purchases more consultation time. Rescheduling moves an existing session. Do not send a reschedule-fee order or reuse an old payment reference for a repeat purchase.

Delivery and validation boundaries

Backend implementation and documented contracts do not prove that all frontend clients or live integrations have been updated. Verify notification navigation, canPurchase handling, actual payment callbacks, worker execution, and release behavior with the QA checklist.