@flopay/react 1.13.0 → 1.13.1

package/README.md

@@ -121,6 +121,7 @@ The payment-method list is gateway-driven: the billing API sends `gateways.strip
 
 - `showStripe` (default `true`) toggles Stripe wallets and alternative methods; `showPayPal` (default `true`) toggles PayPal. Turning both off with no PayPal gateway is reported through `onError` as a `validation_error` instead of rendering an empty form.
 - In `layout="buttons"`, **Credit / Debit Card** opens the inline card form. Cancelling a wallet or PayPal silently returns to the chooser. A technical failure after the click (including popup blocking, or a provider closing without a result) restores the chooser, focuses a retry control for that method, shows safe method-specific copy such as `We couldn't open Google Pay. Try again or choose another payment method.`, and calls `onError` with a `FloPayError`. A method that is unavailable before the click just disappears.
+- **Small desktop windows.** Desktop Chrome refuses to open the Google Pay sheet when the browser window cannot fit it (about 680 by 640 CSS pixels of content; a docked DevTools pane counts) and reports only a cancel. In such a window the SDK denies the Payment Request API to the frames Stripe creates, so Google Pay opens in Google's own window, as it does on mobile and in Safari or Firefox. The choice is made when the wallet row mounts and re-evaluated on resize while no wallet attempt or payment is in flight. Should Chrome still refuse a sheet, `onError` receives `external_payment_method_failed` with `details.providerCode` `wallet_sheet_window_too_small` and the buyer is asked to enlarge the window or choose another method.
 - Wallet confirmation has one 25-second SDK budget inside the provider's 30-second callback deadline. If a wallet omits required buyer identity, the authorization is failed promptly, the SDK collects the missing email, and the buyer reopens the wallet to continue.
 - **Confirmation recovery.** Google Pay and Apple Pay authentication can outlive the SDK's observation window. The SDK never cancels that provider promise: it reads the original intent's status and settles once. A successful intent continues to payment exactly once; a cancelled or failed intent offers a wallet retry; an intent still needing action, or a status that cannot be read, keeps payment locked and offers only **Check payment status**. A retry after a lost intent-create response reuses the same authorization attempt id, so no second intent can be created.
 - `showApplePay` and `showGooglePay` are deprecated: wallet availability comes from the session's `enabledPaymentMethods`, and supplying them alongside it emits a one-time `console.warn`. Direct PayPal is resolved from `gateways.paypal`; the `SplitCardForm` `directPaypal` prop remains only for wiring PayPal manually.
@@ -737,6 +738,16 @@ and optional `presentationMode`. `providerCode` is sanitized and falls back to
 `external_payment_method_failed`; raw provider messages, URLs, user agents,
 credentials, payment identifiers, and customer data are never exposed.
 
+One `providerCode` is the SDK's own: `wallet_sheet_window_too_small`. Desktop
+Chrome refuses to open the Google Pay sheet when the browser window cannot fit
+it (roughly less than 680 by 640 CSS pixels of content, so a docked DevTools
+pane counts) and reports that to the page as a plain cancel. When a Google Pay
+click on desktop Chromium is cancelled within 1.5 seconds without the page ever
+losing focus in such a viewport, the SDK reports it through `onError` with this
+`providerCode` and tells the buyer to make the window larger or choose another
+method, instead of silently redrawing the wallet buttons. A buyer who dismisses
+a sheet that did open still gets the silent reset.
+
 A `validation_error` is also reported when both `showStripe` and `showPayPal` are false with no PayPal gateway, or when a session advertises no supported gateway. When saving the AVS billing address is rejected with a `4xx`, `onError` receives the parsed billing API error while the message shows inline; the buyer corrects it for the next attempt.
 
 `FloPayCardSetup` reports failures to `onError` as `FloPayCardSetupError`, which adds `retryable`. Network, rate-limit, `5xx`, card-form timeout, and unexpected failures are retryable; validation failures are not.