Paid Memberships Pro can be used to set up membership levels with many different pricing structures. You can configure a level to offer a recurring subscription or a level with a one-time payment and expiration date. Unless you really want a membership to expire after a certain time frame, you usually DO NOT want to set BOTH a recurring billing amount AND an expiration date on your levels.
Two Options for Renewals
If you want your member payments to bill automatically, set up a recurring billing amount. Users will receive an Invoice via email when their recurring payments are made. If you’d like your members to also get an email warning them of their upcoming automatic renewal, you can use our Recurring Payment Email Reminders Add On.
If you want a one-time payment that expires after a certain time frame, set an expiration date. Users with an expiration date will get an email before the expiration with a chance to renew and extend their membership for another one-time payment.
If you’d like to give your users the option to choose between the two options, you can use our Auto-Renewal Checkbox Add On.
The Rare Case Where Both Are Needed
There are cases where you would want to set both a recurring billing amount and an expiration date. The two most common cases are payment plans (3 easy payments of $19.95) and courses with a set time frame ($100 per week for our 6 week course). In both cases, you likely need to use custom code so users continue to have access to ongoing content they need even though they won’t be paying anymore. You can use a recipe like this one to have members whose memberships expire be given a different ongoing membership.
Yes, we know we are different.
We know that all membership platforms handle recurring billing and expiration dates in a different way. If you are migrating from another system, this can be especially confusing.
With some systems, user memberships will expire on a certain date unless a new recurring payment comes in. With Paid Memberships Pro, memberships will last until the payment gateway detects a missed payment (or three) and cancels the subscription.
The main difference between these approaches is what happens when sites get out of sync with the gateway. With our approach, users can potentially get their membership extended for free while the gateway tries to tell your site to cancel the subscription. With the other approach, users can potentially have their membership removed accidentally even though their payments were processed by the gateway. In situations like this, we tend to go with the decision that is better for your members.
What if you’ve accidentally set up your Membership Levels with Recurring Billing and an Expiration Date?
This is a bit tricky to fix. The first step would be to review this post and if you really don’t need an expiration date, update your membership levels to remove the expiration dates. This will fix things for new members going forward, but your existing members will have an expiration date set in the PMPro database and PMPro will expire those members on the specified dates.
To fix existing members, you need to update the database to remove the expiration dates from those users. The users will still have recurring subscriptions at the gateway and their subscriptions and membership will be cancelled if they miss payments (assuming your gateway IPN or webhook is working properly).
Back up your database. Then use a SQL query like the following to remove the expiration dates (or “end dates”) from ALL existing and active members. Note that if you have members who were imported, manually added, or had other membership levels that DO need expiration dates, then you will need to alter the query so it only removes the end dates from the users you want it to.
We Are Getting Better
Paid Memberships Pro shows a warning when you configure a level to have both a recurring billing amount and an expiration date. This will help the admin determine if they really intended that membership model or if they need to adjust their level settings and clean things up for active members.
There are other cases of user errors like this that we are trying our best to help site owners avoid. We aim to make things as clear as possible and are building development tools to make it easier for us to detect risky configurations or scenarios so we can give actionable warnings to site admins.
WordPress is a powerful tool. You can do a lot with it. You can also break a lot with it. We will never be able to catch every possible error like this, but we will try our best to help our users avoid the worst ones.