@flopay/react 1.9.7 → 1.9.9

package/README.md

@@ -650,6 +650,12 @@ catalog. If the draft already contains an email, that claim also attaches the
 buyer. Otherwise it deliberately omits `accountData` and returns a complete,
 still-anonymous session (`buyerIdentified: false`).
 
+The optional `createSession.timeoutMs` value is applied independently to both
+phases (12 seconds each by default). The shell POST stops its deadline as soon
+as the shell is usable, and the initial catalogue claim PATCH starts with a
+fresh signal and the full budget. Opting out of detached creation keeps the
+one-shot request's single total deadline.
+
 `FloPayCheckout` renders from the shell, so the hosted card form mounts and
 becomes interactive without waiting for either the claim or Stripe.js — Stripe
 wallets, APMs and PayPal load in parallel with the catalog claim and appear
@@ -1046,6 +1052,22 @@ Stripe and PayPal SDK load/runtime failures emit `provider_runtime`. Inline
 `validation_rejected` / `payment_declined` outcomes and never carry
 `failureCategory`.
 
+If Stripe.js cannot initialize after `FloPayCheckout` resolves a full session,
+the checkout no longer hides a provider-independent payment surface. A
+vault-capable session continues with the hosted card form, and Direct PayPal
+continues when the session advertises it; Stripe wallets and APMs are omitted.
+The degraded surface exposes one **Retry payment methods** action. It retries
+only provider initialization and never repeats session read/create/claim,
+automatic checkout, intent creation, or payment processing. A failed retry is
+not offered again during that mount, and cards or Direct PayPal remain usable.
+
+When neither the hosted card form nor Direct PayPal can render, `onError` and
+the `error` render prop receive a `FloPayError` with code
+`CheckoutInitializationFailed`. The default error surface uses fixed buyer-safe
+copy. Raw provider messages are never placed in the DOM or merchant callback.
+Existing-session transport and malformed-response failures are separately
+reported at `session_read`; expected session outcomes remain non-alerting.
+
 Direct PayPal script and unusable-namespace failures remain
 `PROVIDER_LOAD_FAILED` at `provider_load`. Once PayPal reports the button as
 eligible, a pre-ready `onError` or rejected `render()` is instead