The customer updated a card, but SaaS retries still use the old one

Ask support to verify the billing record through the authorized payment platform, without requesting full card numbers by email or chat. Record when the customer made the update and which customer or subscription it affected. If the business has several workspaces or billing accounts, first establish that the new method was saved against the account with the failed invoice.

Stripe documents an order of payment-method preferences, including subscription-level defaults that can take precedence over a customer's general default. Updating one field can therefore leave a more specific older choice in use. Review the method referenced by the failed attempt and the configured defaults before sending the customer through the same update process again.

Inspect the latest attempt's timestamp, payment-method reference and result. If it still points to the previous method, route the case to the configuration owner. If it uses the new method but fails, investigate the actual payment outcome and any required customer authentication. A message saying 'the new card did not work' is misleading when the platform never attempted to use it.

Check whether a retry is scheduled, has executed or is blocked. Stripe's retry documentation distinguishes scheduled attempts from charges that actually execute in some decline situations. Explain the observed state to the customer and provide the platform's secure next action. Avoid repeated manual charges while the existing attempt is still processing.

The desired outcome is payment of the intended outstanding invoice and the correct method for later renewals. An invoice-level payment setting may differ from the subscription's next-cycle setting. Stripe's subscription-invoice documentation describes those levels. Review both instead of assuming a successful one-time payment has updated every future billing instruction.

Keep a record of any customer-authorized change and the successful payment reference. Confirm the invoice balance before further collection attempts. If a staff member records an external payment or applies a credit during the investigation, reconcile that action too so the platform does not collect an amount already settled through another route.

A customer with several subscriptions may have different approved payment arrangements. List the affected subscriptions and identify which should use the newly supplied method. Preserve any deliberate exception, such as a separately invoiced business unit, rather than applying a blanket update across the account merely because one renewal failed.

Ask the system owner to demonstrate the future payment selection using provider identifiers and approved test data. Finance does not need full card details to review that evidence. Record the expected method reference against the failed invoice and each future renewal requiring repair, then confirm that successful collection of one bill has not left the others pointing at the obsolete default.

Ask the systems owner to reproduce the original customer journey in a test environment. Check a customer with a general default, one with a subscription override and one with several active subscriptions. The correct behavior depends on what the customer was told the update would affect. Use that promise as the acceptance condition rather than changing all defaults indiscriminately.

Give support a concise procedure for identifying the relevant payment record and escalation owner. Keep sensitive payment data inside the provider's authorized interface. After the repair, verify the next affected renewal and review whether reminders sent during the incident need correction. Close the case with the customer's current balance and the confirmed future billing arrangement.