@flopay/react 1.9.11 → 1.9.13

package/README.md

@@ -80,6 +80,29 @@ whitespace normalization, so an authorised wallet name can replace it. Name
 selection is atomic: first and last name always come from one source, and are
 omitted when neither source is usable. Email precedence is unchanged.
 
+#### Wallet confirmation recovery
+
+Google Pay and Apple Pay authentication may legitimately outlive the SDK's
+provider observation threshold. The SDK does not cancel that provider promise.
+Instead, it retrieves the original PaymentIntent or SetupIntent with the same
+client secret and routes the provider promise and status read through one
+settlement gate:
+
+- an authoritative success continues to `/process` exactly once;
+- `canceled` or `requires_payment_method` is treated as authoritative,
+  non-chargeable terminal evidence and exposes wallet retry;
+- `requires_action`, an unavailable/mismatched status, or a failed/bounded-out
+  status read keeps payment submission locked and exposes only **Check payment
+  status**.
+
+Rejected confirmations, returned technical errors, and malformed fulfilled
+results use this same recovery contract. A lost intent-create response also
+reuses the authorization-attempt UUID on deliberate retry, so provider
+idempotency cannot mint a second intent. A bounded pending-confirmation handoff
+keeps teardown/remount from exposing another wallet surface while the first
+intent may still complete. Existing component props and merchant callbacks are
+unchanged.
+
 #### Merchant instrument feed
 
 Use `onInstrument` on `FloPayCheckout` or `FloPayProvider` to forward a stable,