GuideStripe Memberships Not Auto-Renewing? How to Fix It Before Renewal Day

If your members paid yearly or monthly fees as one-time Stripe payments, nothing will charge them on renewal day: Stripe only repeats a charge when a subscription, or an invoice you create, tells it to. There are three ways to move existing members to auto-renew. Which one fits depends on one question: did Stripe save each member's card when they first paid?

Many membership apps will need two of them: option 3 for members whose card was saved, and option 1 for everyone else. Option 2 buys time, but it isn't auto-renew; you still have to create every invoice.

First: who has to enter a card again?

This decides how much work each member has to do, so check it before writing to anyone.

Stripe's Checkout docs are direct about it: "By default, payment methods used to make a one-time payment with Checkout aren't available for future use" (Stripe). A one-time payment keeps the card for later only if both of these were true when the member paid:

1. The checkout asked to save it. Either the Checkout Session or Payment Link set payment_intent_data.setup_future_usage (off_session is the value for charging later without the member present), or the session showed the save checkbox from saved_payment_method_options.payment_method_save and the member ticked it (Stripe).
2. The payment belonged to a Customer. With setup_future_usage, Checkout attaches the card to a Customer only if you passed one or Checkout created one. If Checkout didn't create a Customer, the card isn't attached to anyone (Stripe API). Payment Links default to customer_creation=if_required, and a one-time payment doesn't require a Customer unless post-purchase invoices are on (Stripe API).

Payments that weren't tied to a Customer are grouped as guest customers in the Dashboard. Stripe's own words: "Stripe doesn't save payment methods for guest customers, so you can't initiate new charges against them" (Stripe).

How to check: open a few members in the Stripe Dashboard's Customers page. Members who appear only under the Guests tab, or whose customer page lists no payment method, usually have to enter a card once (option 1). If the original checkout set setup_future_usage but created no Customer, the card may still be reachable from that payment's PaymentIntent (Stripe API), so check before asking. Members with a saved card can be moved without entering anything (option 3), provided they have agreed to automatic charges (see below).

Option 1: subscribe through Checkout or a Payment Link

Create a recurring price (yearly or monthly) for each membership plan, then send members a subscribe link.

• Payment Link. Choose a recurring price and the link creates a subscription (Stripe). In subscription mode Stripe saves the card to charge the renewals that follow (Stripe). No code is needed. The catch: by default a subscription's billing date is the day it's created (Stripe), so a member who already paid through next March would pay again today.
• Checkout Session from your server. Create a session in subscription mode with subscription_data.billing_cycle_anchor set to that member's renewal date and subscription_data.proration_behavior set to none. The member enters a card now, isn't charged for the time until the anchor, and gets an invoice for the full amount on that date (Stripe). The anchor has to fall within one billing period from today, which a yearly member's next renewal always does. Checkout can't combine a trial with a billing cycle anchor, so use the anchor rather than a trial here, and it can't add one-time prices when proration_behavior is none, so charge any joining fee another way (Stripe).

Checkout Sessions expire 24 hours after they are created by default (Stripe), so don't email a session link weeks ahead. Put a "Turn on auto-renew" button in your app or members area that creates the session when the member clicks it.

Best for: members whose card was never saved. Ask each one to subscribe before their renewal day.

Option 2: invoice each renewal and charge the saved card

If a member has a saved card set as their default, a one-off invoice with collection_method=charge_automatically charges it without the member doing anything (Stripe). Two things to know:

• When Stripe charges a saved card for an invoice, it doesn't notify the customer about the invoice. Turn on the successful-payment receipt email, or tell members yourself (Stripe).
• Retries for one-off invoices are a separate setting from subscription retries, under Settings, Billing, Invoices (Stripe).

This is still manual billing: nothing creates next year's invoice unless you or your app does. Use it to cover one renewal date while you set up option 3, but anchor that member's subscription to the renewal after the one you invoiced, never the same date, or they are charged twice.

Option 3: create subscriptions for members with a saved card

For members whose card Stripe kept, create the subscription for them with the Subscriptions API:

• customer: the member's Stripe Customer.
• items[0][price]: the recurring price of their plan.
• default_payment_method: the saved card. If you leave it out, invoices use the Customer's invoice_settings.default_payment_method (Stripe API), so make sure one of the two is set.
• billing_cycle_anchor: their renewal date, with proration_behavior=none, so the first charge lands on renewal day and not today (Stripe).

collection_method defaults to charge_automatically, which is what you want (Stripe API). From then on Stripe charges the card every period on its own.

Check that the card can be used this way. Stripe says that when you save a payment method, "you can only use it for the specific usage you've included in your terms". Charging a member who isn't present needs their agreement to the payments, their timing and frequency, how the amount is set and how to cancel, and you should keep a record of that agreement (Stripe). If the member's original checkout didn't cover automatic yearly or monthly charges, get their agreement first, or use option 1 so they opt in on a Stripe page.

Why the anchor and not a free trial? A trial also delays the first charge, but members can't switch plans or quantities on a subscription with a trial offer in the customer portal (they can still cancel) (Stripe), and your app would see trialing instead of active (Stripe).

When the bank asks for authentication. Some banks ask the cardholder to confirm a charge even when the card is saved. authentication_required is a hard decline: Stripe keeps the retries scheduled but only runs them once a new payment method is on file (Stripe). Turn on the email that sends the member a Stripe-hosted page to confirm payments their bank asks to authenticate (Stripe), and watch for the invoice.payment_action_required event.

Before renewal day: the checklist

1. Sort members into two lists: saved card (option 3) and no saved card (option 1). Note each member's renewal date.
2. Create the recurring prices, one per plan and interval.
3. Get each member's agreement in writing to the automatic charges, stating the amount, timing and how to cancel, before the first charge. Stripe says your terms must cover these and that you keep a record of the agreement (Stripe).
4. Turn on Smart Retries under Billing, Revenue recovery, Retries. Stripe's recommended default is 8 tries within 2 weeks, and you choose what happens after the last one: cancel, mark unpaid, leave past due or, where eligible, pause (Stripe).
5. Turn on the customer emails for failed payments, expiring cards (sent 1 month before the card expires) and upcoming renewals. Renewal reminders only go out for subscriptions that charge automatically (Stripe).
6. Activate the customer portal (next section) and link it from your app.
7. Wire the webhooks (below), then test a full renewal in a sandbox with a test clock, which moves time forward so you can watch an annual renewal, and a failed one, without waiting a year (Stripe).
8. Retire the old one-time payment links for renewals, and before creating a subscription check that the member has no active one already, so nobody pays twice.

Let members manage it themselves: the customer portal

The Stripe customer portal lets members update their card, view and pay invoices, and cancel immediately or at the end of the period (Stripe). You can turn it on without code: activate the login link in the Dashboard and put it on your site. Members enter their email and Stripe emails them a link that opens their portal. It only works for an email that matches a Stripe Customer, so keep each member's email on their Customer (Stripe). Stripe's failed-payment and expiring-card emails can link to the portal too (Stripe).

Keep member status in your app in sync

Stripe charges the card, but your app decides who gets in. Without webhooks, a member whose renewal failed keeps access, and one who paid may lose it. These are the events Stripe documents for subscriptions (Stripe):

Stripe says to revoke access when a subscription moves to canceled or unpaid, and to ask the customer for new payment details when it moves to past_due (Stripe). Two details that catch apps out:

• Return a success response to invoice.created. If Stripe doesn't get one, it delays finalizing automatically collected invoices for up to 72 hours, so renewals charge late (Stripe).
• Verify that each event came from Stripe before acting on it (Stripe), and store the Stripe Customer ID on each member record so every event finds the right member.

Getting it done before renewal day

The Stripe Billing Fix and Setup ($950, fixed price) does this work in your codebase: the subscriptions for members with saved cards, subscribe links that start on each member's own renewal date for the rest, the customer portal, failed-payment settings and the webhook handler that keeps member status in sync, all tested in a Stripe sandbox first. If you'd rather have a developer on call for billing and the rest of the app, the Monthly Dev Subscription starts at $1,495 a month. Not sure which members can be moved without re-entering a card? Send me a short description of how they paid and I'll tell you where I'd start.