Como o MemberMouse lida com o faturamento recorrente

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.

Com os serviços de pagamento por cartão em arquivo, o plug-in MemberMouse em seu site é responsável por manter o controle do cronograma de pagamento e enviar solicitações de pagamento ao serviço de pagamento (por exemplo, Stripe, Braintree, Authorize.net CIM) quando um pagamento é devido. Esse arranjo é mais flexível, mas exige que nosso plug-in assuma a responsabilidade pelo faturamento recorrente.

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 do 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 do WordPress para alterar esse intervalo.

O faturamento local pode exigir a execução da atividade do site

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.

Em geral, a maioria dos sites é acessada pelo menos uma vez a cada poucas horas, devido ao tráfego de membros e de mecanismos de pesquisa, e isso é suficiente para fornecer um faturamento confiável. No entanto, é teoricamente possível que um site sem cron centralizado não seja acessado por um longo período de tempo e, nesse caso, o faturamento local não seria executado quando esperado. 

Felizmente, essa preocupação é facilmente resolvida com o uso de um serviço de monitoramento de tempo de atividade. Esses serviços acessam periodicamente o seu site e confirmam se ele responde conforme o esperado. Se o site não responder, o monitor de tempo de atividade o alertará por e-mail ou mensagem de texto. Além de fornecer uma importante métrica de confiabilidade, as verificações periódicas do serviço de monitoramento acionam o faturamento para ser executado conforme necessário.   

Há muitos serviços de monitoramento de tempo de atividade disponíveis, e vários incluem ofertas de nível gratuito que são mais do que suficientes para sites de pequeno e médio porte. Aqui estão alguns serviços que oferecem um nível gratuito:

• UptimeRobot
• Pilha melhor
• Monitor de tempo de atividade
• StatusCake
• HetrixTools

Ao configurar o monitoramento, você terá a opção de escolher a frequência com que o sistema envia solicitações ao seu site. Embora possa parecer intuitivamente melhor monitorar com uma frequência maior, lembre-se de que cada check-in exige que o servidor processe e responda a uma solicitação, utilizando recursos. Para a maioria dos clientes, recomendamos uma frequência de monitoramento de 15 a 30 minutos.

Observe que alguns provedores de hospedagem com cron centralizado recomendam que você desative o WP-Cron e confie totalmente na infraestrutura deles para acionadores, mas não recomendamos isso. O acionamento periódico fornece um nível mínimo de atividade, mas a fila é configurada para ser executada com mais frequência, se possível, e, para obter os melhores resultados, deve-se permitir que ela o faça.

Criação e restauração de backups de seu site

Como todas as informações envolvidas no faturamento local são armazenadas em sua instalação do WordPress, a restauração de um backup de seu site retorna a programação de faturamento a um estado anterior. Isso significa que as cobranças que foram processadas após a criação do backup serão colocadas na fila para serem executadas novamente.

To help you manage situations where a backup is restored, we’ve introduced a new Próximos pagamentos que permite que você ignore ou cancele reembolsos individualmente ou em massa. 

De modo geral, as cobranças em atraso são executadas o mais rápido possível e o sistema começará a processá-las assim que a restauração for concluída. As proteções que o MemberMouse pode oferecer contra isso são baseadas nos recursos do serviço de pagamento. Os clientes que usam o Stripe estão protegidos por: 

• Registro de metadados - Quando o MemberMouse processa um boleto no Stripe, ele registra informações sobre o próximo boleto a ser processado. Quando um backup com mais de 24 horas é restaurado, pesquisamos os metadados do Stripe para ver se o próximo faturamento programado já foi processado. Se forem encontrados dados correspondentes, pausamos temporariamente o faturamento local e exibimos uma mensagem solicitando que você tome medidas para corrigir as programações de pagamento no MemberMouse. O artigo A cobrança no local foi pausada explica como lidar com essa situação.
  
• Idempotência de transações - Toda transação executada no Stripe utiliza um Chave de idempotência gerado a partir das informações do pedido. O Stripe rejeitará transações que já tenham sido cobradas nas últimas 24 horas.

Se você estiver criando manualmente um backup antes de uma migração ou outra atividade de manutenção importante, poderá pausar temporariamente o faturamento local antes de começar. Caso seja necessário restaurar esse backup, o faturamento local já estará pausado quando a restauração for concluída. Em seguida, você pode ignorar os pagamentos que já foram faturados e ativar o faturamento local quando essa etapa for concluída. As configurações do Local Billing Scheduler podem ser encontradas em MemberMouse > Configurações gerais > Outras configurações, próximo à parte inferior da página.