@flopay/react 1.4.16 → 1.4.18

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.
@@ -664,7 +699,7 @@ import { useFloPay, useElements, useCheckout } from '@flopay/react';
664
699
  function PaymentStatus() {
665
700
  const flopay = useFloPay(); // FloPay | null
666
701
  const elements = useElements(); // FloPayElements | null
667
- const checkout = useCheckout(); // { session, loading, error }
702
+ const checkout = useCheckout(); // { session, loading, error, claimPending }
668
703
 
669
704
  if (!flopay) return <div>Loading SDK...</div>;
670
705
  // ...
@@ -692,7 +727,7 @@ function PaymentStatus() {
692
727
  |------|---------|-------------|
693
728
  | `useFloPay()` | `FloPay \| null` | Current FloPay instance from context. `null` while loading. |
694
729
  | `useElements()` | `FloPayElements \| null` | Current elements group from context. `null` while loading. |
695
- | `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. |
696
731
 
697
732
  ### FloPayProviderProps
698
733
 
@@ -724,6 +759,24 @@ No endpoint, custom tag, user context, message, stack, or metadata can be
724
759
  configured. See [`docs/TELEMETRY.md`](../../docs/TELEMETRY.md) for the complete
725
760
  privacy and retention contract.
726
761
 
762
+ If the React host has its own Sentry client, use the re-exported pure filter as
763
+ the host's `beforeSend` callback:
764
+
765
+ ```ts
766
+ import * as Sentry from '@sentry/browser';
767
+ import { dropThirdPartyOnlyError } from '@flopay/react';
768
+
769
+ Sentry.init({ beforeSend: dropThirdPartyOnlyError });
770
+ ```
771
+
772
+ No Sentry package or configuration is bundled by FloPay. The predicate drops
773
+ only complete exception stacks with no app or `@flopay/*` frame and at least
774
+ one recognised browser-extension URL or Stripe `dahlia/stripe.js` path/module
775
+ marker. Anonymous frames may accompany that marker. Mixed, unrelated,
776
+ incomplete, and anonymous-only errors pass through unchanged. The `in_app`
777
+ flag is ignored because host rewriting may set it to `true` on third-party
778
+ frames.
779
+
727
780
  Inline session creation classifies bounded failures without inspecting raw
728
781
  errors: network/CORS/timeouts emit `transport_error`, 5xx responses emit
729
782
  `server_error`, and malformed response discriminants emit `invalid_response`.
@@ -794,4 +847,4 @@ endpoint when a buyer enters the card path.
794
847
  | `SplitCardFormProps` | Props for `SplitCardForm` |
795
848
  | `PayPalButtonProps` | Props for `PayPalButton` |
796
849
  | `ElementComponentProps` | Shared props for all element components |
797
- | `CheckoutState` | `{ session, loading, error }` |
850
+ | `CheckoutState` | `{ session, loading, error, claimPending }` |