FloPay Backend Changelog

v1.10.26 - A new customer.merged webhook tells merchants when two of their customers were merged #

When two customers are merged, Flopay now sends a customer.merged webhook to each merchant whose customer record changed, with the kept and removed customer ids, so merchants that store Flopay customer ids can update their own records.

Until now, a merchant only learned about a customer merge from the merge response. Merges run by Flopay support or by an agent could leave the customer ids a merchant stores in its own systems out of date. Flopay now sends a customer.merged webhook after every completed merge.

What changed

• A completed merge sends one customer.merged event to each affected merchant.
  • A merge you run for your own account sends the event to you.
  • A merge Flopay support runs across accounts sends it to every merchant that had the removed customer. A merchant that only had the kept customer receives nothing.
• The event names the kept customer as user, and its customer object carries id and targetId (the kept customer), sourceId (the removed customer), keptClientUserId, discardedClientUserId and movedCounts.
• movedCounts always has the keys paymentMethods, subscriptions, payments, invoices and checkoutSessions. Each counts only your own records that moved to the kept customer.
• A merge that is refused, fails, or is only previewed sends nothing. A retried merge or a repeated request with the same Idempotency-Key never sends a second event.
• Webhook deliveries sent before the merge are not re-sent, and their stored payloads are not changed.

Why it matters

• Merchants that keep their own copy of customer ids learn about every merge, whoever ran it, and can update their records.

Developer notes

• customer.merged follows the same endpoint and event selection rules as every other event type. Subscribe an endpoint to customer.merged to receive it.
• Existing event types, fields and payloads are unchanged. This release contains no breaking changes.