@flopay/react 1.4.14 → 1.4.17

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
package/README.md CHANGED
@@ -393,6 +393,41 @@ Session-level `currency` is now **required**. The backend (#760) enforces `@IsNo
393
393
 
394
394
  When you use `onBeforeButtonClick` with `createSession`, any returned `InlineSessionPatch` is merged into the draft session params before the selected buttons-layout flow continues. That lets you add tracking data or update account fields just in time without pre-creating a separate backend session.
395
395
 
396
+ ### Detached session creation (default)
397
+
398
+ `createSession` checkouts are created in two phases (TeamFloPay/backend#1099):
399
+ a lightweight session *shell* that skips catalog validation and the
400
+ buyer-identity advisory locks, then a background **claim** that attaches buyer
401
+ identity, address, products and coupons.
402
+
403
+ `FloPayCheckout` renders from the shell, so the hosted card form mounts and
404
+ becomes interactive without waiting for either the claim or Stripe.js — Stripe
405
+ wallets, APMs and PayPal load in parallel with the claim and appear when it
406
+ lands. The card widget's submit button stays gated for that window, because the
407
+ billing API rejects a charge against an unclaimed session; if a buyer clicks
408
+ during it, the widget cancels the click and the form asks them to press pay
409
+ again. In practice the claim resolves while the card is still being filled in.
410
+
411
+ Nothing else changes for you: the same session, the same callbacks, the same
412
+ results. Catalog and coupon errors still surface as a checkout load error, just
413
+ from the claim rather than the create.
414
+
415
+ Opt out per session to restore the original single-request create:
416
+
417
+ ```tsx
418
+ <FloPayCheckout
419
+ createSession={{
420
+ /* … */
421
+ deferDataAttachment: false, // one-shot create
422
+ }}
423
+ />
424
+ ```
425
+
426
+ Detached creation applies only to `checkoutMode: 'full'` (the billing API
427
+ rejects it for `auto` / `confirm`) and is skipped when `tokenizedData` is
428
+ supplied. There is **no fallback** to the one-shot create — it requires a
429
+ billing API that exposes `PATCH /v1/checkouts/sessions/{id}/claim`.
430
+
396
431
  ### Advanced: Manual Provider Setup
397
432
 
398
433
  Use `SplitCardForm` when you need to compose the provider and session yourself.
@@ -547,8 +582,17 @@ session embeds session.vault or advertises gateways.stripe.enabledPaymentMethods
547
582
  are charged by the backend's auto-checkout cascade.
548
583
  - **3DS** is handled inside the widget — there is no client-side `confirmCardPayment`.
549
584
 
550
- **Failure modes:** the widget renders its own status / decline UI; `onDecline` /
551
- `onError` receive the mapped reason + message so consumers can react.
585
+ **Processing feedback:** after the hosted widget emits `submitting`, the SDK's
586
+ full-checkout processing overlay remains visible continuously until the widget
587
+ reports `complete`, `decline`, or `error`. Intermediate status polling and
588
+ late card-field validation mutations cannot expose the completed form while a
589
+ charge is still in flight. A synchronous card-validation rejection still
590
+ returns the buyer to the form immediately, as does a `4xx` account-snapshot
591
+ validation failure.
592
+
593
+ **Failure modes:** `onDecline` / `onError` receive the mapped reason + message
594
+ so consumers can react, and the SDK leaves an inline retry message after its
595
+ terminal failure overlay clears.
552
596
 
553
597
  > **Backend dependencies:** the hosted widget must emit the `flopay-vault`
554
598
  > `postMessage` outcome the SDK listens for (otherwise it falls back to its own
@@ -655,7 +699,7 @@ import { useFloPay, useElements, useCheckout } from '@flopay/react';
655
699
  function PaymentStatus() {
656
700
  const flopay = useFloPay(); // FloPay | null
657
701
  const elements = useElements(); // FloPayElements | null
658
- const checkout = useCheckout(); // { session, loading, error }
702
+ const checkout = useCheckout(); // { session, loading, error, claimPending }
659
703
 
660
704
  if (!flopay) return <div>Loading SDK...</div>;
661
705
  // ...
@@ -683,7 +727,7 @@ function PaymentStatus() {
683
727
  |------|---------|-------------|
684
728
  | `useFloPay()` | `FloPay \| null` | Current FloPay instance from context. `null` while loading. |
685
729
  | `useElements()` | `FloPayElements \| null` | Current elements group from context. `null` while loading. |
686
- | `useCheckout()` | `CheckoutState` | `{ session, loading, error }` from CheckoutContext |
730
+ | `useCheckout()` | `CheckoutState` | `{ session, loading, error, claimPending }` from CheckoutContext. `claimPending` remains true while a detached shell is not safe to charge. |
687
731
 
688
732
  ### FloPayProviderProps
689
733
 
@@ -785,4 +829,4 @@ endpoint when a buyer enters the card path.
785
829
  | `SplitCardFormProps` | Props for `SplitCardForm` |
786
830
  | `PayPalButtonProps` | Props for `PayPalButton` |
787
831
  | `ElementComponentProps` | Shared props for all element components |
788
- | `CheckoutState` | `{ session, loading, error }` |
832
+ | `CheckoutState` | `{ session, loading, error, claimPending }` |