FloPay SDK Changelog

Client-facing updates for FloPay SDK releases.

v1.8.10 - Reliable automatic checkout success and PayPal routing #

Flopay SDK 1.8.10 keeps a completed automatic checkout reported as successful even when a merchant callback throws, and lets the session's own PayPal advertisement decide the direct PayPal channel.

26 Aug 2026

Bug Fix
Checkout
React SDK
PayPal

Flopay SDK v1.8.10 fixes two ways a checkout could take the wrong path after the backend had already decided the outcome. A wallet payment that succeeded no longer shows as a failure because merchant code threw while handling it, and direct PayPal now follows the channel the session itself advertises.

What changed

  • FloPayAutomaticPaymentButton runs the merchant onSuccess callback through the SDK's isolated invoker. A callback that throws — or returns a rejecting promise — is logged to the merchant's console and the checkout stays successful, instead of being reclassified as a payment failure.
  • The automatic button recognises the synchronous auto-completed sentinel structurally, by its code, rather than by instanceof FloPayError. A page that loads more than one copy of the SDK runtime no longer loses the already-completed session and reports it as an error.
  • DirectPayPalButton and SplitCardForm treat the session's gateways.paypal.providerObjectType as the authoritative source for the PayPal channel. An advertised order or setup_token now selects the Flo-owned paypal_vaulted requests even when the integration never forwarded the providerObjectType prop.
  • SplitCardForm custom layouts fall back to the session on the checkout context, so a merchant-composed layout that does not pass session directly still routes and retries against the advertised PayPal object.
  • Stripe-hosted PayPal is unchanged, and a legacy session that advertises nothing keeps sending the released paypal requests byte-identically.

Why it matters

Google Pay and the other automatic wallets could complete in the backend and still surface an error to the buyer, purely because the merchant's own success handler threw. Direct PayPal could meanwhile fall back to the legacy channel on a current session, despite the backend having routed the checkout to a Flo-owned Order or Setup Token.

Developer notes

  • Upgrade the @flopay/* packages you use to 1.8.10 together.
  • The providerObjectType prop on DirectPayPalButton and on SplitCardForm's directPaypal config is deprecated. Forward the session instead; the prop still works as a fallback for integrations that do not.
  • Merchant onSuccess failures now reach the browser console as [FloPay] Merchant callback failed; checkout continued. and are not sent as Flo telemetry. Handle your own errors inside the callback if you need them reported.
  • Existing integrations require no migration.