FloPay SDK Changelog

v1.2.0 - Stripe APM (Cashapp, Klarna, Link, and others) enabled at checkout #

SplitCardForm now renders Stripe payment methods directly from the per-session enabledPaymentMethods list, so turning on Cash App Pay, Klarna, Affirm, iDEAL, and other APMs in your Stripe dashboard takes effect without any SDK or app code changes.

FloPay SDK v1.2.0 hands control of which Stripe payment methods appear in SplitCardForm to the session payload. The checkout reads gateways.stripe.enabledPaymentMethods from the session and renders only what the merchant has enabled for that Stripe account, partitioned automatically between the express-checkout button row and a new APM accordion. Enabling a new method in the Stripe dashboard now flows through to live checkouts with no redeploy.

What changed

• SplitCardForm now reads gateways.stripe.enabledPaymentMethods from the checkout session and uses it to drive which methods render. Card entry continues to live in the dedicated split-card fields.
• Express methods (Apple Pay, Google Pay, PayPal, Link, Amazon Pay, Klarna) are placed in the top express-checkout row. Other enabled APMs (Cash App Pay, Affirm, iDEAL, and similar) render in a new accordion PaymentElement region below.
• New showStripe and showPayPal props on SplitCardForm provide gateway-level visibility toggles (both default to true). When a session ships a PayPal gateway, the PayPal renderer is selected automatically: the DirectPayPal SDK when available, otherwise Stripe-rendered PayPal.
• SplitCardForm now emits a validation_error through onError at integration time when both showStripe={false} and PayPal is unavailable, instead of rendering an empty checkout.
• The tokenization payload (TokenizedBody) gains two fields, gateway and paymentMethodType, so backends can route the resulting /v1/checkouts/sessions/process call by gateway and method. isPaypal is still populated for PayPal flows during the deprecation window.

Why it matters

• Merchants can light up new Stripe payment methods directly from the Stripe dashboard and have them appear in checkout without an SDK upgrade or app release.
• Integrators get a single, predictable layout: express buttons on top, additional APMs in an accordion, card entry in the split fields — driven entirely by the session payload.
• Misconfigurations that previously produced an empty checkout surface are now caught early through a clear validation error.

Developer notes

• Ensure your billing session response populates gateways.stripe.enabledPaymentMethods with the methods you want exposed (for example ["card", "apple_pay", "google_pay", "klarna", "cashapp"]). Methods omitted from this list will not render.
• The showApplePay and showGooglePay props on SplitCardForm are deprecated in favor of session-driven visibility. They still work for now but will be removed in a future minor; prefer driving visibility through enabledPaymentMethods and the new showStripe / showPayPal props.
• If your backend inspects the tokenization payload, you can now switch on the new gateway and paymentMethodType fields on TokenizedBody instead of relying on the isPaypal boolean. isPaypal remains set for PayPal during the deprecation window so existing integrations keep working.
• When toggling showStripe={false}, make sure a PayPal gateway is configured for the session, otherwise SplitCardForm will surface a validation_error through onError rather than rendering.