Academy › Build › Payments

The card expires before the desire to keep paying does

Turn on your payment processor's expiring card alert and the link that lets the customer update it themselves, so they never have to read you the number or wait for a failed charge.

By Yodai · Published on September 6, 2026 · Updated on October 12, 2026

When you charge a monthly fee with an automatic card payment, the charge just comes in every month, until something you don't control breaks. One customer has been paying her monthly fee for a year and a half without missing a single month. Then one day, with no warning, the charge doesn't go through. She hasn't canceled anything: her card expired, and the bank sent the new one to her, not to you.

You don't find out until you check the account and see a failed charge. That's when the worst possible path begins: messaging her to ask for the new card number, waiting for her to reply, and typing it into the payment processor by hand. Three days of hassle over something that never had to happen.

Every card, physical or virtual, is good only until its expiration date, and how often they expire is up to the bank that issues them: in the system Mastercard uses to process cards for banks, a renewed card defaults to 48 months of validity, a setting that can be changed. Say you have a book of 150 customers paying monthly with four-year cards: that's about three cards a month hitting that date, without anyone, you or them, keeping track of it.

This lesson isn't about a new customer's first charge. It's about charge number eighteen, or thirty-six: the one that stops coming in simply because a card has an expiration date, like every card does.

The notice goes out, just not to you

When a card is about to expire, the bank sends the cardholder a new one. It doesn't write to the business billing them every month: at most, it passes the new details along through the card network. With Visa Account Updater, participating banks send the new number and expiration date when they reissue a card, and merchants who also participate, through their bank, receive them if available. Stripe tries to update saved cards this way, but notes that outside the United States coverage varies by country and there's no way to know in advance which cards will get updated. If your customer's card doesn't update, you find out about the problem once it already is one: the day the charge fails and that month's revenue doesn't come in.

Between those two moments, when she gets the new card and when you find out, there's a gap where anything can happen. She hasn't canceled and she isn't unhappy with what you offer: she just hasn't thought again about a payment detail she doesn't check every day.

For the customer, a year and a half of charges without a single hiccup is proof that everything works. An email saying "your payment was declined" breaks that feeling, even though the failure has nothing to do with what you offer. The sooner you fix it, the less it looks like your problem and the more it looks like a normal bank thing.

Asking for it over chat is the costly mistake

When the failed-charge alert pops up, the fastest thing seems to be texting or emailing the customer and asking right there for the new card number. That's the most expensive mistake you can make: you're asking them to write out, in plain text, in a chat or an email, exactly what's needed to use their card without having it. As the Bank of Spain points out, all it takes to commit fraud is the card number, expiration date, and security code. You copy it over by hand to the payment processor, and that number stays saved in a conversation nobody controls.

Beyond the risk of that number getting saved somewhere it shouldn't, you're asking the customer for an extra step they never should have had to take: copying sixteen digits by hand and trusting you to type them in correctly. One mistyped digit and the charge fails again the following week.

The link that fixes it on its own

The alternative is giving the customer a link that opens straight to the update-payment-method screen, no password to remember, no menu to get lost in. They get it by email before the card expires, not after. Yodai doesn't do this part: it comes built into the payment processor you use to bill your fees, if that processor offers it, and you sign up for and set it up separately. Stripe, for instance, can send an email a month before a saved card expires, with a link to one of its own pages where the customer updates their payment method and, if they have an outstanding invoice, pays it.

That link is generated by your payment processor, the same one billing the fees, which already knows which card each customer has and when it expires. You don't need to calculate dates or keep a separate list.

What the customer sees when they click through is a simple screen: a field for the card number, the new expiration date, and the security code. No passwords for your site, no security questions. That data is stored by the payment processor, not your business: with the integrations recommended in Stripe's security guide, payment data goes straight to the processor without passing through your servers, so you never see it, just like you don't see it today when a customer pays for the first time.

If your processor allows it, have the email go out from your own domain instead of theirs: this isn't just a cosmetic detail, because if it looks like spam, the customer won't open it, and the reminder will have been for nothing.

How to set this up in your payment processor

This isn't something you turn on in Yodai, which doesn't bill fees or warn you about expired cards: it's set up in the payment processor you use to bill your fees, Stripe Billing, for example, which you sign up for and configure separately. In Stripe, it's a customer-email setting you turn on once, and from then on it runs automatically for every subscription you bill through them, including customers who sign up later.

The alert and the link prevent most of the drop-offs caused by expired cards. Not all of them: when the charge fails anyway, you still have to decide how long to wait before cutting off access.