# Continue checkout after confirming a new account

A configured partner website can return a new customer to their selected
checkout when they open the signup confirmation email on another device. The
return contains product, offer, addon and quantity choices. The checkout fetches
a fresh canonical quote, applies current eligibility and legal checks, and still
requires the customer's explicit purchase confirmation.

This capability is disabled by default on the website. Deploying the code alone
preserves current signup responses and the existing inline checkout journey.

## Authority and routes

Booking Bible owns identity and signup checks. The new anonymous, rate-limited
`POST /api/v1/auth/signup/confirm` accepts only `token_hash`, organization slug
and brand UUID. It verifies Supabase with `type: 'signup'`, which looks up a
confirmation token rather than a recovery/magic-link token. Invited identities
are rejected. The server also verifies a 24-hour signed signup context bound to
email, organization, brand and exact environment origin. That context is issued
only after canonical signup's guardian/imported-account checks; editable user
metadata alone is not authority. A real password, verified email, active scoped
membership, matching acquisition brand, undeleted profile and satisfiable MFA
state are required before session tokens are returned.

The current official provider implementation documents the distinct token
families in [verify.go](https://github.com/supabase/auth/blob/master/internal/api/verify.go).
The [Supabase SSR guide](https://supabase.com/docs/guides/getting-started/tutorials/with-nextjs)
describes direct token-hash confirmation without an originating-device cookie.
Existing mobile binding, recovery codes and PKCE exchanges retain their contracts.

The website receiver is `/api/auth/signup/callback`; it exchanges the token on
the server, sets httpOnly session cookies only after success and removes token
parameters before redirect. Redirects are private/no-store and no-referrer.
Failure returns to inline checkout login with a localized explanation, or the
ordinary login modal if there is no checkout. It never navigates to a host
supplied in `next`. No new member navigation item, icon, entitlement or historical
access rule is introduced. The website's existing branding and locale remain.
Only a generic successful auth audit is added, without tokens or URLs.

## Staging first activation

Do not enable the website flag until these exact prerequisites are complete:

1. Deploy Booking Bible's signup/confirm endpoint and the website callback.
2. Set **Booking Bible server-only** `PARTNER_SIGNUP_CALLBACKS_JSON` to an array
   of exact `{ "organization_id": "<uuid>", "brand_id": "<uuid>", "origin": "https://<approved-staging-host>" }`
   tuples. Each tuple is unique. The origin must be an HTTPS origin with no
   path, credentials, query, fragment or wildcard. Staging must contain only
   approved staging receivers; there is no production fallback.
3. Set **Booking Bible server-only** `PARTNER_SIGNUP_CONFIRMATION_SECRET` to an
   independently generated random value of at least 32 characters. Keep it
   stable for pending emails; replacing it expires their continuation authority.
4. Verify the existing canonical rows: active organization and active brand
   belonging to that organization. The mapping in step 2 is the server owner's
   explicit trust grant for the external receiver. `brands.website_url` is
   presentation; `brand_custom_domains` describes platform portal routing.
   Neither enables this flow. Do not add a platform portal-domain row for an
   independently hosted partner website. Independently approve ownership and
   deployment of the exact external callback before adding the mapping.
5. Approve the callback URL in Supabase Auth redirect configuration and install
   the repository's complete `docs/templates/supabase-auth/confirm-signup.html`
   into **Confirm signup** (`mailer_templates_confirmation_content`). This is
   the same previously prepared marked web-signup template; no second template
   change is needed. Its `cross_device_signup_v1` branch appends
   `&token_hash={{ .TokenHash }}&type=email` to `.RedirectTo`. Unmarked callers
   continue through `.ConfirmationURL`.
6. Set **website server-only** `BB_PARTNER_SIGNUP_CONTINUATION_ENABLED=true` on
   staging. Missing mapping, secret or valid organization/brand then fails closed; it
   cannot silently send the buyer through another origin.
7. With an explicitly authorized synthetic destination, send one staging signup
   email and open it on a second device with no original cookies. Verify exact
   offer/quantity/addon choices, fresh quote/legal gates, and no automatic
   purchase. Verify expired/used links, imported recovery, guardian and MFA
   refusal. No send or hosted configuration change is performed by these tests.
8. Only after staging acceptance, repeat the approved configuration and activation
   sequence in production with its separate external-origin ownership and deployment evidence.

Read-only prerequisite query (bind parameters, no raw user input):

```sql
select o.id as organization_id, o.is_active, o.platform_status,
       b.id as brand_id, b.status as brand_status
from public.organizations o
join public.brands b on b.organization_id = o.id
where o.id = :organization_id and b.id = :brand_id;
```

Configuration requires authorized hosting environment access and Supabase
Dashboard/Auth template or Management API access. Supabase MCP in this session
provides database reads and documentation; no callable hosted Auth-template
update has been identified. Save the current template before any approved update.

Rollback sets the website flag false first, then removes the corresponding
Booking Bible mapping if necessary. Existing password/OTP login stays available;
pending direct confirmation links fail safely and preserve checkout choices.
With the flag false, the browser still persists its existing explicit inline
checkout intent; it sends no partner payload to Booking Bible and promises no
cross-device continuation. No database migration is required.