FloPay Backend Changelog

Client-facing updates for FloPay backend and API releases.

v1.0.3 - Traceable Stripe objects with flo_* metadata #

Stripe customers, subscriptions, payments, products, and coupons now carry flo_* identifiers so dashboard and webhook events trace back to platform records without extra lookups.

16 May 2026

Improvement
Stripe
Webhooks
Observability

Every Stripe object the platform creates or updates is now stamped with a consistent set of flo_* metadata keys. Support staff inspecting Stripe in the dashboard, and webhook consumers reacting to events, can map each Stripe record back to its originating client, user, checkout session, subscription, product, coupon, or invoice without an additional API call or database lookup.

What changed

  • Standardized metadata keys — Stripe Customer, Subscription, PaymentIntent, SetupIntent, Product, and Coupon create/update calls now include flo_client, flo_user, flo_checkout_session, flo_subscription, flo_product, flo_coupon, and flo_invoice whenever the corresponding identifier is known. Keys are omitted entirely when no value applies, so metadata payloads remain clean.
  • Single-source subscription tagging — Subscriptions are tagged with flo_product only for single-product subscriptions and with flo_coupon only when exactly one coupon is applied, keeping the metadata unambiguous for dashboard filtering and downstream reporting.
  • Webhook resolution improvements — Stripe webhook handlers (payment_intent.succeeded, payment_intent.payment_failed, and the outbox/persistence pipeline) now prefer the canonical flo_checkout_session, flo_product, and flo_coupon keys when reconciling events to platform records, with a fallback to the previous checkoutSessionId / initialCheckoutSessionId keys for objects created before this release.

Why it matters

Operators and developers can now jump directly from any Stripe object — in the dashboard, in a webhook payload, or in an exported report — to the matching platform entity. This shortens incident triage, simplifies reconciliation, and reduces the number of round-trip lookups required to answer "which Flo record produced this Stripe object?"

Developer notes

  • No action is required for objects created before this release. Webhook handlers transparently fall back to the legacy metadata keys, so historical Stripe records continue to resolve correctly.
  • New Stripe objects created after upgrading will carry the flo_* keys going forward. Custom integrations that read Stripe metadata can begin relying on the canonical key names immediately.