Método · Recorrente
Subscrições que não falham em silêncio.
A receita recorrente falha de duas formas aborrecidas: o cartão é reemitido e a cobrança deixa de funcionar, ou uma renovação é recusada temporariamente e ninguém repara até o cliente já ter saído. Os network tokens resolvem a primeira, as novas tentativas agendadas resolvem a segunda, e ambos funcionam sem que a sua equipa tenha de construir um motor de faturação.
Seu
Calendário e montante
Auto
Nova tentativa após recusa temporária
Token
Sobrevive à reemissão do cartão
1
Uma encomenda por ciclo
Como funciona
Da adesão à renovação, em quatro passos.
- 01
AUTHORIZE
O cliente paga uma vez no checkout; o cartão fica guardado como network token.
- 02
SCHEDULE
Define o montante, o intervalo, o início e o fim — ou deixa em aberto.
- 03
CHARGE
Cada ciclo gera a sua própria encomenda, o seu próprio recibo e o seu próprio webhook.
- 04
RECOVER
Uma recusa temporária é repetida segundo um calendário, em vez de ser dada como perdida por churn.
Cada ciclo é uma encomenda real
Uma subscrição não é um objeto especial com reporting próprio — cada cobrança gera uma encomenda, um recibo e um webhook, tal como um pagamento único. Assim, a subscrição reconcilia linha a linha, é possível reembolsar um só mês sem desfazer toda a relação, e a sua equipa financeira não precisa de um segundo modelo mental para a receita recorrente.
- 01Uma encomenda, um recibo e um webhook por ciclo
- 02Reembolse um único ciclo sem tocar nos outros
- 03Reconcilia na mesma lista dos pagamentos únicos
As duas falhas que realmente custam dinheiro
O churn involuntário resume-se sobretudo a duas coisas: cartões expirados ou reemitidos, e recusas temporárias que ninguém repetiu. Os network tokens acompanham o titular numa reemissão, pelo que a cobrança continua a funcionar quando chega um cartão novo. As novas tentativas agendadas voltam a tentar após uma recusa temporária, em momentos escolhidos para terem melhor probabilidade do que a primeira tentativa.
- 01Os network tokens sobrevivem a reemissões e expirações
- 02Recusas temporárias repetidas segundo um calendário, não abandonadas
- 03O cliente só é avisado quando realmente importa
O que é preciso para ativar
Uma flag no primeiro pagamento para guardar o cartão, e um calendário. Não há nenhum produto de faturação separado para integrar, e as cobranças da subscrição chegam ao mesmo back office e ao mesmo pagamento (payout) que tudo o resto que recebe.
FAQ
Pagamentos recorrentes — perguntas dos comerciantes.
Não. O calendário, as novas tentativas e a gestão de tokens fazem parte do método. Da sua parte, fica o primeiro pagamento e a decisão sobre o montante e o intervalo.
O cartão guardado é um network token, que acompanha o titular nas reemissões e expirações — por isso a subscrição que antes falharia continua a ser cobrada.
Sim. O cartão por trás do Apple Pay ou do Google Pay pode ser tokenizado para cobranças recorrentes, pelo que uma subscrição iniciada com um toque continua sem que o cliente volte ao checkout.
Cada ciclo é a sua própria encomenda, por isso reembolsa essa encomenda — total ou parcialmente — sem afetar nenhum outro ciclo nem cancelar a subscrição.
Mais métodos
Muitas vezes ativados em conjunto.
Cartões guardados
Cofre · Um cliqueOs clientes habituais pagam com um toque; o cartão fica no nosso cofre e o seu sistema guarda uma referência.
02Pagamentos com cartão
Visa · MastercardO canal por defeito, com 3-D Secure 2.0 e autenticação forte do cliente tratados dentro do fluxo.
03Pay by link
Sem necessidade de integraçãoUm link que cria no back office e envia — com todos os métodos por trás, sem necessidade de site.
Receba um pagamento em cada um deles.
Um comerciante sandbox, chaves de API e um checkout com todos estes métodos ativados — para executar cada método de ponta a ponta antes de se comprometer com o que quer que seja.