An Apple Pay or Google Pay wallet saved without a purchase now keeps its card brand, last four digits and expiry, so customers can tell their saved methods apart on the hosted manage page and merchants get the same card details from the payment methods API.
A wallet a customer saved without a purchase, for example on the hosted manage page, was listed only as "Apple Pay" or "Google Pay". It is now saved with the card behind it.
What changed
- When an Apple Pay or Google Pay setup completes, the card brand, last four digits and expiry month and year of the card behind the wallet are saved with it.
- The hosted manage page lists such a wallet as, for example,
Apple Pay · Visa •••• 4242.
GET /v1/payment-methods returns brand, lastFour, expiryMonth and expiryYear for these wallets, as it already does for cards.
Why it matters
Customers with more than one saved wallet, or a wallet and a card, can tell them apart when they choose a default or remove one.
Developer notes
- No response shape changes: the fields already exist and were
null for these wallets.
- The card details are read with the setup itself, on the account the setup ran on. If they are not available, the wallet is saved and the setup completes exactly as before, without them.
- Wallets saved before this release keep empty card fields; there is no backfill.
- Bank debit and card setup are unchanged. No migration.
- This release contains no breaking changes.
Customers on the hosted manage page can now see, add, remove and choose as their default a saved Apple Pay or Google Pay wallet or a PayPal account, as well as cards. Subscriptions the chosen method can pay move onto it, and the manage page webhooks carry the method's real type. PayPal can now be saved on a no-purchase setup session.
The hosted manage page could list a saved PayPal account but not change it, and did not show wallets saved for later use at all. Customers who pay with Apple Pay, Google Pay or PayPal can now manage those methods on the same page as their cards.
What changed
- The manage page lists cards, PayPal accounts and the Apple Pay and Google Pay wallets saved for later use. Every row has a method type, a readable label such as
Apple Pay or PayPal (a•••@example.com), and a real default marker.
- Customers can remove a wallet or a PayPal account. A PayPal account that a subscription still depends on stays, with the existing payer-action code.
- Customers can make a wallet or a PayPal account their default. The active subscriptions it can pay move onto it, and the rest are reported with the existing reasons. Renewals and retries try the default first, whatever its type.
- A setup started from the manage page carries the currency of the customer's subscriptions (or else the merchant's default currency), so Apple Pay and Google Pay can be offered. A wallet or PayPal saved there becomes the default, and the setup result now names its method type.
- PayPal can be saved on a no-purchase setup session: the vault setup token is created on the PayPal account the session offered.
- The "used for" list on the manage page now includes subscriptions paid by a saved wallet or PayPal account.
payment_method.added, payment_method.removed and payment_method.default_changed webhooks carry the real type (card or paypal) and a new methodType field.
Why it matters
Customers who chose a wallet or PayPal can keep their payment details up to date without contacting the merchant, and merchants learn exactly which kind of method changed.
Developer notes
- All changes are additive. Existing fields keep their meaning;
readOnly stays on manage rows and is now always false.
- Webhook consumers that only expected
type: "card" may now also see type: "paypal"; the new methodType names the wallet.
- One additive migration adds a nullable
checkout_session_id column and index to user_non_card_payment_method.
- Merchant payment method endpoints are unchanged.
- This release contains no breaking changes.
When the hosted card setup form does not ask for a card security code, the expiry year box now has its own right border and rounded corners. Before, the row looked cut off, as if the security code field had been pushed out of view.
The hosted card setup form leaves out the card security code when it saves a card for later use. Its layout still assumed a security code box sat beside the expiry year, so the year box had no right edge and the row looked cut off.
What changed
- When the form leaves out the security code, the expiry year box now closes the row with its own right border and rounded corners, and turns red like the other fields when the expiry is invalid.
- Payment forms, which still ask for the security code, look exactly as before.
Developer notes
- Styling only. No API, webhook or SDK change, and no integration change is needed.
- This release contains no breaking changes.
When an alert network's references do not match a Flopay payment, Flopay now finds the payment by the card's last four digits, the amount and the transaction date, and confirms it with the authorization code where it can. Linked alerts carry the payment and customer in their webhooks. Ambiguous alerts stay unlinked. No integration change is needed.
19 Oct 2026
Improvement
Webhooks
Disputes
Most pre-dispute alerts from alert networks arrived unlinked, with an empty paymentIds, because the references the network sends (such as the acquirer reference number) are not ones Flopay records for a payment. Merchants then had to find the order themselves inside the short response window.
What changed
- When an alert's references match no payment, Flopay searches the merchant's captured payments, refunded ones included, for the alert amount and currency (or the network's converted amount), made around the transaction date by a customer with a saved card ending in the alert's last four digits.
- When the alert carries an authorization code and the payment ran on Stripe, Flopay confirms the payment against the authorization code Stripe recorded for it.
- Flopay links only when exactly one payment remains. When several could match, the alert stays unlinked rather than guess.
- An alert delivered unlinked earlier is linked when the alert network sends it again or updates it: a
pre_dispute_alert.updated event carries the same preDisputeAlert.id with paymentIds, linkStatus: "linked" and user.
- Once linked, an alert stays linked when a later notification matches nothing.
Why it matters
- More alerts arrive already tied to the payment and customer, so merchants can refund or respond inside the alert window without searching for the order.
Developer notes
- The webhook payload shape is unchanged. Treat
paymentIds and user on pre_dispute_alert.updated as you already do.
- This release contains no breaking changes.
Pre-dispute alert webhooks now carry the transaction date, card brand, card issuer country and the alert network's converted amount when they are known, so merchants can find the payment an alert is about even before Flopay links it. The new fields are optional and nullable. Existing fields and integrations are unchanged.
19 Oct 2026
Improvement
Webhooks
Disputes
A pre-dispute alert is delivered as soon as Flopay can attribute it to a merchant, often before it is linked to a Flopay payment. Until now the alert told the merchant the amount, currency, card digits and descriptor, but not when the payment was made or which card network it ran on, which made the order harder to find inside the short response window.
What changed
pre_dispute_alert.created and pre_dispute_alert.updated carry five new fields on preDisputeAlert: transactionAt, cardBrand, cardCountry, convertedAmount and convertedCurrency.transactionAt is when the card transaction took place. Alert networks usually report only the date, which is delivered as midnight UTC. When the network gives no date, it comes from the acquirer reference number's processing date, which is the transaction date or the day after it.cardBrand is the lower-case card network, such as visa or mastercard, and cardCountry is the two-letter country of the card issuer.convertedAmount and convertedCurrency are the alert amount as converted by the alert network, when it supplied a conversion. They are always present or null together.- Stripe inquiries and early fraud warnings fill
transactionAt, cardBrand and cardCountry from the charge.
Why it matters
- Merchants can locate the payment an alert is about, by date and card, while the alert is still unlinked.
Developer notes
- Every new field is optional and nullable. Alerts first delivered before this release report them as
null.
- The fields are descriptive: learning them for an alert already delivered does not send a new
pre_dispute_alert.updated event.
- Card BIN is still never part of the payload.
- This release contains no breaking changes.
Three new webhook events, payment_method.added, payment_method.removed and payment_method.default_changed, tell a merchant's systems when a customer changes their saved cards on the Flopay hosted manage page. Endpoints receive them only when subscribed. Existing events and integrations are unchanged.
18 Oct 2026
Improvement
Webhooks
Customers
A customer signed in to the Flopay hosted manage page can add a card, remove a card and choose their default card. Until now a merchant's systems were not told about these changes, so their records could drift from what the customer did. Flopay now sends a webhook for each change.
What changed
payment_method.added is sent once when a card the customer added or replaced on the page has been saved.payment_method.removed is sent once when the customer removes a card on the page. A repeated or refused removal sends nothing.payment_method.default_changed is sent once when a card becomes the customer's default on the page, including a card added there that becomes the default automatically. It names the previous default card, the subscriptions that moved to the new default, and the subscriptions that stayed where they were with the reason. Choosing the card that is already the default, or a change that could not be made, sends nothing.- A replaced card is reported as two events: the new card added and, when the customer removes it, the old card removed.
Why it matters
- A merchant's records of a customer's cards and default card stay in step with what the customer did on the hosted page.
Developer notes
- Add
payment_method.added, payment_method.removed or payment_method.default_changed to the events of a webhook endpoint through POST /v1/webhooks or PATCH /v1/webhooks/{id} to receive them. Existing endpoints are not subscribed automatically.
- Payloads have
objectType: "payment_method" and a paymentMethod object with the payment method id, client id, type and when the change happened. They never contain card numbers, expiry dates or other card details.
- Cards added, removed or changed through a merchant's own integration do not send these events.
- This release contains no breaking changes.
A customer signed in to the Flopay hosted manage page now sees their saved PayPal account in their list of payment methods, marked as view only, next to their cards. Merchant payment method endpoints are unchanged.
Until now, the hosted manage page listed only a customer's saved cards, so a customer who pays with PayPal could not see that account there. Flopay now shows it, clearly marked as view only.
What changed
- A signed-in customer's saved PayPal account with that merchant appears in their list of payment methods, with a masked account email, next to their cards.
- The PayPal account is view only: it cannot be removed, replaced or made the default from the page, and the page is told why.
- Cards in the list look and behave exactly as before.
- Other wallets are still not shown, and other customers' or other merchants' PayPal accounts are never shown.
Why it matters
- Customers see every saved method they pay with, instead of wondering where their PayPal account went.
Developer notes
- Merchant payment method endpoints and their responses are unchanged.
- This release contains no breaking changes.
A customer signed in to the Flopay hosted manage page can now make one of their saved cards the default, and their subscriptions with that merchant move onto it. A card added or replaced from the page becomes the default automatically. Merchant payment method and setup session endpoints are unchanged.
18 Oct 2026
Improvement
Customers
Subscriptions
Until now, a customer could add, replace or remove cards on the hosted manage page, but could not choose which card their subscriptions use. Flopay now lets the customer choose a default card.
What changed
- A signed-in customer can make any of their active cards with that merchant the default. It becomes their only default card with that merchant, and the card list shows which card it is.
- Their active subscriptions with that merchant move to the default card, as long as the card can pay for them.
- Renewals try the default card first. If it cannot be charged, they fall back to the cards the customer already has on file, in the same order as before. Customers who never choose a default card are renewed exactly as before.
- Subscriptions the card cannot pay for stay on their current payment method, and the customer is told how many and why. This covers subscriptions paid through PayPal and subscriptions billed through a payment gateway where the card is not saved.
- A card the customer adds or replaces on the page becomes the default automatically, and the page shows how many subscriptions moved. The customer can choose another default at any time.
- If a subscription cannot be moved, nothing changes: the previous default card stays the default, every subscription stays where it was, and the customer can try again.
- Cancelled, expired and failed subscriptions, subscriptions with other merchants and other customers' cards are never changed.
Why it matters
- A customer who adds a new card can move their subscriptions off a card they mean to stop using, without contacting the merchant.
Developer notes
- Merchant payment method endpoints, setup session creation and cards saved through a merchant's own integration behave exactly as before. No new field appears in merchant responses.
- This release contains no breaking changes.
A customer signed in to the Flopay hosted manage page can now see, for each of their saved cards, the active subscriptions it pays for with the plan name and next renewal date. Merchant subscription and payment method endpoints are unchanged.
18 Oct 2026
Improvement
Customers
Subscriptions
Until now, a customer looking at their saved cards on the hosted manage page could not tell which subscriptions each card was paying for, so changing or removing a card meant guessing. Flopay now gives the hosted manage page a read of what each card pays for.
What changed
- A signed-in customer can see their active subscriptions with that merchant, each with the saved card paying for it, the plan name and the next renewal date.
- Only subscriptions that are still billed are shown. Cancelled, expired and failed subscriptions, and subscriptions with other merchants, are not.
- A subscription paused with a resume date shows that date as its next renewal. A subscription set to cancel before it would renew shows no next renewal date.
- A card that pays for nothing shows no subscriptions.
- Only a customer signed in to that merchant's manage page can read this, and only for their own cards. The answers are never cached.
Why it matters
- Customers can see what a card is used for before they replace or remove it.
Developer notes
- Merchant subscription and payment method endpoints, their authentication and their responses are unchanged.
- This release contains no breaking changes.
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.
18 Oct 2026
Improvement
Customers
Webhooks
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.