@flopay/react 1.4.10 → 1.4.12
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 +11 -5
- package/dist/index.cjs +8 -8
- package/dist/index.mjs +8 -8
- package/package.json +3 -3
package/README.md
CHANGED
|
@@ -357,11 +357,17 @@ Skip the backend API route — create the session directly in the component:
|
|
|
357
357
|
The component POSTs to the billing API, gets the full session back, and renders the form — zero backend code needed.
|
|
358
358
|
|
|
359
359
|
That create POST sends a stable `Idempotency-Key` header automatically whenever a
|
|
360
|
-
secure RNG is available
|
|
361
|
-
session
|
|
362
|
-
|
|
363
|
-
|
|
364
|
-
|
|
360
|
+
secure RNG is available. `FloPayCheckout` resolves the key once per logical
|
|
361
|
+
checkout, stores it with the inline-session cache in `sessionStorage`, and reuses
|
|
362
|
+
it across transport retries, effect reruns, and component remounts. Concurrent
|
|
363
|
+
mounts (StrictMode double-mount, Suspense remount, or navigation flicker) share
|
|
364
|
+
both the session create and the auto-mode payment attempt, so one purchase cannot
|
|
365
|
+
fan out into multiple creates or charges.
|
|
366
|
+
|
|
367
|
+
Logical checkout identity is based on the merchant, buyer, cart/pricing, and
|
|
368
|
+
coupons. Checkout-mode changes, refreshed payment tokens, and analytics/UTM prop
|
|
369
|
+
churn do not rotate the key while that purchase is active. A different cart or
|
|
370
|
+
buyer gets a different key; an email-less buyer is separated by `account.userId`.
|
|
365
371
|
|
|
366
372
|
To control the key yourself — for example to keep it stable across your own
|
|
367
373
|
server retries — pass `idempotencyKey` on `createSession`:
|