FloPay Backend Changelog

v1.0.2 - Checkout now runs on the local catalog #

Checkout sessions validate against the platform's own products and coupons and stream that catalog data through to Stripe, removing runtime price lookups.

Checkout now resolves products, prices, and coupons against the local catalog introduced in v1.0.1 instead of looking them up in Stripe at request time. Sessions are validated up-front, pricing is sent inline to Stripe, and every checkout, subscription, and invoice is linked back to the catalog records that produced it.

What changed

• Catalog-validated checkout sessions — POST /checkout/sessions now resolves every submitted product and coupon code against the client's local catalog before a session is created. Unknown, soft-deleted, or non-applicable entries are rejected with a 422 response carrying machine-readable codes (UnknownProduct, DeletedProduct, UnknownCoupon, DeletedCoupon, CouponNotApplicable).
• Inline pricing to Stripe — Stripe subscription and one-off charge calls now send price_data/product_data built from the local catalog, including trial days and price overrides. Stripe no longer needs a pre-existing Price for each checkout item.
• Persistent checkout-to-catalog links — New checkout_product and checkout_coupon records capture which catalog entries were used for each session. Resulting subscription and invoice rows are populated with the corresponding product_id and coupon_id, including from incoming Stripe webhooks.
• Coupon guarantor — Stripe coupons are retrieved-or-created on demand per currency from the local coupon definition, with race handling for concurrent creates.

Why it matters

Merchants get a single source of truth for what they sell. Pricing, trial windows, and discount rules live in the platform catalog and are enforced consistently at checkout, on the resulting Stripe charge, and on the persisted invoice and subscription — which makes reporting, refunds, and reconciliation line up cleanly across the lifecycle.

Developer notes

• Checkout request bodies must reference product and coupon code values that exist (and are not soft-deleted) in the local catalog for the authenticated client. Invalid references now return 422 with a typed error code instead of being passed through to the gateway.