Zum Hauptinhalt springen
Was this helpful?

Post-Payment Customer Linking

This page documents the PrimeCal flow that runs after a successful public booking payment. Use it when you need to understand:

  • how PrimeCal resolves or creates the customer account
  • how the reservation is linked idempotently
  • how the confirmation page chooses its calendar destination
  • how future booking forms prefill safe customer fields

Customer Account Resolution​

After a successful payment, PrimeCal automatically:

  1. normalizes the customer email and contact fields
  2. performs a case-insensitive user lookup
  3. safely enriches an existing user only when fields are missing
  4. creates a customer account when the email is unknown
  5. creates a short-lived password-setup token (stored as a hash only)

The reservation is linked to the resolved customer account idempotently. Audit records are created for:

  • auto-created customers
  • safe profile enrichments
  • reservation-to-user linking
  • skipped or conflicting relink attempts

Public Endpoints And Response Contract​

Relevant endpoints:

  • POST /api/public/booking/organisations/:slug/reserve
  • GET /api/public/booking/organisations/:slug/checkout-status
  • POST /api/payments/stripe/webhook

The checkout-status response carries the fields the client needs after payment:

{
  "reservationId": 901,
  "status": "confirmed",
  "paymentStatus": "succeeded",
  "requiresPayment": true,
  "canRetryPayment": false,
  "confirmationMessage": "Your booking is confirmed.",
  "customerAccount": {
    "status": "created",
    "requiresPasswordSetup": true,
    "profile": {
      "name": "May B. Late",
      "email": "may@example.com",
      "phone": "+15550001015"
    }
  },
  "navigation": {
    "organisationSlug": "primecal-spa",
    "calendarPageUrl": "/book/primecal-spa"
  }
}

Notes:

  • customerAccount.profile is intentionally lean and contains only safe prefill fields.
  • navigation.calendarPageUrl is the backend-provided destination for public flows that should not hard-code a route.
  • authenticated customers can still be sent to /app/calendar as the canonical signed-in workspace route.

Confirmation-Page Behavior​

After the public booking return from Stripe:

  1. the client polls checkout-status
  2. the payment-return screen renders when the reservation is confirmed
  3. the screen shows:
    • Go to my calendar
    • Book another time
  4. the primary action resolves as:
    • /app/calendar for an authenticated customer session
    • navigation.calendarPageUrl for a public or auto-created customer flow

Customer-Profile Prefills​

The client merges safe customer data from:

  1. the authenticated session
  2. checkout-status.customerAccount.profile
  3. a local customer-profile cache used for later public booking visits

Only these fields are reused:

  • name
  • email
  • phone

The public form still allows the user to override every value before submit.

Password Setup And Onboarding Messages​

The backend prepares a password-setup token after auto-creating a customer account, but delivery still needs to be triggered. Typical options are:

  • a built-in onboarding email
  • a notification or automation message
  • a support or CRM-triggered onboarding flow

Keep these requirements in mind:

  • never send plain-text passwords
  • keep the password-setup link short-lived
  • explain clearly that the account was created after a paid booking
  • explain that the link lets the customer finish account activation safely

Security Notes​

  • PrimeCal does not store raw card data.
  • PrimeCal does not expose Stripe secrets, webhook secrets, or internal payment metadata in the frontend.
  • Payment confirmation remains webhook-driven.
  • Customer-profile reuse is limited to safe booking-contact fields.
  • Auto-created customer access stays scoped to the intended booking/calendar path instead of broad organisation membership.