{"id":10583,"date":"2026-08-05T10:03:34","date_gmt":"2026-08-05T08:03:34","guid":{"rendered":"https:\/\/consultoriaehero.com\/?p=10583"},"modified":"2026-08-05T10:03:34","modified_gmt":"2026-08-05T08:03:34","slug":"subscricoes-com-redsys-no-woocommerce-guia-2026","status":"publish","type":"post","link":"https:\/\/consultoriaehero.com\/pt\/subscricoes-com-redsys-no-woocommerce-guia-2026\/","title":{"rendered":"Subscri\u00e7\u00f5es com Redsys no WooCommerce: guia 2026"},"content":{"rendered":"

Cobrar subscri\u00e7\u00f5es com Redsys no WooCommerce<\/strong> \u00e9 hoje a via padr\u00e3o para gerir pagamentos recorrentes em Espanha, porque a Redsys \u00e9 a plataforma que presta servi\u00e7o \u00e0 maioria dos bancos espanh\u00f3is (BBVA, Santander, CaixaBank, Sabadell e muitos mais). A chave n\u00e3o est\u00e1 na primeira cobran\u00e7a, que qualquer gateway sabe fazer, mas na segunda, na terceira e em todas as que v\u00eam depois: renova\u00e7\u00f5es cobradas automaticamente, m\u00eas ap\u00f3s m\u00eas, sem que o cliente tenha de voltar a introduzir o cart\u00e3o. Neste artigo explicamos como a tokeniza\u00e7\u00e3o o torna poss\u00edvel, como se enquadra na norma SCA\/PSD2 e por que o Bizum, apesar de ser c\u00f3modo, n\u00e3o pode ser usado para recorr\u00eancias. O objetivo \u00e9 que montes um modelo de quotas fi\u00e1vel, em que um primeiro pagamento autorizado d\u00ea lugar a cobran\u00e7as posteriores sem fric\u00e7\u00e3o.<\/p>\n

\"Cobran\u00e7a<\/figure>\n

Subscri\u00e7\u00f5es com Redsys no WooCommerce: por que a tokeniza\u00e7\u00e3o muda tudo<\/h2>\n

Uma cobran\u00e7a recorrente tem uma exig\u00eancia particular: o neg\u00f3cio deve poder voltar a cobrar sem que o cliente esteja presente. Isso obriga a guardar de forma segura uma “credencial de pagamento” reutiliz\u00e1vel. A Redsys resolve isto com o pagamento por refer\u00eancia<\/strong>, que \u00e9 o seu nome para a tokeniza\u00e7\u00e3o: no primeiro pagamento n\u00e3o s\u00f3 se cobra, como se solicita ao banco uma refer\u00eancia que representa esse cart\u00e3o e que fica vinculada ao com\u00e9rcio. Nas renova\u00e7\u00f5es, a loja envia apenas essa refer\u00eancia e o valor, e o banco executa a cobran\u00e7a.<\/p>\n

Conv\u00e9m sublinhar uma ideia que muitas vezes passa despercebida: a loja nunca volta a lidar com o n\u00famero real do cart\u00e3o. Apenas guarda e reutiliza essa refer\u00eancia, de modo que os dados sens\u00edveis permanecem sempre do lado do banco e da Redsys, n\u00e3o no teu servidor. Isto reduz a tua exposi\u00e7\u00e3o e simplifica o cumprimento das obriga\u00e7\u00f5es de seguran\u00e7a sobre dados de cart\u00e3o.<\/p>\n

O que \u00e9 o pagamento por refer\u00eancia (tokeniza\u00e7\u00e3o)<\/h3>\n

A refer\u00eancia \u00e9 um identificador opaco. N\u00e3o \u00e9 o n\u00famero do cart\u00e3o, n\u00e3o revela os dados sens\u00edveis do cliente e s\u00f3 serve para esse com\u00e9rcio concreto. Por isso \u00e9 seguro armazen\u00e1-la: mesmo que algu\u00e9m a intercetasse, n\u00e3o a poderia usar noutro s\u00edtio nem reconstruir o cart\u00e3o original. Este mecanismo \u00e9 o que separa um simples gateway de pagamento de um gateway capaz de sustentar subscri\u00e7\u00f5es reais. Sem token, cada renova\u00e7\u00e3o exigiria que o cliente voltasse a pagar manualmente, e isso, na pr\u00e1tica, mata qualquer modelo de recorr\u00eancia.<\/p>\n

Como funciona a cobran\u00e7a recorrente com Redsys passo a passo<\/h2>\n

Para entender bem como funcionam as subscri\u00e7\u00f5es com Redsys no WooCommerce, conv\u00e9m separar mentalmente dois momentos muito distintos, porque t\u00eam requisitos t\u00e9cnicos e legais diferentes.<\/p>\n

O primeiro pagamento: cria\u00e7\u00e3o da refer\u00eancia<\/h3>\n

No checkout inicial o cliente est\u00e1 presente. Introduz o cart\u00e3o no TPV virtual da Redsys e, se o banco o exigir, completa a autentica\u00e7\u00e3o refor\u00e7ada (normalmente um c\u00f3digo enviado pela app banc\u00e1ria ou por SMS). Nessa mesma opera\u00e7\u00e3o, a loja solicita a cria\u00e7\u00e3o da refer\u00eancia. No final, acontecem duas coisas: foi cobrada a primeira quota e foi guardado o token para o futuro.<\/p>\n

As renova\u00e7\u00f5es autom\u00e1ticas: cobran\u00e7a sem fric\u00e7\u00e3o<\/h3>\n

Quando chega a data de renova\u00e7\u00e3o, o processo \u00e9 totalmente desassistido. O WooCommerce dispara a cobran\u00e7a, envia a refer\u00eancia guardada para a Redsys e o banco debita o valor. O cliente n\u00e3o recebe qualquer formul\u00e1rio, n\u00e3o tem de fazer nada e, se tudo correr bem, nem se apercebe at\u00e9 ver a cobran\u00e7a no extrato. Quando o banco responde, a Redsys envia \u00e0 loja uma notifica\u00e7\u00e3o de confirma\u00e7\u00e3o; com ela, o WooCommerce marca a encomenda de renova\u00e7\u00e3o como paga e prolonga a subscri\u00e7\u00e3o automaticamente. Este \u00e9 exatamente o comportamento que o guia de subscri\u00e7\u00f5es no WooCommerce<\/a> descreve como imprescind\u00edvel para qualquer neg\u00f3cio de quotas: que a renova\u00e7\u00e3o n\u00e3o dependa da boa mem\u00f3ria do cliente.<\/p>\n

SCA e PSD2: autentica\u00e7\u00e3o refor\u00e7ada sem quebrar as renova\u00e7\u00f5es<\/h2>\n

A norma europeia PSD2 introduziu a Autentica\u00e7\u00e3o Refor\u00e7ada do Cliente (SCA): em muitos pagamentos eletr\u00f3nicos o utilizador deve provar quem \u00e9 com um duplo fator. \u00c0 primeira vista isto choca com a ideia de uma cobran\u00e7a desassistida, porque na renova\u00e7\u00e3o o cliente n\u00e3o est\u00e1 presente para se autenticar. \u00c9 aqui que a tokeniza\u00e7\u00e3o bem implementada faz a diferen\u00e7a.<\/p>\n

Como as subscri\u00e7\u00f5es com Redsys no WooCommerce contornam a SCA de forma segura<\/h3>\n

A pr\u00f3pria PSD2 contempla as opera\u00e7\u00f5es iniciadas pelo com\u00e9rcio (os chamados MIT, merchant-initiated transactions<\/em>). A l\u00f3gica \u00e9 simples: a autentica\u00e7\u00e3o forte \u00e9 realizada uma vez<\/strong>, no primeiro pagamento com o cliente presente, e esse consentimento fica associado \u00e0 refer\u00eancia. As renova\u00e7\u00f5es posteriores s\u00e3o marcadas como cobran\u00e7as recorrentes iniciadas pelo com\u00e9rcio, ficando isentas de repetir o duplo fator. N\u00e3o se est\u00e1 a contornar a seguran\u00e7a: est\u00e1-se a cumprir a norma no momento certo e a aproveitar a isen\u00e7\u00e3o prevista para recorr\u00eancias. Por isso as subscri\u00e7\u00f5es com Redsys no WooCommerce podem ser autom\u00e1ticas e cumprir a norma ao mesmo tempo.<\/p>\n

Na pr\u00e1tica, isto significa que o peso da autentica\u00e7\u00e3o recai na primeira cobran\u00e7a. Se essa cria\u00e7\u00e3o for feita corretamente, com o cart\u00e3o devidamente tokenizado e o consentimento registado, o resto do ciclo de vida da subscri\u00e7\u00e3o decorre sem voltar a incomodar o cliente com c\u00f3digos nem confirma\u00e7\u00f5es. Da\u00ed que a cria\u00e7\u00e3o seja o momento mais delicado de todo o processo e aquele que mais conv\u00e9m cuidar.<\/p>\n

Por que o Bizum n\u00e3o serve para cobran\u00e7as recorrentes<\/h2>\n

O Bizum \u00e9 r\u00e1pido, conhecido e com uma excelente taxa de convers\u00e3o para pagamentos pontuais. Mas foi desenhado precisamente para isso: pagamentos pontuais, um a um, com o utilizador a confirmar no telem\u00f3vel. O Bizum n\u00e3o admite tokeniza\u00e7\u00e3o<\/strong>, ou seja, n\u00e3o gera uma refer\u00eancia reutiliz\u00e1vel que permita ao com\u00e9rcio voltar a cobrar por sua conta. Sem token n\u00e3o h\u00e1 renova\u00e7\u00e3o desassistida poss\u00edvel.<\/p>\n

A consequ\u00eancia pr\u00e1tica \u00e9 clara: podes oferecer Bizum para o primeiro pagamento se for c\u00f3modo para os teus clientes, mas a renova\u00e7\u00e3o de uma subscri\u00e7\u00e3o precisa, obrigatoriamente, de um cart\u00e3o tokenizado atrav\u00e9s da Redsys. Apresentar o Bizum como m\u00e9todo de “subscri\u00e7\u00e3o” seria enganador, porque todos os meses exigiria que o cliente confirmasse o pagamento manualmente, e isso j\u00e1 n\u00e3o \u00e9 uma subscri\u00e7\u00e3o: \u00e9 uma s\u00e9rie de compras avulsas que dependem de o cliente se lembrar e querer.<\/p>\n

Tabela comparativa: Redsys tokenizado face a outras op\u00e7\u00f5es<\/h2>\n
\n\n\n\n\n\n\n\n\n
M\u00e9todo<\/th>\nRenova\u00e7\u00e3o autom\u00e1tica<\/th>\nTokeniza\u00e7\u00e3o<\/th>\nSCA uma s\u00f3 vez<\/th>\nUso recomendado<\/th>\n<\/tr>\n<\/thead>\n
Redsys (pagamento por refer\u00eancia)<\/td>\nSim<\/td>\nSim<\/td>\nSim, na cria\u00e7\u00e3o<\/td>\nSubscri\u00e7\u00f5es e quotas recorrentes<\/td>\n<\/tr>\n
Bizum<\/td>\nN\u00e3o<\/td>\nN\u00e3o<\/td>\nN\u00e3o aplic\u00e1vel<\/td>\nApenas pagamentos pontuais ou primeira cobran\u00e7a<\/td>\n<\/tr>\n
Domicilia\u00e7\u00e3o SEPA<\/td>\nSim<\/td>\nMandato, n\u00e3o token de cart\u00e3o<\/td>\nN\u00e3o aplic\u00e1vel<\/td>\nRecorrente B2B ou quotas elevadas<\/td>\n<\/tr>\n
Cart\u00e3o internacional (outros gateways)<\/td>\nSim<\/td>\nSim<\/td>\nSim<\/td>\nVendas fora de Espanha<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

Para um neg\u00f3cio espanhol que vende a clientes espanh\u00f3is, montar subscri\u00e7\u00f5es com Redsys no WooCommerce costuma ser a combina\u00e7\u00e3o mais natural: quota baixa, integra\u00e7\u00e3o direta com o banco de sempre e compatibilidade total com a cobran\u00e7a recorrente.<\/p>\n

Como configurar a cobran\u00e7a recorrente da Redsys na tua loja<\/h2>\n

N\u00e3o entraremos no detalhe t\u00e9cnico de cada entidade para p\u00f4r em marcha as subscri\u00e7\u00f5es com Redsys no WooCommerce, porque cada banco tem o seu pr\u00f3prio painel, mas conv\u00e9m saber o que pedir e o que procurar para n\u00e3o ter surpresas.<\/p>\n

O que pedir ao teu banco<\/h3>\n