soniang-ux
### Summary After completing a paid Pro (yearly) checkout, the account stays on the Community plan. Linking Google afterwards leaves the entitlement stranded, and signing in with that same Google account on the other domain fails with `identity_already_exists`. ### Steps to reproduce 1. Open `/pricing` while signed out. 2. Complete Pro yearly checkout via Stripe/Link. The redirect returns to `/pricing?checkout=success` on `threeui.netlify.app`, followed by a `/pricing/#access_token=...` callback. 3. Connect Google afterwards, as the pricing FAQ instructs: "After payment, connect Google so you can recover your Pro access on another device." 4. Reload `/pricing` and open the account menu. ### Expected The account shows the Pro plan, and Pro components unlock. ### Actual * The account menu still shows **Community plan** long after payment. Reloading does not change it. * The Stripe subscription is active and a receipt was issued, so the charge itself succeeded. * Signing in with the same Google account on `threeui.com` redirects to: ``` https://threeui.com/pricing?error=server_error&error_code=identity_already_exists&error_description=Identity+is+already+linked+to+another+user ``` ### Suspected cause Checkout appears to create an anonymous Supabase user, and the post-payment Google link attaches the Google identity to that anonymous record. A later OAuth sign-in on the other domain resolves to a different user and then cannot claim the already-linked identity, so the entitlement sits on an account the buyer can never sign into. This looks related to #4, which flagged the same `threeui.com` vs `threeui.netlify.app` Supabase Site URL and allowed-origin mismatch. ### Environment * Domains: `threeui.netlify.app` and `threeui.com` * Auth: Supabase Google OAuth * Desktop Chrome on macOS ### Impact A paying customer is left on the Community plan with no self-serve way to recover access. It also encourages repeat checkout attempts, which risks duplicate charges. ### Suggested fix * Attach the Stripe entitlement to the email on the Checkout session rather than to the anonymous session's user id. * When `identity_already_exists` comes back, sign the user into the existing identity's account instead of returning a server error. * Align the Supabase Site URL and redirect allow-list across both domains (see #4).