@flopay/react 1.4.18 → 1.4.20

package/README.md

@@ -356,6 +356,41 @@ Skip the backend API route — create the session directly in the component:
 
 The component POSTs to the billing API, gets the full session back, and renders the form — zero backend code needed.
 
+#### Authorisation-only checkout
+
+Set `captureMethod: 'manual'` in the same `createSession` draft for an eligible
+item-only card checkout:
+
+```tsx
+<FloPayCheckout
+  createSession={{
+    clientId: 'your-client-id',
+    captureMethod: 'manual',
+    currency: 'EUR',
+    items: [{ code: 'order_123', totalAmount: 29.99 }],
+    account: { userId: 'user_1', email: 'user@example.com' },
+    successUrl: '/success',
+    cancelUrl: '/cancel',
+  }}
+  onComplete={(result) => {
+    if (result.status === 'authorized') {
+      saveAuthorisation({
+        paymentId: result.paymentId,
+        sessionId: result.sessionId,
+        expiresAt: result.authorizationExpiresAt,
+      });
+    }
+  }}
+  onSessionCompleted={(successUrl) => router.push(successUrl)}
+/>
+```
+
+The component still releases the buyer to the success experience, but its
+overlay says `PAYMENT AUTHORISED`. `authorized` means funds are held, not paid.
+Capture remains a merchant-authenticated REST operation and is never available
+to browser code. Manual capture is rejected for subscription carts. See the
+repository's [pre-authorisation guide](../../docs/PREAUTHORIZATION.md).
+
 That create POST sends a stable `Idempotency-Key` header automatically whenever a
 secure RNG is available. `FloPayCheckout` resolves the key once per logical
 checkout, stores it with the inline-session cache in `sessionStorage`, and reuses
@@ -785,6 +820,16 @@ Stripe and PayPal SDK load/runtime failures emit `provider_runtime`. Inline
 `validation_rejected` / `payment_declined` outcomes and never carry
 `failureCategory`.
 
+The same classification applies to React-owned saved-payment processing in
+`auto` and `confirm` modes. An ordinary saved-payment `400` decline, a
+structured-field `400`, or a `422` still falls back to the usable full checkout
+and emits `operation.fallback`, but reports only the matching
+`payment_declined` or `validation_rejected` outcome. Genuine server,
+transport, malformed-response, and provider-runtime failures remain
+categorized technical errors. This does not change fallback rendering or
+merchant callback behavior, and no response body, provider payload, session
+value, payment data, or raw error message is added to telemetry.
+
 ### SplitCardFormProps
 
 Key payment-surface props include: