@flopay/react 1.9.0 → 1.9.2
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 +8 -0
- package/dist/index.cjs +9 -9
- package/dist/index.mjs +8 -8
- package/package.json +3 -3
package/README.md
CHANGED
|
@@ -978,6 +978,14 @@ Stripe and PayPal SDK load/runtime failures emit `provider_runtime`. Inline
|
|
|
978
978
|
`validation_rejected` / `payment_declined` outcomes and never carry
|
|
979
979
|
`failureCategory`.
|
|
980
980
|
|
|
981
|
+
Direct PayPal script and unusable-namespace failures remain
|
|
982
|
+
`PROVIDER_LOAD_FAILED` at `provider_load`. Once PayPal reports the button as
|
|
983
|
+
eligible, a pre-ready `onError` or rejected `render()` is instead
|
|
984
|
+
`PROVIDER_RUNTIME_FAILED` at `provider_ready`. These bounded groups contain no
|
|
985
|
+
provider message or stack. Ineligibility, superseded renders, and recognized
|
|
986
|
+
PayPal teardown remain non-alerting; only true load failures project to the
|
|
987
|
+
merchant instrument feed as `checkout_error` / `sdk_load`.
|
|
988
|
+
|
|
981
989
|
The same classification applies to React-owned saved-payment processing in
|
|
982
990
|
`auto` and `confirm` modes. An ordinary saved-payment `400` decline, a
|
|
983
991
|
structured-field `400`, or a `422` still falls back to the usable full checkout
|