FloPay Backend Changelog

v1.7.20 - Subscription rebill filters for payments and webhooks #

Payment and webhook-event lists, exports, and batch resends can now use a linked subscription's successful rebill count.

Payment and webhook-delivery reporting can now organize records by the number of successful renewal charges recorded for each linked subscription. Merchants and operators can isolate activity for subscriptions that have not yet renewed, compare more established subscriptions, and target webhook redelivery without combining separate datasets.

What changed

• GET /v1/payments, GET /v1/admin/payments, GET /v1/webhooks/events, and GET /v1/admin/webhooks/events now accept numeric subscription.rebillCount filters, such as subscription.rebillCount[gte]=2, using eq, gt, gte, lt, and lte operators.
• Payment and webhook-event results can be ordered with sort[asc]=subscription.rebillCount or sort[desc]=subscription.rebillCount. Records without a linked subscription are placed last, and equal rebill counts retain stable pagination.
• POST /v1/payments/exports, POST /v1/admin/payments/exports, POST /v1/webhooks/events/exports, and POST /v1/admin/webhooks/events/exports support the same filters and sorting, and can include subscription.rebillCount as an opt-in numeric field in CSV or JSON output.
• POST /v1/webhooks/events/resend accepts the same rebill-count filters, allowing a batch resend to target webhook events linked to subscriptions within a selected renewal range.

Why it matters

• Payment and webhook-delivery reports can segment activity by subscription maturity without matching records across separate exports.
• Support and operations teams can focus webhook redelivery on a relevant subscription cohort while retaining the existing client-scoped resend behavior.

Developer notes

• Add relation=subscription only when the nested subscription data is needed in a list response. Filtering or sorting by subscription.rebillCount does not expand the relation automatically.
• The export field is opt-in and does not change the default payment or webhook-event export schema.
• This change is additive. Existing response fields, pagination envelopes, default ordering, relation loading, webhook payloads, and automatic delivery behavior are unchanged; no SDK update, merchant configuration, or data migration is required.