Cobrança recorrente: requisitos para subscrições bem definidas

Distinga subscrição, documento e tentativa

A subscrição representa o acordo de acesso ou fornecimento ao longo do tempo. Um documento de cobrança representa um valor devido, e a tentativa de pagamento procura liquidá-lo. Estes objetos devem ter referências diferentes. Uma tentativa recusada não deve apagar a história da subscrição nem criar automaticamente uma nova dívida sem regras explícitas.

Considere um serviço de manutenção mensal. O cliente pode ter o mês atual pago, embora a tentativa relativa ao próximo período falhe. A aplicação precisa de conhecer a data até à qual o serviço está coberto. Bloquear tudo à primeira falha pode contrariar a regra comercial; prolongar indefinidamente também. A decisão deve ser definida antes da implementação.

Faturação do software OrsunPay

Verifique quem fornece a capacidade recorrente

Nem todas as integrações de pagamentos incluem uma solução de subscrições. Confirme o produto do prestador, a sua disponibilidade na conta e as condições para guardar referências de pagamento de forma apropriada. Não crie uma base de dados própria de segredos de cartão para simular uma funcionalidade que deveria pertencer ao ambiente autorizado do prestador.

Na OrsunPay, Billing refere-se à faturação do uso do software e às respetivas cobranças, não a um motor pronto para subscrições dos seus clientes. A experiência completa desse produto continua em desenvolvimento. Se precisa de recorrência comercial, escolha e valide uma solução específica, distinguindo-a da camada de orquestração e dos contratos que mantém com os prestadores.

Ligações a prestadores

Escreva regras de calendário e alteração

Defina o início do período, o fuso horário e a regra para meses com durações diferentes. Explique quando uma alteração de preço entra em vigor e como é comunicada. Se houver um cálculo proporcional por mudança de plano, guarde exemplos que permitam conferir o resultado. Não deixe que dois sistemas calculem a mesma diferença de formas independentes.

Num serviço com nível básico e avançado, a mudança pode vigorar no ciclo seguinte ou implicar uma cobrança adicional acordada. São opções comerciais diferentes. O apoio deve conseguir consultar a regra aplicada, a data e o valor, sem depender de memória. Uma integração tecnicamente correta pode continuar a gerar conflitos se o significado da mudança nunca foi definido.

Trate falhas e incertezas de forma distinta

Uma recusa confirmada e uma resposta perdida precisam de procedimentos diferentes. Antes de repetir uma operação incerta, consulte a tentativa existente. A documentação Stripe sobre pagamentos e webhooks mostra a importância de eventos assíncronos; a aplicação deve validar esses eventos e impedir que a mesma confirmação prolongue o acesso duas vezes.

Defina quem acompanha os casos pendentes e quando ocorre comunicação ao cliente. Não prometa repetições automáticas se não foram configuradas no produto efetivamente utilizado. As regras de acesso, cobrança e contacto devem estar relacionadas, mas separadas. Uma falha no envio de email, por exemplo, não transforma um pagamento confirmado numa operação que precisa de ser novamente cobrada.

Modele cancelamento e devolução separadamente

Cancelar uma renovação futura não significa necessariamente devolver o valor de um período já pago. A interface interna deve permitir distinguir essas ações e as respetivas autorizações. Registe o que foi pedido, a regra aplicada e a confirmação enviada. Para condições contratuais, fiscais ou legais, utilize os responsáveis adequados; este roteiro é operacional.

• Teste um cancelamento antes da próxima tentativa prevista.
• Simule uma mudança de plano com cobrança ainda pendente.
• Repita a confirmação e verifique que o acesso não duplica.
• Confirme que uma devolução não recria a subscrição por engano.

Prepare uma reconciliação entre sistemas

A equipa deve conseguir relacionar subscrição, documento, tentativa e direito de acesso. Um painel do prestador pode mostrar o pagamento sem explicar um bloqueio no produto. Atribua responsáveis a cada sistema e um procedimento de recuperação que preserve os resultados já confirmados.

Antes de lançar, execute um ciclo completo com início, renovação, falha e cancelamento. Registe os estados esperados e as mensagens que o cliente recebe. A OrsunPay pode integrar uma arquitetura de pagamentos com contas próprias dos prestadores e cobrança de software separada, mas não deve receber capacidades de gestão de subscrições apenas por associação ao termo Billing.

Fontes

• Stripe — Pagamentos
• Stripe — Notificações webhook