How MemberMouse Handles Recurring Billing

When discussing how MemberMouse handles recurring billing, we first need to distinguish between payment services that support card-on-file functionality, and those that don't. Card-on-file functionality is when the payment service stores a customer's credit card information in a secure way and provides a payment token that can be used to make future payments.

With payment services that don't support card-on-file functionality (i.e. PayPal, Authorize.net), MemberMouse has no control over the recurring billing process. When the customer purchases a subscription via one of these services, a schedule is set up within the payment service, and they take responsibility for rebilling the customer at the appropriate time. MemberMouse listens for notifications of failed or successful billing, and takes the appropriate action.

With card-on-file payment services, the MemberMouse plugin on your site is responsible for keeping track of the payment schedule and sending payment requests to the payment service (i.e. Stripe, Braintree, Authorize.net CIM) when a payment is due. This arrangement is more flexible, but it requires our plugin to assume responsibility for recurring billing.

Historically, MemberMouse addressed this by synchronizing your site's billing schedule with a centralized server. Only the schedule ID and rebill date were stored on the server, no personal information for any customer was ever stored remotely. Centralizing billing allowed us to overcome certain environmental limitations of the time, and guarantee that billing would run every few hours. All versions of MemberMouse prior to 2.4.5 use this centralized approach.

Starting with MemberMouse 3.0, we utilize WP-Cron and a new queueing system to handle recurring billing entirely within the plugin. This means that billing on your site is no longer dependent on our centralized infrastructure, but it introduces some additional considerations for site operators. By default, we've scheduled local billing to run every 15 minutes, but advanced users may utilize our WordPress Filters to change this interval.

Local Billing May Require Site Activity to Run

One important limitation of WordPress is that WP-Cron can only run scheduled tasks when it is triggered. Many hosting providers overcome this limitation by periodically triggering WP-Cron using other parts of their infrastructure. However, a minority of providers don't offer this feature, and in this case, billing will only run when the site is accessed.

In general, most sites are accessed at least once every few hours, due to member and search engine traffic, and this is enough to provide reliable billing. However, it is theoretically possible that a site without centralized cron might not be accessed for an extended period of time, and in this case, local billing would not run when expected. 

Fortunately, this concern is easily addressed by using an uptime monitoring service. These services periodically access your site, and confirm that it responds as expected. If the site does not respond, the uptime monitor alerts you by email or text message. In addition to providing an important reliability metric, the periodic checks by the monitoring service will trigger billing to run as needed.   

There are many available uptime monitoring services, and several include free-tier offerings that are more than sufficient for small and medium-sized websites. Here are a few services that offer a free tier:

• UptimeRobot
• Better Stack
• Uptime Monitor
• StatusCake
• HetrixTools

When configuring monitoring, you will have the option to choose how often the system sends requests to your site. Although it may seem intuitively better to monitor at a higher frequency, keep in mind that each check-in requires your server to process and respond to a request, utilizing resources. For most customers, we recommend 15-30 minute monitoring frequency.

Note that some hosting providers with centralized cron recommend that you deactivate WP-Cron and rely entirely on their infrastructure for triggers, but we advise against this. Periodic triggering provides a minimum level of activity, but the queue is configured to run more frequently if possible, and for best results it should be allowed to do so.

Creating and Restoring Backups of Your Site

Since all information involved in local billing is stored within your WordPress installation, restoring a backup of your site returns the billing schedule to a previous state. This means that rebills that were processed after the backup was created will be queued to run again.

To help you manage situations where a backup is restored, we've introduced a new Upcoming Payments page, which allows you to skip or cancel rebills individually or in bulk. 

Generally speaking, overdue rebills are run as quickly as possible, and the system will begin processing them as soon as the restore is complete. The protections that MemberMouse can offer against this are based on payment service features. Customers using Stripe are protected by: 

• Metadata Recording – When MemberMouse processes a rebill in Stripe, it records information about the next rebill due to be processed. When a backup more than 24 hours old is restored, we search Stripe metadata to see if the next scheduled rebill has already been processed. If matching data is found, we temporarily pause local billing and display a message prompting you to take action to correct the payment schedules in MemberMouse. The article On-site Rebilling has been Paused explains how to address this situation.
  
• Transaction Idempotency – Every transaction run on Stripe utilizes an Idempotency Key generated from order information. Stripe will reject transactions that have already billed within the last 24 hours.

If you are manually creating a backup before a migration or other major maintenance activity, you can temporarily pause local billing before you start. Should it become necessary to restore this backup, local billing will already be paused when the restoration is complete. You can then skip any payments that have already billed, and enable local billing once this step is complete. Settings for the Local Billing Scheduler can be found in MemberMouse > General Settings > Other Settings, near the bottom of the page.