tf-checkout-react 2.0.0-beta.26 → 2.0.0-beta.27

package/README.md

@@ -7,17 +7,23 @@ components, plus the shared API and React Query hooks. Which paths a buyer can
 actually use depend on the event, the deployed API, the buyer's session and the
 payment provider.
 
-This reference describes **2.0.0-beta.26**. It is a prerelease with a different
+This reference describes **2.0.0-beta.27**. It is a prerelease with a different
 API from 1.x. Pin the version while evaluating it. npm's `latest` and `beta`
 tags can move independently and an unqualified install may select 1.x:
 
 ```bash
 npm view tf-checkout-react dist-tags
-npm install tf-checkout-react@2.0.0-beta.26 @tanstack/react-query react react-dom
+npm install tf-checkout-react@2.0.0-beta.27 @tanstack/react-query react react-dom
 ```
 
-The [API reference](https://unpkg.com/tf-checkout-react@2.0.0-beta.26/docs/API.md)
-is included as `docs/API.md` in this package.
+The [API reference](https://unpkg.com/tf-checkout-react@2.0.0-beta.27/docs/API.html)
+is included as `docs/API.md` and `docs/API.html` in this package. A
+[standalone guide](https://unpkg.com/tf-checkout-react@2.0.0-beta.27/docs/GUIDE.html)
+is also available.
+
+If the HTML has not reached the CDN yet, open the packaged `docs/API.md` in a
+Markdown viewer or read the [plain-text API Markdown](https://cdn.jsdelivr.net/npm/tf-checkout-react@2.0.0-beta.27/docs/API.md).
+The full guide is also shown on this npm page.
 
 ## Choose a checkout layout
 
@@ -677,7 +683,7 @@ error or closed provider page means the charge failed. A custom provider page mu
 settle with `{ event: 'dismiss' }` on close/unmount, and other custom payment
 ports must settle, or a waiting reset cannot finish.
 
-The beta.26 declaration comments for `reset` and `PAID_ORDER_PENDING_MESSAGE`
+The beta.27 declaration comments for `reset` and `PAID_ORDER_PENDING_MESSAGE`
 say pressing Pay again finishes an unconfirmed order; the `resetWhenSettled`
 comment also omits retired checkouts as a reason for `false`. Those comments do
 not establish that a retry is safe. Use the session and reconciliation guidance
@@ -734,7 +740,7 @@ holder's answers in `ticketDataCapture`, and add-on answers via
 the opaque catalog ID. Use backend country/state IDs for `countryId` and
 `stateId`; `countryCode` / `stateCode` are payment billing codes.
 
-In beta.26 conditional custom-field requiredness is left to the backend and
+In beta.27 conditional custom-field requiredness is left to the backend and
 not all hosted-checkout conditional visibility is reproduced. Verify the
 actual event against the deployed checkout, including blanks, images, holder
 scoping and validation errors; do not claim parity from the presence of a
@@ -755,7 +761,7 @@ unknown; `reloadCheckoutDetails()` can also retry the waiver read. A retained
 order with a possible payment follows separate recovery and needs reconciliation.
 `WaiverSigning` handles the SDK's signing flow.
 
-**Consent limitation in beta.26:** when `privacyPolicy` is supplied, the
+**Consent limitation in beta.27:** when `privacyPolicy` is supplied, the
 stock `BillingInfo` replaces the Ticket Fairy marketing checkbox with the
 required privacy checkbox, but both use `consent.ttfOptIn`; the order sends
 that value as `ttf_opt_in`. The privacy acknowledgement and Ticket Fairy
@@ -1242,7 +1248,7 @@ existing 1.x integration pinned until the new flow and backend are verified.
 There is no automatic translation of old URLs, component props, account
 sessions or persisted 1.x state.
 
-| 1.x integration | 2.0.0-beta.26 approach |
+| 1.x integration | 2.0.0-beta.27 approach |
 | --- | --- |
 | `setConfigs({ BASE_URL, ... })` | `configureCheckout({ env` or `baseUrl`, `clientId`, `clientSecret: ''`, ... `})`; public client registration and session setup are required. |
 | `TicketsContainer`, `SeatMapContainer`, `AddOnsContainer` | `EmbeddedCheckout` or `Tickets`, `SeatMap`, `AddOns` under `CheckoutProvider`. Adapt callbacks and navigation. |