O PrestaShop está construído à volta de um ato único: um carrinho, uma encomenda, um pagamento. A subscrição supõe o inverso, um compromisso que produz pagamentos no tempo sem que o cliente volte. Estes dois modelos não se juntam naturalmente.
Eis a arquitetura que funciona, e os pontos em que as implementações partem.
Quem detém a verdade
Primeira decisão, e condiciona tudo o resto.
Uma plataforma de pagamento como o Stripe dispõe de um motor de faturação recorrente completo: subscrições, vencimentos, relances, gestão dos cartões expirados. Reconstruir isso no PrestaShop seria um erro.
A repartição que se sustenta: o Stripe detém a subscrição, isto é, o ciclo, os vencimentos e a cobrança. O PrestaShop detém o catálogo, o cliente e as encomendas geradas a cada vencimento.
Concretamente, cada débito bem-sucedido cria uma encomenda no PrestaShop, que segue depois o seu processo normal de preparação e de expedição. É o que permite manter as suas estatísticas, as suas faturas e a sua logística coerentes.
Os webhooks a escutar
É o coração da integração, e o ponto onde o trabalho está realmente.
Cinco eventos devem ser tratados, cada um com um comportamento preciso.
- O pagamento de vencimento bem-sucedido. Cria a encomenda no PrestaShop, decrementa o stock, dispara o email de confirmação.
- O pagamento falhado. Não cria encomenda, coloca a subscrição em espera, dispara a sequência de relance.
- A subscrição atualizada. Mudança de fórmula, de quantidade, de data. Deve repercutir-se do lado da loja.
- A subscrição anulada. Corta o acesso se vende conteúdo, para os envios se vende físico.
- O meio de pagamento a expirar. Dispara um relance antes da falha, o que evita a interrupção.
Três regras técnicas sobre os webhooks. Verifique a assinatura de cada notificação, senão qualquer um pode criar encomendas na sua loja. Trate-os de forma idempotente: o mesmo evento pode ser entregue várias vezes, e não deve criar duas encomendas. E responda rapidamente acusando a receção, tratando depois em tarefa de fundo, sem o que a plataforma considera a chamada em falha e reproduz o evento.
DataFirefly Subscriptions: Subscrições e Pagamento Recorrente Stripe para PrestaShop 8 e 9O módulo de subscrições para PrestaShop 8 e 9: cartão guardado na Stripe, recuperação de falhas e área de cliente autónoma.169,00€
Os cartões expirados, primeira rubrica de perda
Numa subscrição, a maioria das resilições sofridas vem de um meio de pagamento tornado inválido, não de uma decisão do cliente.
Três mecanismos acumulam-se para limitar os estragos. A atualização automática dos cartões, proposta pelas redes e retransmitida pelas plataformas de pagamento, que recupera o novo número sem intervenção. O relance antes da expiração, disparado um mês antes da data de fim de validade. E a sequência de nova tentativa depois de uma falha, espalhada por uma a duas semanas em vez de repetida no dia seguinte.
Preveja um período de graça durante o qual o serviço continua ativo apesar da falha. Cortar imediatamente transforma um incidente bancário numa resilição definitiva.
O funil: não misturar
Questão de conceção muitas vezes decidida tarde demais. Um carrinho com uma subscrição e produtos de compra única coloca um problema: a primeira cria um compromisso recorrente, os segundos não.
Duas abordagens aceitáveis. O funil dedicado, em que a subscrição se subscreve sozinha, sem possibilidade de lhe juntar outra coisa. Mais simples, mais claro para o cliente, e é a escolha por defeito recomendada.
Ou o carrinho misto, em que a encomenda inicial contém os dois, com um pagamento único que cobre os produtos e dispara a subscrição. Tecnicamente mais pesado, e é preciso ser muito claro sobre o que será debitado a seguir.
O que não se deve fazer: deixar duas subscrições diferentes no mesmo carrinho. Os ciclos de faturação divergem imediatamente e a gestão torna-se inextricável.
A autenticação forte
A regulamentação europeia sobre os pagamentos impõe uma autenticação do portador para muitas transações. Numa subscrição, o primeiro pagamento é autenticado pelo cliente, os seguintes relevam de um quadro diferente porque são iniciados pelo comerciante.
Duas consequências práticas. O mandato deve ser corretamente registado no primeiro pagamento, o que as plataformas gerem desde que a intenção de pagamento seja criada com os bons parâmetros. E certos vencimentos podem apesar de tudo exigir uma autenticação, o que supõe um percurso previsto para trazer o cliente para uma página de autenticação, em vez de uma falha silenciosa.
O quadro legal
Três obrigações, fiscalizadas e regularmente falhadas.
A informação antes da subscrição: duração, montante, periodicidade e modalidades de resilição devem estar visíveis na página de compra, não apenas nas condições gerais.
A resilição online, tão simples como a subscrição, acessível a partir da área de cliente sem ter de escrever nem telefonar.
A informação antes da renovação para as subscrições de renovação tácita, num prazo que deixe ao cliente o tempo de recusar.
Os três números do modelo
A receita recorrente mensal, que dá a base económica. A taxa de atrição mensal, distinguindo as resilições voluntárias das falhas de pagamento, porque os remédios diferem. E a duração de vida média de um subscritor, que decorre da segunda e que determina quanto pode gastar para adquirir um.
O módulo Subscriptions para PrestaShop implementa esta arquitetura no PrestaShop 8 e 9: subscrições apoiadas no Stripe, criação automática das encomendas a cada vencimento, tratamento dos webhooks com verificação de assinatura, gestão das falhas de pagamento e área de cliente para modificar ou resiliar.