Customer Payment Mandate Expiry Exposure

A customer has a subscription set to renew next month, but the payment method on file has expired or its recurring-use permission is no longer valid. Customer payment mandate expiry exposure describes upcoming billings for which the authorised payment route may not work at the expected charge time.

Define the mandate, since a saved card, direct-debit authorisation or another permitted recurring payment agreement has different expiration and revocation rules. Stripe documents consent for saving methods for future transactions and subscription-specific payment settings, and the Visa stored-credential framework discusses cardholder agreement for recurring transactions.

These sources illustrate why a stored token is not unconditional permission to charge. Choose the horizon, because billings due in seven, 30 or 60 days reveal different exposure, and choose the unit, since subscriptions, customer accounts or expected invoices each answer a different operational question.

Check validity, because a card expiry date, revoked mandate, disabled instrument and incompatible currency are distinct issues, and avoid false certainty since automatic card-updater services may refresh an expired card, so check the actual provider state before claiming guaranteed failure. Separate exposure from failure: an expired visible card can still route through an issuer update, while a valid card can decline for other reasons.

Check cancellation too, as a subscription scheduled to end before the billing date should not enter the renewal exposure population, and check billing dates, because trial ending, annual renewal and mid-cycle add-ons may create separate attempted charges. Review payment priority, since a customer can have several saved methods and the default for a subscription may differ from the account default, and confirm authority by never silently switching to an unrelated payment instrument just because the preferred one appears stale.

Audit consent as well: a technically available method is not eligible if the customer has not authorised it for this purpose. Handle bank mandates with care, as direct debit can be cancelled or limited by bank and jurisdiction, so verify the applicable rules, and watch partial customer accounts where one organisation pays several subscriptions from different methods.

Track amount, since expected invoice value can help prioritise support but is not yet cash due or revenue earned, and show severity because a near-term high-value renewal and a distant small invoice need different follow-up priorities. Record reason codes, as expired instrument, authorisation revoked, payment method removed and incompatible rail need different action, and use current data by timestamping the report because a mandate validity snapshot can change after the customer updates details.

Retain event history so a newly refreshed mandate clears the current exposure without erasing that it was previously at risk, and keep failed-update history visible, since a customer may have tried to replace the method but not completed a required verification step, which is not authorisation to use a new method. Protect customer choice by sending reminders to update payment information that are accurate and sent under approved communication rules, avoid duplicate reminders so one customer with five subscriptions does not receive five confusing requests if one method update would cover them, and never request full card details or mandate credentials in ordinary email or support chat.

Pair exposure with failed payments, because exposure predicts a potential problem while actual first-attempt failure is a separate outcome. Use the measure to prepare legitimate customer-led updates, not as authority to initiate a new charge or switch accounts.