@flopay/react 1.9.15 → 1.9.16

package/README.md

@@ -214,12 +214,12 @@ Gateway (TeamFloPay/backend#1563). It processes those payments entirely
 server-side behind the same hosted vault card form, so your checkout code does
 not change and never needs to know which gateway took the card:
 
-- **Opt-in on create.** An inline Full-mode checkout (`createSession`, or a
-  session created with `PaymentAPI.createAndFetchSession` /
-  `createDetachedSession`) declares the `worldpay-corporate-gateway-v1`
-  capability. Auto, Confirm, and pre-tokenized sessions do not, and neither do
-  older SDKs, so their routing is unchanged. See the `@flopay/js` README for the
-  wire contract.
+- **No opt-in.** The billing API decides from the merchant's configured
+  gateways whether a session can use Worldpay (TeamFloPay/backend#1641). The
+  SDK sends no capability token or gateway hint, so routing is the same for
+  every SDK version and create style. Auto, Confirm, and pre-tokenized
+  sessions stay on the released routing because the billing API keeps them
+  there, not because the SDK asks.
 - **Same card surface.** `FloPayCheckout` and `SplitCardForm` mount the hosted
   form with no Stripe runtime and no Worldpay browser SDK or credentials. When
   a session read omitted the embedded vault block, an open session that

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@flopay/react",
-  "version": "1.9.15",
+  "version": "1.9.16",
   "type": "module",
   "sideEffects": false,
   "publishConfig": {
@@ -34,8 +34,8 @@
     "@paypal/paypal-js": "^10.0.0",
     "@stripe/react-stripe-js": "^6.6.0",
     "@stripe/stripe-js": "^9.8.0",
-    "@flopay/js": "1.9.15",
-    "@flopay/shared": "1.9.15"
+    "@flopay/js": "1.9.16",
+    "@flopay/shared": "1.9.16"
   },
   "peerDependencies": {
     "react": ">=18.0.0",