Cobrar subscrições com Redsys no WooCommerce é hoje a via padrão para gerir pagamentos recorrentes em Espanha, porque a Redsys é a plataforma que presta serviço à maioria dos bancos espanhóis (BBVA, Santander, CaixaBank, Sabadell e muitos mais). A chave não está na primeira cobrança, que qualquer gateway sabe fazer, mas na segunda, na terceira e em todas as que vêm depois: renovações cobradas automaticamente, mês após mês, sem que o cliente tenha de voltar a introduzir o cartão. Neste artigo explicamos como a tokenização o torna possível, como se enquadra na norma SCA/PSD2 e por que o Bizum, apesar de ser cómodo, não pode ser usado para recorrências. O objetivo é que montes um modelo de quotas fiável, em que um primeiro pagamento autorizado dê lugar a cobranças posteriores sem fricção.
Subscrições com Redsys no WooCommerce: por que a tokenização muda tudo
Uma cobrança recorrente tem uma exigência particular: o negócio deve poder voltar a cobrar sem que o cliente esteja presente. Isso obriga a guardar de forma segura uma “credencial de pagamento” reutilizável. A Redsys resolve isto com o pagamento por referência, que é o seu nome para a tokenização: no primeiro pagamento não só se cobra, como se solicita ao banco uma referência que representa esse cartão e que fica vinculada ao comércio. Nas renovações, a loja envia apenas essa referência e o valor, e o banco executa a cobrança.
Convém sublinhar uma ideia que muitas vezes passa despercebida: a loja nunca volta a lidar com o número real do cartão. Apenas guarda e reutiliza essa referência, de modo que os dados sensíveis permanecem sempre do lado do banco e da Redsys, não no teu servidor. Isto reduz a tua exposição e simplifica o cumprimento das obrigações de segurança sobre dados de cartão.
O que é o pagamento por referência (tokenização)
A referência é um identificador opaco. Não é o número do cartão, não revela os dados sensíveis do cliente e só serve para esse comércio concreto. Por isso é seguro armazená-la: mesmo que alguém a intercetasse, não a poderia usar noutro sítio nem reconstruir o cartão original. Este mecanismo é o que separa um simples gateway de pagamento de um gateway capaz de sustentar subscrições reais. Sem token, cada renovação exigiria que o cliente voltasse a pagar manualmente, e isso, na prática, mata qualquer modelo de recorrência.
Como funciona a cobrança recorrente com Redsys passo a passo
Para entender bem como funcionam as subscrições com Redsys no WooCommerce, convém separar mentalmente dois momentos muito distintos, porque têm requisitos técnicos e legais diferentes.
O primeiro pagamento: criação da referência
No checkout inicial o cliente está presente. Introduz o cartão no TPV virtual da Redsys e, se o banco o exigir, completa a autenticação reforçada (normalmente um código enviado pela app bancária ou por SMS). Nessa mesma operação, a loja solicita a criação da referência. No final, acontecem duas coisas: foi cobrada a primeira quota e foi guardado o token para o futuro.
As renovações automáticas: cobrança sem fricção
Quando chega a data de renovação, o processo é totalmente desassistido. O WooCommerce dispara a cobrança, envia a referência guardada para a Redsys e o banco debita o valor. O cliente não recebe qualquer formulário, não tem de fazer nada e, se tudo correr bem, nem se apercebe até ver a cobrança no extrato. Quando o banco responde, a Redsys envia à loja uma notificação de confirmação; com ela, o WooCommerce marca a encomenda de renovação como paga e prolonga a subscrição automaticamente. Este é exatamente o comportamento que o guia de subscrições no WooCommerce descreve como imprescindível para qualquer negócio de quotas: que a renovação não dependa da boa memória do cliente.
SCA e PSD2: autenticação reforçada sem quebrar as renovações
A norma europeia PSD2 introduziu a Autenticação Reforçada do Cliente (SCA): em muitos pagamentos eletrónicos o utilizador deve provar quem é com um duplo fator. À primeira vista isto choca com a ideia de uma cobrança desassistida, porque na renovação o cliente não está presente para se autenticar. É aqui que a tokenização bem implementada faz a diferença.
Como as subscrições com Redsys no WooCommerce contornam a SCA de forma segura
A própria PSD2 contempla as operações iniciadas pelo comércio (os chamados MIT, merchant-initiated transactions). A lógica é simples: a autenticação forte é realizada uma vez, no primeiro pagamento com o cliente presente, e esse consentimento fica associado à referência. As renovações posteriores são marcadas como cobranças recorrentes iniciadas pelo comércio, ficando isentas de repetir o duplo fator. Não se está a contornar a segurança: está-se a cumprir a norma no momento certo e a aproveitar a isenção prevista para recorrências. Por isso as subscrições com Redsys no WooCommerce podem ser automáticas e cumprir a norma ao mesmo tempo.
Na prática, isto significa que o peso da autenticação recai na primeira cobrança. Se essa criação for feita corretamente, com o cartão devidamente tokenizado e o consentimento registado, o resto do ciclo de vida da subscrição decorre sem voltar a incomodar o cliente com códigos nem confirmações. Daí que a criação seja o momento mais delicado de todo o processo e aquele que mais convém cuidar.
Por que o Bizum não serve para cobranças recorrentes
O Bizum é rápido, conhecido e com uma excelente taxa de conversão para pagamentos pontuais. Mas foi desenhado precisamente para isso: pagamentos pontuais, um a um, com o utilizador a confirmar no telemóvel. O Bizum não admite tokenização, ou seja, não gera uma referência reutilizável que permita ao comércio voltar a cobrar por sua conta. Sem token não há renovação desassistida possível.
A consequência prática é clara: podes oferecer Bizum para o primeiro pagamento se for cómodo para os teus clientes, mas a renovação de uma subscrição precisa, obrigatoriamente, de um cartão tokenizado através da Redsys. Apresentar o Bizum como método de “subscrição” seria enganador, porque todos os meses exigiria que o cliente confirmasse o pagamento manualmente, e isso já não é uma subscrição: é uma série de compras avulsas que dependem de o cliente se lembrar e querer.
Tabela comparativa: Redsys tokenizado face a outras opções
| Método | Renovação automática | Tokenização | SCA uma só vez | Uso recomendado |
|---|---|---|---|---|
| Redsys (pagamento por referência) | Sim | Sim | Sim, na criação | Subscrições e quotas recorrentes |
| Bizum | Não | Não | Não aplicável | Apenas pagamentos pontuais ou primeira cobrança |
| Domiciliação SEPA | Sim | Mandato, não token de cartão | Não aplicável | Recorrente B2B ou quotas elevadas |
| Cartão internacional (outros gateways) | Sim | Sim | Sim | Vendas fora de Espanha |
Para um negócio espanhol que vende a clientes espanhóis, montar subscrições com Redsys no WooCommerce costuma ser a combinação mais natural: quota baixa, integração direta com o banco de sempre e compatibilidade total com a cobrança recorrente.
Como configurar a cobrança recorrente da Redsys na tua loja
Não entraremos no detalhe técnico de cada entidade para pôr em marcha as subscrições com Redsys no WooCommerce, porque cada banco tem o seu próprio painel, mas convém saber o que pedir e o que procurar para não ter surpresas.
O que pedir ao teu banco
- TPV virtual com pagamento por referência ativado. Não basta um TPV normal; é preciso solicitar explicitamente a modalidade de referência (tokenização). Às vezes chama-se “pagamento por referência” ou “pagamento recorrente”.
- Chave secreta de assinatura (SHA-256). A Redsys assina cada operação; vais precisar dessa chave para que o WooCommerce e o banco se entendam.
- Confirmação de que suportam MIT. É o que permite marcar as renovações como cobranças iniciadas pelo comércio e evitar o duplo fator em cada cobrança.
Testa primeiro no ambiente de teste
A Redsys dispõe de um ambiente de testes independente do real, com as suas próprias chaves. Antes de abrir a cobrança aos clientes convém simular aí uma criação de referência e uma renovação completa, verificando que a assinatura é validada corretamente e que a notificação de confirmação chega à loja. Assim detetas erros de configuração sem arriscar cobranças reais nem deixar subscrições a meio. Lembra-te de que a chave do ambiente de testes e a de produção são diferentes: trocá-las ao passar para o real é um esquecimento habitual.
O que procurar no plugin
Para que as subscrições com Redsys no WooCommerce funcionem sem sobressaltos, o conector que usares deve fazer três coisas bem: criar a referência no primeiro pagamento, guardá-la associada à subscrição e lançar as renovações enviando essa referência com a assinatura correta. EHERO WooCommerce Subscriptions integra a Redsys recorrente de forma nativa, de modo que a tokenização, o ciclo de renovação e a gestão da isenção SCA vêm resolvidos sem plugins intermédios nem remendos. Se quiseres validar a abordagem com base no WooCommerce, a documentação oficial do WooCommerce é uma boa referência do comportamento padrão da plataforma.
Faturação automática das renovações
Uma cobrança recorrente gera, todos os meses, uma obrigação contabilística. Se cada renovação te obrigar a emitir uma fatura manualmente, a poupança de tempo da cobrança automática perde-se na contabilidade. Por isso, quando geres subscrições com Redsys no WooCommerce, faz sentido ligar as cobranças à faturação: quando uma subscrição é renovada e a Redsys confirma a cobrança, a fatura deve ser emitida automaticamente. Documentar cada renovação não é apenas comodidade: é uma obrigação fiscal, e automatizar a fatura evita esquecimentos e concilia os valores com o que foi realmente cobrado pela Redsys. EHERO Woo Holded cobre precisamente essa etapa, sincronizando as encomendas do WooCommerce com o teu sistema de faturação para que as renovações fiquem documentadas sem intervenção manual.
Perguntas frequentes
Posso usar Bizum para cobrar uma subscrição todos os meses?
Não de forma automática. O Bizum não permite tokenizar o cartão, por isso cada cobrança exigiria que o cliente confirmasse o pagamento manualmente. Serve para o primeiro pagamento, não para a renovação.
O cliente tem de se autenticar em cada renovação por causa da SCA?
Não. A autenticação reforçada é feita uma única vez, na criação da referência. As renovações são marcadas como cobranças iniciadas pelo comércio e ficam isentas do duplo fator.
O que acontece se o cartão tokenizado expirar ou o banco rejeitar a cobrança?
A renovação falha e a subscrição fica pendente de pagamento. O ideal é que o sistema volte a tentar a cobrança e avise o cliente para atualizar o cartão antes de suspender o serviço.
Preciso de um TPV virtual especial do meu banco para tokenizar?
Precisas do mesmo TPV da Redsys, mas com a modalidade de pagamento por referência ativada. É um ajuste que o teu banco ativa a pedido; convém confirmá-lo antes de lançar as subscrições.
Conclusão
Montar subscrições com Redsys no WooCommerce não é complicado quando entendes a peça central: a tokenização ou pagamento por referência, que transforma um primeiro pagamento autenticado numa série de renovações automáticas e conformes com a PSD2. O Bizum fica para os pagamentos pontuais; a recorrência vive no cartão tokenizado. Se queres cobrar quotas todos os meses sem fricção, com o respaldo do teu banco espanhol e sem depender de terceiros, dá uma vista de olhos a EHERO WooCommerce Subscriptions: integra a Redsys recorrente de forma nativa e poupa-te a maior dor de cabeça de qualquer negócio de subscrição, que é a cobrança que chega, sem falhas, mês após mês.