Ao discutir como o MemberMouse lida com o faturamento recorrente, primeiro precisamos distinguir entre os serviços de pagamento que oferecem suporte à funcionalidade de cartão em arquivo e os que não oferecem. A funcionalidade de cartão em arquivo é quando o serviço de pagamento armazena as informações do cartão de crédito de um cliente de forma segura e fornece um token de pagamento que pode ser usado para fazer pagamentos futuros.
Com serviços de pagamento que não suportam a funcionalidade de cartão em arquivo (ou seja, PayPal, Authorize.net), o MemberMouse não tem controle sobre o processo de faturamento recorrente. Quando o cliente adquire uma assinatura por meio de um desses serviços, um cronograma é configurado no serviço de pagamento e ele assume a responsabilidade de cobrar novamente o cliente no momento apropriado. O MemberMouse ouve as notificações de cobrança bem-sucedida ou não e toma as medidas adequadas.
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.
Historicamente, o MemberMouse resolvia esse problema sincronizando a programação de faturamento do seu site com um servidor centralizado. Somente o ID da programação e a data do faturamento eram armazenados no servidor, e nenhuma informação pessoal de nenhum cliente era armazenada remotamente. A centralização do faturamento nos permitiu superar certas limitações ambientais da época e garantir que o faturamento fosse executado a cada poucas horas. Todas as versões do MemberMouse anteriores à 2.4.5 usam essa abordagem centralizada.
A partir do MemberMouse 3.0, utilizamos WP-Cron e um novo sistema de filas para lidar com o faturamento recorrente inteiramente dentro do plug-in. Isso significa que o faturamento em seu site não depende mais de nossa infraestrutura centralizada, mas introduz algumas considerações adicionais para os operadores do site. Por padrão, programamos o faturamento local para ser executado a cada 15 minutos, mas os usuários avançados podem utilizar nosso Filtros do WordPress para alterar esse intervalo.
O faturamento local pode exigir a execução da atividade do site
Uma limitação importante do WordPress é que o WP-Cron só pode executar tarefas agendadas quando é acionado. Muitos provedores de hospedagem superam essa limitação acionando periodicamente o WP-Cron usando outras partes de sua infraestrutura. No entanto, uma minoria de provedores não oferece esse recurso e, nesse caso, o faturamento só será executado quando o site for acessado.
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:
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.
Para ajudá-lo a gerenciar situações em que um backup é restaurado, introduzimos um novo 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.