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.
Con los servicios de pago de tarjeta en archivo, el complemento MemberMouse de su sitio es responsable de realizar un seguimiento del calendario de pagos y de enviar las solicitudes de pago al servicio de pago (es decir, Stripe, Braintree, Authorize.net CIM) cuando vence un pago. Esta disposición es más flexible, pero requiere que nuestro plugin asuma la responsabilidad de la facturación recurrente.
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.
A partir de MemberMouse 3.0, utilizamos 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 Filtros de WordPress para cambiar este intervalo.
La facturación local puede requerir que se ejecute la actividad del sitio
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.
En general, se accede a la mayoría de los sitios al menos una vez cada pocas horas, debido al tráfico de miembros y motores de búsqueda, y esto es suficiente para proporcionar una facturación fiable. Sin embargo, es teóricamente posible que no se acceda a un sitio sin cron centralizado durante un largo periodo de tiempo y, en este caso, la facturación local no se ejecutaría cuando se espera.
Afortunadamente, esta preocupación se soluciona fácilmente utilizando un servicio de monitorización del tiempo de actividad. Estos servicios acceden periódicamente a su sitio y confirman que responde como se espera. Si el sitio no responde, el monitor de tiempo de actividad le avisa por correo electrónico o mensaje de texto. Además de proporcionar una importante medida de fiabilidad, las comprobaciones periódicas del servicio de monitorización activarán la facturación cuando sea necesario.
Hay muchos servicios de monitorización del tiempo de actividad disponibles, y varios incluyen ofertas gratuitas que son más que suficientes para sitios web pequeños y medianos. Estos son algunos servicios que ofrecen un nivel gratuito:
Al configurar la monitorización, tendrá la opción de elegir la frecuencia con la que el sistema envía peticiones a su sitio. Aunque intuitivamente pueda parecer mejor monitorizar con una frecuencia mayor, tenga en cuenta que cada registro requiere que su servidor procese y responda a una petición, utilizando recursos. Para la mayoría de los clientes, recomendamos una frecuencia de monitorización de 15-30 minutos.
Tenga en cuenta que algunos proveedores de alojamiento con cron centralizado recomiendan que desactive WP-Cron y dependa enteramente de su infraestructura para los disparos, pero se lo desaconsejamos. La activación periódica proporciona un nivel mínimo de actividad, pero la cola está configurada para ejecutarse con más frecuencia si es posible, y para obtener mejores resultados se le debe permitir hacerlo.
Creación y restauración de copias de seguridad de su sitio web
Dado que toda la información relacionada con la facturación local se almacena dentro de su instalación de WordPress, la restauración de una copia de seguridad de su sitio devuelve el programa de facturación a un estado anterior. Esto significa que las refacturaciones que se procesaron después de que se creara la copia de seguridad se pondrán en cola para ejecutarse de nuevo.
To help you manage situations where a backup is restored, we’ve introduced a new Próximos pagos que le permite omitir o cancelar las refacturaciones individualmente o en bloque.
Por lo general, las refacturaciones vencidas se ejecutan lo más rápidamente posible, y el sistema comenzará a procesarlas en cuanto se complete la restauración. Las protecciones que MemberMouse puede ofrecer contra esto se basan en las características del servicio de pago. Los clientes que utilizan Stripe están protegidos por:
- Grabación de metadatos - Cuando MemberMouse procesa una refacturación en Stripe, registra información sobre la siguiente refacturación que debe procesarse. Cuando se restaura una copia de seguridad de más de 24 horas de antigüedad, buscamos en los metadatos de Stripe si ya se ha procesado la siguiente refacturación programada. Si se encuentran datos coincidentes, pausamos temporalmente la facturación local y mostramos un mensaje que le pide que tome medidas para corregir los calendarios de pago en MemberMouse. El artículo Se ha suspendido la refacturación in situ explica cómo abordar esta situación.
- Idempotencia de las transacciones - Cada transacción realizada en Stripe utiliza un Clave de idempotencia generado a partir de la información del pedido. Stripe rechazará las transacciones que ya se hayan facturado en las últimas 24 horas.
Si estás creando manualmente una copia de seguridad antes de una migración u otra actividad de mantenimiento importante, puedes pausar temporalmente la facturación local antes de empezar. Si fuera necesario restaurar esta copia de seguridad, la facturación local ya estará en pausa cuando se complete la restauración. A continuación, puede omitir los pagos ya facturados y habilitar la facturación local una vez completado este paso. La configuración del Programador de Facturación Local se encuentra en MemberMouse > Ajustes generales > Otros ajustesal final de la página.

