tf-checkout-react-native 2.0.0-beta.21 → 2.0.0-beta.23

package/README.md

@@ -1,39 +1,40 @@
 # tf-checkout-react-native
 
-The TicketFairy checkout for React Native. Drop in one component and you have
-ticket selection, add-ons, buyer details, payment, ID verification, and the
-receipt — or compose the sections yourself.
-
-Same API as [`tf-checkout-react`](https://github.com/theticketfairy/tf-shared-libraries/blob/main/packages/tf-checkout-react/README.md); the flow,
-validation, and gating rules are literally the same code.
-
-The 2.x source is maintained in [`tf-shared-libraries/packages/tf-checkout-react-native`](https://github.com/theticketfairy/tf-shared-libraries/tree/main/packages/tf-checkout-react-native).
-The core is private and bundled into both platform packages. Use React 18+ and
-React Query 5 on web; the native requirements below reflect its supported build.
+The Ticket Fairy checkout for React Native. Use the embedded flow or compose its
+ticket selection, add-ons, buyer details, payment and confirmation sections.
+Available features depend on the event, backend, device and payment provider.
+
+The native and [web](https://www.npmjs.com/package/tf-checkout-react)
+packages share a checkout core, with platform-specific UI and payment adapters.
+They do not yet have complete hosted-checkout parity.
+
+The 2.x source is maintained in `tf-shared-libraries/packages/tf-checkout-react-native`;
+the source repository requires access.
+The shared core is private and bundled into both platform packages. Native host
+requirements and peer dependencies are listed below.
 Never put a confidential OAuth client secret in browser or mobile code. Public
 checkout integrations use registered SDK client IDs and owned buyer sessions.
 
 ## Install
 
-### 2.0.0-beta.21 prerelease candidate
+This README describes `2.0.0-beta.23`, the paired 2.x prerelease. Pin it
+explicitly to use this version. `beta` and `latest` are mutable npm tags, not
+guarantees about the highest version; an unqualified install can still resolve
+a stable 1.x package. Check the current dist-tags when choosing a version.
+Publication does not by itself establish backend rollout, device compatibility
+or provider/payment acceptance.
 
-This package targets the matching web/native `2.0.0-beta.21` candidate. Confirm
-exact-version availability and integrity against the [canonical release receipts](https://github.com/theticketfairy/tf-shared-libraries/tree/main/docs/releases)
-before pinning it in an app. Candidate source and local packs alone do not prove
-publication. The unqualified npm package continues to resolve to stable 1.x;
-`@beta` follows the most recently accepted prerelease. Use the exact version
-below when integrating this contract.
+```bash
+npm view tf-checkout-react-native dist-tags
+```
 
 This version preserves quantities across rotating encrypted ticket IDs using
 the API's optional canonical `selectionKey`, while quantity/change APIs and cart
 requests retain the latest encrypted IDs. Deploy and verify the canonical
 base/dated key and dated numeric context before relying on that behavior:
 `display_price`, `price_with_fees`, `fee_included`, `price_currency` and
-`price_symbol`. No localized price parsing or base-price/cap substitution is
-used. Missing optional keys retain opaque-ID compatibility, without a
-rotation-retention claim. The [beta.20 notes](https://github.com/theticketfairy/tf-shared-libraries/blob/main/docs/releases/2.0.0-beta.21.md)
-and [app integration contract](https://github.com/theticketfairy/tf-shared-libraries/blob/main/docs/integration/app-sdk.md)
-record API rollout requirements and separate deployment/provider/device gates.
+`price_symbol`. Missing optional keys retain opaque-ID compatibility without a
+rotation-retention claim. The deployed API must provide and validate that data.
 
 Post-purchase upgrade waiting is a separate server-owned contract. Only valid
 change-options targets can expose Join or Leave; malformed target IDs, labels
@@ -41,11 +42,12 @@ or existing entries are ignored. A sold-out row does not enable it. The backend
 must explicitly offer that organizer-configured flow; local receiver validation
 does not prove its deployed availability or a completed join.
 
+For an Expo host with compatible React and React Native versions:
+
 ```bash
-npx expo install tf-checkout-react-native@2.0.0-beta.21 \
+npx expo install tf-checkout-react-native@2.0.0-beta.23 \
   @tanstack/react-query \
   @stripe/stripe-react-native \
-  react-native-mmkv@3 \
   @react-native-clipboard/clipboard \
   react-native-webview \
   react-native-render-html@6.3.4
@@ -54,31 +56,31 @@ npx expo install tf-checkout-react-native@2.0.0-beta.21 \
 Bare React Native:
 
 ```bash
-npm install tf-checkout-react-native@2.0.0-beta.21 @tanstack/react-query @stripe/stripe-react-native react-native-mmkv@3 @react-native-clipboard/clipboard react-native-webview react-native-render-html@6.3.4
+npm install tf-checkout-react-native@2.0.0-beta.23 @tanstack/react-query @stripe/stripe-react-native @react-native-clipboard/clipboard react-native-webview react-native-render-html@6.3.4
 ```
 
-These are **peer dependencies** on purpose. React contexts and native
-modules must exist exactly once in an app — a second copy of react-query means
-your `<QueryClientProvider>` is invisible to our hooks, and a second Stripe
-means a duplicate pod. As peers there is one copy and no Metro aliasing is ever
-needed.
+These packages, React and React Native are **peer dependencies**. Install
+compatible versions in the host and ensure the SDK and host resolve the same
+React, React Query and native-module instances. Check your dependency tree and
+native build; declaring peers does not itself prevent duplicates.
 
-Everything else — the SDK core, the flow, the UI — ships inside the package.
+The private shared core and native UI are bundled; npm installs the package's
+declared runtime dependencies separately.
 
-This beta.21 candidate retains the `react-native-render-html` peer `>=6.3.4 <7`
+This version requires the `react-native-render-html` peer `>=6.3.4 <7`
 for formatted ticket, add-on, bundle and accommodation descriptions and its
 public `RichText` renderer. Development and component tests use `6.3.4`; the
-install commands above pin that compatible version. See [native rich content](../../docs/integration/native-rich-content.md)
-for the rendering contract and pending acceptance coverage.
+install commands above pin that compatible version. Verify the rendering and
+link behavior needed by your host on its supported devices.
 
 ## Requirements
 
-- React Native `0.81+` with the New Architecture enabled (required by
-  `react-native-mmkv` 3.x)
+- React Native `0.81+` with the New Architecture enabled (the supported build cohort)
 - React `19.1+`, Node `20.19.4+`
-- iOS 15.1+ · Android API 24+ (Stripe SDK minimums)
-- A development build. **Expo Go will not work** — this package uses native
-  modules.
+- iOS 15.1+ · Android API 24+ for the supported React Native 0.81 cohort
+- A development build is recommended for this SDK and real wallet
+  configuration. Expo Go compatibility for the complete checkout is not
+  established.
 
 Add the Stripe plugin to `app.json`:
 
@@ -98,26 +100,104 @@ npx expo run:ios
 
 ## Use it
 
+Native `configureCheckout` and the root `configure` alias require a host-owned
+synchronous `StorageAdapter`. The SDK does not create a persistent MMKV store
+or verify that the host's adapter is encrypted. Restore an OS-protected adapter
+before configuring checkout; migrate old credentials securely or require a new
+sign-in. Use a separate namespace per environment.
+
+The adapter has synchronous `getItem(key)`, `setItem(key, value)` and
+`removeItem(key)` methods. `getItem` returns a string, `null` or `undefined`.
+An adapter that queues asynchronous persistence may also expose `flush():
+Promise<void>`; the host must await it after credential-changing operations
+before reporting durable success. The built-in auth completion does not await
+that final flush automatically. Never pass async functions as the synchronous
+methods or mount SDK hooks before restoring an asynchronous mirror.
+
+### Expo storage example
+
+The following host-owned example restores one Keychain/Keystore-backed entry
+before setup, then writes the next snapshot synchronously before updating its
+in-memory mirror. Install it in an Expo development build with
+`npx expo install expo-secure-store`:
+
+```ts
+// credentialStorage.ts
+import * as SecureStore from 'expo-secure-store'
+import type { StorageAdapter } from 'tf-checkout-react-native'
+
+export async function restoreCredentialStorage(namespace: string): Promise<StorageAdapter> {
+  const raw = await SecureStore.getItemAsync(namespace)
+  const parsed: unknown = raw === null ? {} : JSON.parse(raw)
+  if (!parsed || typeof parsed !== 'object' || Array.isArray(parsed) ||
+      Object.values(parsed).some(value => typeof value !== 'string')) {
+    throw new Error('Could not restore checkout credentials')
+  }
+  let values = new Map(Object.entries(parsed as Record<string, string>))
+  const commit = (next: Map<string, string>) => {
+    SecureStore.setItem(namespace, JSON.stringify(Object.fromEntries(next)), {
+      keychainAccessible: SecureStore.WHEN_UNLOCKED_THIS_DEVICE_ONLY,
+      requireAuthentication: false,
+    })
+    values = next
+  }
+  return {
+    getItem: key => values.get(key) ?? null,
+    setItem: (key, value) => { const next = new Map(values); next.set(key, value); commit(next) },
+    removeItem: key => { const next = new Map(values); next.delete(key); commit(next) },
+  }
+}
+```
+
+This example does not request biometric authentication. Secure storage has
+platform-specific size and backup behavior; configure your host's backup policy
+and handle restoration/write failures. Synchronous writes can block the JS
+thread. See the public [Expo SecureStore documentation](https://docs.expo.dev/versions/latest/sdk/securestore/).
+
 ```tsx
+import { useEffect, useState } from 'react'
+import { Button, Text, View } from 'react-native'
 import { QueryClient, QueryClientProvider } from '@tanstack/react-query'
 import { configureCheckout, EmbeddedCheckout } from 'tf-checkout-react-native'
-
-configureCheckout({ env: 'PROD', clientId: 'PUBLIC_SDK_CLIENT_ID', clientSecret: '', cookieAuth: true })
+import { restoreCredentialStorage } from './credentialStorage'
+
+// Share initialization across repeated effects and permit retry after failure.
+let initialization: Promise<void> | undefined
+function prepareCheckout(): Promise<void> {
+  if (!initialization) {
+    initialization = (async () => {
+      const storage = await restoreCredentialStorage('my_app_checkout_prod')
+      configureCheckout({ env: 'PROD', clientId: 'PUBLIC_SDK_CLIENT_ID', clientSecret: '', storage })
+    })().catch(error => { initialization = undefined; throw error })
+  }
+  return initialization
+}
 
 const queryClient = new QueryClient()
 
 export default function App() {
+  const [ready, setReady] = useState(false)
+  const [failed, setFailed] = useState(false)
+  const [attempt, setAttempt] = useState(0)
+  useEffect(() => {
+    let active = true
+    prepareCheckout().then(() => { if (active) setReady(true) })
+      .catch(() => { if (active) setFailed(true) })
+    return () => { active = false }
+  }, [attempt])
+  if (failed) return <View><Text>Checkout setup failed.</Text><Button title="Try again" onPress={() => { setFailed(false); setAttempt(value => value + 1) }} /></View>
+  if (!ready) return <Text>Getting checkout ready…</Text>
   return (
     <QueryClientProvider client={queryClient}>
-      <EmbeddedCheckout eventId="14304" onComplete={(order) => console.log(order)} />
+      <EmbeddedCheckout eventId="14304" />
     </QueryClientProvider>
   )
 }
 ```
 
-`configureCheckout` runs once at app start and defaults SDK-owned storage to
-MMKV. Storage survives a relaunch; the backend still validates the restored
-session.
+The SDK adds no Expo storage peer. Bare React Native hosts can implement the
+same contract with their own OS-protected storage. The backend still validates
+restored sessions; setup checks adapter shape but does not prove its security.
 
 ### Checkout sessions and account scope
 
@@ -126,12 +206,20 @@ cookie handling. Owned credentials use the SDK's header-backed session storage.
 Public checkout sign-in preserves the event-bound guest carrier and keeps its
 buyer credential server-side; it does not return a full-account ticket or grant
 private account access. First-party full-account flows explicitly use
-`accountAuth: true`; see the shared identity contract below.
+`accountAuth: true` when the host is authorized for that scope.
 
 ### Environments
 
 ```ts
-configureCheckout({ env: 'STAG', clientId: 'PUBLIC_SDK_CLIENT_ID', clientSecret: '', cookieAuth: true })
+export async function prepareStagingCheckout() {
+  const storage = await restoreCredentialStorage('my_app_checkout_stag')
+  configureCheckout({
+    env: 'STAG',
+    clientId: 'PUBLIC_SDK_CLIENT_ID',
+    clientSecret: '',
+    storage,
+  })
+}
 ```
 
 `PROD` → `www.ticketfairy.com`, `STAG` → `test.ticketfairy.com`, `DEV` →
@@ -142,7 +230,7 @@ configureCheckout({ env: 'STAG', clientId: 'PUBLIC_SDK_CLIENT_ID', clientSecret:
 | Prop                                | Type                                | Default     | Does                                          |
 | ----------------------------------- | ----------------------------------- | ----------- | --------------------------------------------- |
 | `eventId`                           | `string`                            | —           | The event to sell. Required.                  |
-| `onComplete`                        | `(order: PlaceOrderResult) => void` | —           | Fires once payment settles.                   |
+| `onComplete`                        | `(order: PlaceOrderResult) => void` | —           | Receives an order result, possibly pending.    |
 | `confirmationMode`                  | `'inline' \| 'redirect'`            | `'inline'`  | `redirect` leaves routing to `onComplete`.    |
 | `initialView`                       | `'tickets' \| 'seats'`              | `'tickets'` | Opening screen.                               |
 | `onViewChange`                      | `(view) => void`                    | —           | Reports the visible view.                     |
@@ -150,7 +238,7 @@ configureCheckout({ env: 'STAG', clientId: 'PUBLIC_SDK_CLIENT_ID', clientSecret:
 | `collectTicketHolders`              | `boolean`                           | `true`      | One named holder per ticket.                  |
 | `collectHolderContact`              | `boolean`                           | `true`      | Also collect holder email/phone.              |
 | `skipBillingWhenProfileComplete`    | `boolean`                           | `false`     | Skip billing for complete signed-in profiles. |
-| `auth`                              | `false \| AuthOptions`              | built-in    | Configure or remove the login modal.          |
+| `auth`                              | `EmbeddedCheckoutProps['auth']`      | built-in    | Configure or remove the login modal.          |
 | `onLogin`                           | `(email?: string) => void`          | —           | Open your own login UI instead.               |
 | `privacyPolicy`                     | `CheckoutPrivacyPolicy`             | —           | Your privacy policy link and brand name.      |
 | `additionalConditions`              | `EventCondition[]`                  | —           | Extra acknowledgements.                       |
@@ -163,6 +251,13 @@ configureCheckout({ env: 'STAG', clientId: 'PUBLIC_SDK_CLIENT_ID', clientSecret:
 `readAttributionFromUrl` is accepted for parity with web and is a no-op —
 there is no `window.location` on a device.
 
+Native hosts must resolve and supply any supported promo or referral explicitly.
+An ambiguous numeric `?r=` can represent either; do not send it as a referral
+without authoritative classification. This beta also leaves conditional custom
+field requiredness to the backend and does not reproduce every hosted-checkout
+conditional visibility rule. Verify the event's field behavior before relying
+on parity.
+
 ## Theming
 
 ```tsx
@@ -181,6 +276,7 @@ The same token names as web: color (`accent`, `surface`, `text`, `muted`,
 Every section reads the same `useCheckout()` store from the provider.
 
 ```tsx
+import { ScrollView } from 'react-native'
 import {
   CheckoutProvider,
   Tickets,
@@ -188,14 +284,13 @@ import {
   BillingInfo,
   Payment,
   OrderSummary,
-  useCheckout,
 } from 'tf-checkout-react-native'
 
 const MyCheckout = () => (
   <CheckoutProvider theme={{ colorScheme: 'dark' }}>
     <ScrollView>
-      <Tickets />
-      <AddOns />
+      <Tickets eventId="14304" />
+      <AddOns eventId="14304" />
       <BillingInfo />
       <OrderSummary />
       <Payment />
@@ -213,39 +308,59 @@ const MyCheckout = () => (
 **Auth** — `AuthModal`, `LoginForm`, `RegisterForm`, `ForgotPasswordForm`,
 `ResetPasswordForm`.
 
+## Payment methods
+
+The payment section uses event and server eligibility plus device support to
+select available methods. Stripe card entry uses the native card field by
+default. A composed host can opt into Stripe PaymentSheet by supplying
+`paymentSheet={{ merchantDisplayName, returnURL }}` and
+`options={{ urlScheme }}` to `CheckoutProvider`; the registered return URL must
+be `${urlScheme}://stripe-redirect` and the host must route Stripe callbacks.
+The embedded component does not expose this opt-in.
+
+This beta admits the sheet for eligible non-MXN Stripe PaymentIntents containing
+card alone, or card plus Cash App Pay in USD; delayed methods are not admitted
+in that sheet. MXN installments and new-card payment plans use the card field.
+Stripe may offer Link when the account and intent qualify. Link is separate from
+saved-card AutoFill, which is not guaranteed by the SDK or PaymentSheet.
+Apple Pay and Google Pay require backend, device and merchant configuration;
+the event's payment account and the host's wallet setup must be compatible.
+Other gateway or redirect flows can require a provider page. Test each enabled
+method on the intended account and device before relying on it.
+
 ## Headless
 
 `useCheckout()` gives you the whole flow with no UI.
 
 ```tsx
-const checkout = useCheckout({ eventId: '14304' })
+import { Button } from 'react-native'
+import { useCheckout, type TicketSelection } from 'tf-checkout-react-native'
 
-await checkout.setTickets('14304', [{ ticketTypeId: '1', quantity: 2 }])
-checkout.setBilling({ firstName, lastName, email, phone })
-checkout.setConsent({ ttfOptIn: true, brandOptIn: false })
-const order = await checkout.placeOrder('card')
+function Reserve({ eventId, selections }: { eventId: string; selections: TicketSelection[] }) {
+  const checkout = useCheckout()
+  return <Button title="Reserve" onPress={() => { void checkout.setTickets(eventId, selections) }} />
+}
 ```
 
-`placeOrder` is retry-safe: one order, one charge, however many times the button
-is pressed.
+Build `selections` from the current event catalog, then collect the applicable
+billing, holder and consent data before calling `placeOrder`. The engine
+coordinates concurrent placement and retains an order when a payment outcome
+is uncertain. Confirm the authoritative order and provider status before
+retrying or fulfilling; this is not a guarantee of exactly-once charging across
+all hosts and providers.
 
 ### Starting a new checkout
 
-`reset()` discards the cart. It returns nothing, so
-`useEffect(() => checkout.reset(), [eventId])` works as it always has. Before
-any money moves it resets at once. While a payment is going through, it waits
-for the payment to finish, so the payment never lands in a new cart. An order
-that is not confirmed yet is kept when it is charged, or when a payment step
-failed without an answer that nothing was charged (a network error, a
-timeout, or a Stripe error that is not a decline or a cancel). A Razorpay or
-redirect payment page the buyer closes is kept only when a check of the order
-fails or finds a payment; otherwise it is a cancel. Pressing Pay again then
-finishes the order, or pays as usual when nothing was paid. A server refusal
-of the order, such as an expired reservation, releases it.
-
-To know which happened, await `resetWhenSettled()` instead. It resolves `true`
-once the checkout is reset, or `false` when it kept the order. In that case,
-show the buyer `PAID_ORDER_PENDING_MESSAGE`. While it waits for a payment
+`reset()` returns nothing and starts a reset. If payment is in flight, the
+engine waits for that operation; it retains an order when its recorded state
+indicates money may have moved. A closed provider page or network error is not
+proof that no payment occurred. Reconcile the order with the backend and payment
+provider before retrying or fulfilling it.
+
+To know whether reset completed, await `resetWhenSettled()` instead. It resolves
+`true` after reset or `false` when reset cannot proceed, including a retained
+order or a retired checkout. For a payment that may have moved, show the buyer
+`PAID_ORDER_PENDING_MESSAGE` and reconcile it. While it waits for a payment
 (`status === 'placing'`), tell the buyer, for example "Finishing your
 payment…":
 
@@ -254,20 +369,25 @@ if (checkout.status === 'placing') setNotice('Finishing your payment…')
 if (!(await checkout.resetWhenSettled())) setNotice(PAID_ORDER_PENDING_MESSAGE)
 ```
 
-A custom `providerPage` must resolve `'dismiss'` when it closes or unmounts, and
-any other custom port must settle then too, or `resetWhenSettled()` waits for it.
+A custom `providerPage` must resolve `{ event: 'dismiss' }` when it closes or
+unmounts, and other custom ports must settle too, or `resetWhenSettled()` waits.
 
-A custom confirmer marks a decline or cancel by rejecting with
-`paymentProviderError(message, 'declined' | 'cancelled')`. Any other rejection
-counts as a payment that may have gone through, so the order is kept.
+A custom confirmer can classify a failure with
+`paymentProviderError(message, outcome)`, where `outcome` is `declined`,
+`cancelled`, `notStarted` or `unknown`. Use the first three only when the
+provider confirms that no charge occurred. An unknown outcome needs
+reconciliation, not an assumption that payment failed.
 
-The full SDK is re-exported from this package — `ttf`, `api`, `hooks`, `dtos`,
-`logic`, and the engine. See the [SDK reference](https://github.com/theticketfairy/tf-shared-libraries/blob/main/packages/tf-checkout-shared/README.md).
+The shared SDK exports are available from this package, including `ttf`, hooks,
+types and the engine. The package's TypeScript declarations describe its public
+exports.
 
 ## Rewards
 
 The native analogue of the web Rewards section: standing, the referral tree,
 the prize ladder, packs, the share card, and one share button.
+Render standalone `Confirmation` within an active `CheckoutProvider`; the host
+provides the `orderHash` used in this example.
 
 ```tsx
 import { Confirmation, Rewards } from 'tf-checkout-react-native'
@@ -277,7 +397,8 @@ import { Confirmation, Rewards } from 'tf-checkout-react-native'
 ```
 
 When `<EmbeddedCheckout/>` renders the receipt itself, pass the block through
-`confirmationChildren`:
+`confirmationChildren`. In this example the host supplies `eventId` and
+`MyRewards`:
 
 ```tsx
 <EmbeddedCheckout eventId={eventId} confirmationChildren={<MyRewards />} />
@@ -289,8 +410,7 @@ Native adaptations, and why:
   web SVG uses. Adding `react-native-svg` would be a new native peer for every
   customer app; a dot-and-line picture does not need one.
 - **One share button.** Per-channel buttons collapse into `Share.share()` — the
-  OS sheet already lists every installed app, which is what the web's share
-  sheet channel reaches for through the browser.
+  OS sheet presents the eligible share targets available on that device.
 - **Copy comes in as props**, this package's idiom. `translate`, or `locale` and
   `messages` for the built-in `rewards.*` catalogue.
 
@@ -299,13 +419,14 @@ Native adaptations, and why:
 `SeatMap` uses the existing WebView peer to render internal charts or the event's
 Seats.io chart, with the shared core owning selection, holds and reservations.
 It requires the matching backend seating/session contracts. Provider-backed hold
-and deployed-cart acceptance remain separate checks; see the
-[seating contract and evidence](https://github.com/theticketfairy/tf-shared-libraries/blob/main/docs/integration/app-sdk.md#seat-chart-and-ticket-refund-checkpoint--25-october-2026).
+and deployed-cart acceptance remain separate checks.
 
-## Known gaps vs web
+## Known gaps vs hosted checkout
 
-- **Smooth scroll** — no `scrollIntoView` equivalent, so `autoScroll` has no
-  native counterpart.
+Native URL attribution requires host-supplied values, conditional custom-field
+visibility is not fully mirrored, and native smooth scroll is not equivalent to
+web's `autoScroll`. Provider, wallet and device behavior also needs separate
+qualification. The list is not a claim of full hosted or web SDK parity.
 
 ## Development
 
@@ -323,24 +444,22 @@ Both need a dev client. Build one with:
 cd example && pnpm run ios
 ```
 
-Set credentials in `example/.env` (`EXPO_PUBLIC_`-prefixed); see
-`example/.env.example`.
+Use only public, non-secret configuration in `example/.env`
+(`EXPO_PUBLIC_`-prefixed); never put a confidential credential in the app.
 
 The example's `metro.config.js` pins React, react-query, and Stripe to single
 copies. That is a **workspace-only** concern — it exists because the example
-consumes the library through a symlink. Consumers installing from npm need
-nothing of the sort.
+consumes the library through a symlink. An npm host should still verify that its
+dependency tree resolves the intended single instances.
 
 ---
 
-Part of the [TicketFairy checkout monorepo](https://github.com/theticketfairy/tf-shared-libraries/blob/main/README.md).
-
+The checkout monorepo is available to authorised repository collaborators.
 
 Public checkout sign-in uses event-scoped server-only buyer binding, without a bundled
 client secret. The checkout's auth modal supplies the event automatically; standalone
 `AuthModal` callers pass `checkoutEventId` and can receive the narrow
 `onCheckoutAuthenticated(CheckoutBuyerProfile)` callback. Password/signup/email/phone
 proofs still complete required two-factor verification. These credentials cannot read
-private account preferences or tickets. See the [shared identity contract](https://github.com/theticketfairy/tf-shared-libraries/blob/main/packages/tf-checkout-shared/README.md) for
-scope, retry, logout and configuration ownership. Existing confidential OAuth clients
+private account preferences or tickets. Existing confidential OAuth clients
 are trusted-server integrations; never distribute their secrets in browser/native code.