SCA e 3D Secure nas renovações de subscrições: lidar com authentication_required

A maioria das renovações falhadas tem a ver com dinheiro ou cartões: saldo insuficiente, um cartão expirado, um bloqueio no banco. Há um tipo diferente. O cartão está bom e o dinheiro existe, mas o banco quer que o cliente confirme o pagamento. No Stripe, isso aparece como o decline code authentication_required, ou como uma fatura à espera de uma ação do cliente.

Nenhuma nova tentativa resolve isto. O cliente tem de voltar e aprovar o pagamento. Este guia explica porque acontece, o que o Stripe faz por si e como levar o cliente a ultrapassar o passo depressa. Baseia-se na documentação do Stripe e nas regras europeias que lhe estão por trás (fontes consultadas em novembro de 2026).

Isto não é aconselhamento jurídico. A regulação dos pagamentos é complexa; verifique a sua configuração com o Stripe e, quando necessário, com um especialista.

Porque é que as renovações precisam sequer de autenticação

A autenticação forte do cliente em resumo

A Strong Customer Authentication (SCA) vem da segunda Diretiva de Serviços de Pagamento da UE (PSD2). Exige que os pagadores autentiquem os pagamentos eletrónicos com dois de três fatores: algo que sabem, algo que têm, algo que são. Para cartões, a forma habitual de o fazer online é o 3D Secure, em que o banco mostra um passo de confirmação (um código, uma aprovação na app, uma impressão digital).

Segundo o guia de SCA e o centro de ajuda do Stripe, a SCA aplica-se quando o prestador de pagamentos do negócio e o banco do titular do cartão estão ambos no Espaço Económico Europeu. A página de isenções do Stripe cobre também o Reino Unido e a Suíça. Os pagamentos em que uma das partes está fora da região (“one leg out”) ficam fora do âmbito, embora os bancos possam pedir autenticação na mesma.

Pagamentos recorrentes e transações iniciadas pelo comerciante

Uma renovação de subscrição acontece quando o cliente não está presente. As regras têm isso em conta:

• As normas técnicas da UE, o Regulamento Delegado (UE) 2018/389 da Comissão, exigem SCA quando um pagador cria, altera ou inicia pela primeira vez uma série de transações recorrentes com o mesmo montante e o mesmo beneficiário. Os pagamentos seguintes da série podem ser isentos (artigo 14.º).
• Os pagamentos com cartão que o comerciante inicia ao abrigo de um acordo com o cliente são tratados como transações iniciadas pelo comerciante (MIT). A página de isenções do Stripe explica que o cartão deve ser autenticado quando é guardado e que precisa do acordo do cliente (um mandato) para o cobrar mais tarde. Marcar um pagamento como MIT funciona de forma muito parecida com pedir uma isenção.

Assim, em princípio, uma autenticação na inscrição cobre as renovações futuras.

Porque falha mesmo assim

Na prática, a última palavra é do banco emissor. Pode recusar uma isenção ou uma MIT e pedir autenticação na mesma. As situações comuns incluem uma alteração do montante (um upgrade, um aumento de preço, cobranças por utilização), um cartão guardado sem autenticação, ou simplesmente a avaliação de risco do próprio banco. Quando isso acontece numa renovação off-session, ninguém está presente para concluir o 3D Secure e o pagamento falha.

O artigo de suporte do Stripe sobre as recusas authentication_required acrescenta um caso limite: os emissores devolvem por vezes authentication_required mesmo em pagamentos que já passaram pelo 3D Secure. Nesse caso, o cliente tem de contactar o seu banco.

O que o Stripe faz nas subscrições

Se usa o Stripe Billing, o Stripe trata da maior parte do mecanismo:

• As renovações são marcadas como off-session automaticamente. O artigo do Stripe sobre on-session vs off-session diz que esta marca é definida por si nas renovações do Billing.
• Os cartões guardados tornam-se MIT. Segundo a página de preparação para a SCA do Stripe, quando um cartão é guardado através das APIs Payment Intents ou Setup Intents, os pagamentos off-session posteriores são marcados como iniciados pelo comerciante.
• A fatura avisa quando é precisa uma ação. O Stripe envia o evento invoice.payment_action_required quando o pagamento de uma fatura precisa de mais uma ação do cliente. O guia de webhooks de subscrições do Stripe diz que a sua app deve então avisar o cliente.
• A página de fatura alojada trata do 3D Secure. A hosted invoice page pode executar o fluxo de autenticação sem trabalho extra da sua parte.
• O Stripe pode enviar o email. Nas definições de emails ao cliente, pode fazer com que o Stripe envie um link para os clientes confirmarem os pagamentos quando o banco o exige.

Quanto às novas tentativas, repare que a página de Smart Retries do Stripe inclui authentication_required entre os hard decline codes: o Stripe não volta a tentar automaticamente sem uma ação do cliente.

As duas formas como aparece

Sinal	O que significa	O que fazer
invoice.payment_action_required, PaymentIntent em requires_action	O banco quer 3D Secure para este pagamento	Enviar ao cliente o link da fatura alojada (ou a sua própria página) para confirmar
Decline code authentication_required em invoice.payment_failed	O emissor recusou e pediu autenticação	O mesmo: trazer o cliente de volta on-session para confirmar ou voltar a introduzir o cartão

O artigo de suporte do Stripe sobre falhas de SCA off-session indica que um PaymentIntent off-session falhado pode acabar em requires_payment_method em vez de requires_action. Se construir a sua própria página de confirmação, trate os dois estados: ou confirma o meio de pagamento existente com 3D Secure, ou recolhe de novo um meio de pagamento.

Levar o cliente a confirmar

O cliente não fez nada de errado e muitas vezes não sabe o que significa “autenticação”. A mensagem deve ser curta, calma e concreta.

O que o email deve dizer

• Assunto: “Confirme o seu pagamento [Produto]”
• Porquê: “O seu banco pede-lhe que confirme este pagamento. É uma verificação de segurança normal, não um problema com o seu cartão.”
• O quê: o montante, o plano, a data.
• Como: um botão, “Confirmar pagamento”, que leva diretamente à página de confirmação.
• Quando: “A sua subscrição continua ativa enquanto confirma. Se não conseguirmos confirmar até [data], será suspensa.”

Evite “o seu pagamento falhou” no assunto. Não é bem verdade, e leva os clientes a pensar que precisam de um cartão novo.

Momento

Envie a primeira mensagem assim que o evento chegar. Ao contrário das soft declines, esperar não ajuda: o banco não muda de ideias sozinho. Um lembrete curto ao fim de dois ou três dias, e depois um último aviso antes do fim do seu período de tolerância, chega. Os nossos modelos de emails de recuperação incluem uma variante para a autenticação.

A página de confirmação

• Funciona no telemóvel sem iniciar sessão (um link assinado).
• Mostra o montante e o produto antes do passo do banco.
• Abre diretamente o passo de 3D Secure do banco.
• Oferece “usar outro cartão” como alternativa, para clientes cujo banco continua a recusar.
• Confirma claramente o sucesso e para todos os emails seguintes em invoice.paid.

Reduzir as falhas de autenticação

Não as pode eliminar por completo, porque quem decide é o banco. Pode torná-las mais raras.

1. Autentique quando o cartão é guardado

Recolha o cartão com um SetupIntent (ou o primeiro PaymentIntent) e setup_future_usage definido para utilização off-session, para que o cartão seja autenticado com o mandato em vigor. A documentação de SetupIntents do Stripe cobre isto. O Stripe Checkout e o Payment Element fazem-no por si na inscrição numa subscrição.

2. Recolha de novo quando muda o acordo

Upgrades, mudanças de preço e novos add-ons alteram o montante. Sempre que possível, faça o cliente confirmar a alteração enquanto está na sua app, para que qualquer autenticação aconteça on-session e não às 3 da manhã no dia da renovação.

3. Cuidado com os trials gratuitos

Se um trial começa sem cobrança, garanta que o cartão é na mesma guardado através de um SetupIntent com autenticação. Caso contrário, a primeira cobrança real, depois do trial, é a primeira vez que o banco vê o mandato. Tratamos os trials em conversão de trial para pago.

4. Trate a Índia à parte

A Índia tem as suas próprias regras para pagamentos recorrentes. A página do Stripe sobre pagamentos recorrentes na Índia explica que os cartões precisam de um e-mandate registado com autenticação por fator adicional, que os clientes recebem uma notificação pré-débito pelo menos 24 horas antes de cada cobrança, e que as cobranças recorrentes acima de INR 15.000 exigem autenticação de cada vez. Se tem clientes indianos, leia essa página; funciona de forma diferente da SCA.

Medir

Acompanhe a autenticação separadamente das outras falhas. Comporta-se de forma diferente e tem a sua própria solução.

• Pedidos de autenticação por mês, por país do cartão.
• Taxa de confirmação: faturas com pedido de autenticação pagas dentro do seu período de tolerância.
• Tempo até à confirmação: do evento até invoice.paid.
• Taxa de alternativa: clientes que confirmaram mudando para um cartão novo.

Se a taxa de confirmação for baixa, olhe primeiro para o email (assunto, clareza, um único botão) e depois para a página no telemóvel.

Checklist

• Os cartões são guardados com autenticação off-session na inscrição.
• invoice.payment_action_required e authentication_required desencadeiam ambos um email de confirmação.
• Os emails “confirm payment” do Stripe estão ativos, ou os seus próprios emails substituem-nos (não ambos).
• A página de confirmação funciona no telemóvel sem palavra-passe.
• As mudanças de preço e os upgrades são confirmados on-session sempre que possível.
• Os emails param assim que a fatura é paga.
• A autenticação é reportada como uma categoria própria.
• Os clientes indianos são tratados segundo as regras do e-mandate.

Como o NoChurn ajuda

O NoChurn trata os pedidos de autenticação como um caso à parte. Quando uma renovação precisa de confirmação, evita novas tentativas inúteis e envia um email de recuperação escrito pela IA, revisto antes do envio e no idioma do cliente, a explicar que o banco quer uma confirmação rápida, com um link para confirmar o pagamento e uma página alojada de atualização do cartão como alternativa. Os dados do cartão ficam no Stripe.

Conecta-se ao Stripe com um clique, ou funciona pela API com a sua própria faturação. O preço depende apenas do MRR, nunca da receita recuperada. Veja pagamentos falhados e preços.