FloPay SDK Changelog

v1.2.6 - Optional product type for a simpler products payload #

CheckoutProduct.type is now optional and deprecated — the backend resolves item vs subscription from the catalog code, so you can build a products[] payload with just code and quantity. Display caching now keys on code alone.

FloPay SDK v1.2.6 simplifies the products payload by making CheckoutProduct.type optional. The billing API resolves whether an entry is a one-time item or a recurring subscription from the catalog code, so consumers no longer need to classify products themselves when creating a session. Existing integrations that still pass type keep working unchanged.

What changed

• CheckoutProduct.type is now optional and deprecated. You can build a products[] entry with just code (and quantity); the backend resolves item-vs-subscription from the catalog code. type is still accepted, and when supplied it refines the client-side optimistic display rendered before the session response loads (subscriptions are listed first).
• Display-cache merging in PaymentAPI now keys products on code alone (code:{code}) rather than the previous type:code composite. Cached display data merges back correctly even when the create-side payload omitted type.
• buildSyntheticSession defaults a product's type to 'item' when it is omitted, so synthetic session previews remain stable.

Why it matters

• Building a checkout session is simpler: a product is identified by its catalog code, removing a redundant field consumers previously had to set correctly.
• The catalog code is now the single product identity used for display merging, so optimistic rendering and the session response reconcile reliably regardless of whether type was provided.

Developer notes

• Upgrade @flopay/js, @flopay/react, @flopay/node, and @flopay/shared together to 1.2.6.
• No code change is required for integrations that still pass type on products[] — the field remains supported during the deprecation window.
• New integrations can omit type and pass code (plus quantity) only. Optionally pass type if you want subscriptions ordered first in the pre-response optimistic display.
• No request/response shapes returned by the billing API have changed.