{"id":10581,"date":"2026-08-05T10:03:13","date_gmt":"2026-08-05T08:03:13","guid":{"rendered":"https:\/\/consultoriaehero.com\/?p=10581"},"modified":"2026-08-05T10:03:13","modified_gmt":"2026-08-05T08:03:13","slug":"subscricions-con-redsys-en-woocommerce-guia-2026","status":"publish","type":"post","link":"https:\/\/consultoriaehero.com\/gl\/subscricions-con-redsys-en-woocommerce-guia-2026\/","title":{"rendered":"Subscrici\u00f3ns con Redsys en WooCommerce: gu\u00eda 2026"},"content":{"rendered":"

Cobrar subscrici\u00f3ns con Redsys en WooCommerce<\/strong> \u00e9 hoxe a v\u00eda est\u00e1ndar para xestionar pagos recorrentes en Espa\u00f1a, porque Redsys \u00e9 a plataforma que d\u00e1 servizo \u00e1 maior\u00eda dos bancos espa\u00f1ois (BBVA, Santander, CaixaBank, Sabadell e moitos m\u00e1is). A clave non est\u00e1 no primeiro cobro, que calquera pasarela sabe facer, sen\u00f3n no segundo, no terceiro e en todos os que ve\u00f1en despois: renovaci\u00f3ns que se cobran soas, mes tras mes, sen que o cliente te\u00f1a que volver introducir a s\u00faa tarxeta. Neste artigo explic\u00e1mosche como o fai posible a tokenizaci\u00f3n, como encaixa coa normativa SCA\/PSD2 e por que Bizum, malia ser c\u00f3modo, non pode usarse para o recorrente. O obxectivo \u00e9 que montes un modelo de cotas fiable, no que un primeiro pagamento autorizado dea p\u00e9 a cobros posteriores sen fricci\u00f3n.<\/p>\n

\"Cobro<\/figure>\n

Subscrici\u00f3ns con Redsys en WooCommerce: por que a tokenizaci\u00f3n o cambia todo<\/h2>\n

Un cobro recorrente ten unha esixencia particular: o negocio debe poder volver cobrar sen que o cliente estea presente. Iso obriga a gardar de forma segura unha “credencial de pagamento” reutilizable. Redsys resolve isto co pagamento por referencia<\/strong>, que \u00e9 o seu nome para a tokenizaci\u00f3n: no primeiro pagamento non s\u00f3 se cobra, sen\u00f3n que se solicita ao banco unha referencia que representa esa tarxeta e que queda vinculada ao comercio. Nas renovaci\u00f3ns, a tenda env\u00eda unicamente esa referencia e o importe, e o banco executa o cargo.<\/p>\n

Conv\u00e9n subli\u00f1ar unha idea que a mi\u00fado se pasa por alto: a tenda nunca volve manexar o n\u00famero real da tarxeta. S\u00f3 garda e reutiliza esa referencia, de modo que os datos sensibles permanecen sempre do lado do banco e de Redsys, non no teu servidor. Isto reduce a t\u00faa exposici\u00f3n e simplifica o cumprimento das obrigas de seguridade sobre datos de tarxeta.<\/p>\n

Que \u00e9 o pagamento por referencia (tokenizaci\u00f3n)<\/h3>\n

A referencia \u00e9 un identificador opaco. Non \u00e9 o n\u00famero da tarxeta, non revela os datos sensibles do cliente e s\u00f3 serve para ese comercio concreto. Por iso \u00e9 seguro almacenala: a\u00ednda que algu\u00e9n a interceptase, non poder\u00eda usala noutro sitio nin reconstru\u00edr a tarxeta orixinal. Este mecanismo \u00e9 o que separa unha simple pasarela de pagamento dunha pasarela capaz de soster subscrici\u00f3ns reais. Sen token, cada renovaci\u00f3n esixir\u00eda que o cliente volvese pagar a man, e iso, na pr\u00e1ctica, mata calquera modelo de recorrencia.<\/p>\n

Como funciona o cobro recorrente con Redsys paso a paso<\/h2>\n

Para entender ben como funcionan as subscrici\u00f3ns con Redsys en WooCommerce, conv\u00e9n separar mentalmente dous momentos moi distintos, porque te\u00f1en requisitos t\u00e9cnicos e legais diferentes.<\/p>\n

O primeiro pagamento: alta da referencia<\/h3>\n

No checkout inicial o cliente si est\u00e1 presente. Introduce a s\u00faa tarxeta no TPV virtual de Redsys e, se o seu banco o pide, completa a autenticaci\u00f3n reforzada (normalmente un c\u00f3digo enviado pola app bancaria ou por SMS). Nesa mesma operaci\u00f3n, a tenda solicita a alta da referencia. Ao rematar, ocorren d\u00faas cousas: cobrouse a primeira cota e gardouse o token para o futuro.<\/p>\n

As renovaci\u00f3ns autom\u00e1ticas: cobro sen fricci\u00f3n<\/h3>\n

Cando chega a data de renovaci\u00f3n, o proceso \u00e9 totalmente desatendido. WooCommerce dispara o cobro, env\u00eda a referencia gardada a Redsys e o banco carga o importe. O cliente non recibe ning\u00fan formulario, non ten que facer nada e, se todo vai ben, nin se entera ata que ve o cargo no seu extracto. Cando o banco responde, Redsys env\u00eda \u00e1 tenda unha notificaci\u00f3n de confirmaci\u00f3n; con ela, WooCommerce marca o pedido de renovaci\u00f3n como pagado e prolonga a subscrici\u00f3n de forma autom\u00e1tica. Este \u00e9 exactamente o comportamento que a gu\u00eda de subscrici\u00f3ns en WooCommerce<\/a> describe como imprescindible para calquera negocio de cotas: que a renovaci\u00f3n non dependa da boa memoria do cliente.<\/p>\n

SCA e PSD2: autenticaci\u00f3n reforzada sen romper as renovaci\u00f3ns<\/h2>\n

A normativa europea PSD2 introduciu a Autenticaci\u00f3n Reforzada de Cliente (SCA): en moitos pagamentos electr\u00f3nicos o usuario debe demostrar quen \u00e9 cun dobre factor. A primeira vista isto choca coa idea dun cobro desatendido, porque na renovaci\u00f3n o cliente non est\u00e1 diante para autenticarse. Aqu\u00ed \u00e9 onde a tokenizaci\u00f3n ben implementada marca a diferenza.<\/p>\n

Como as subscrici\u00f3ns con Redsys en WooCommerce sortean o SCA de forma segura<\/h3>\n

A propia PSD2 contempla as operaci\u00f3ns iniciadas polo comercio (os chamados MIT, merchant-initiated transactions<\/em>). A l\u00f3xica \u00e9 sinxela: a autenticaci\u00f3n forte real\u00edzase unha vez<\/strong>, no primeiro pagamento co cliente presente, e ese consentimento queda asociado \u00e1 referencia. As renovaci\u00f3ns posteriores m\u00e1rcanse como cargos recorrentes iniciados polo comercio, quedando exentas de repetir o dobre factor. Non se est\u00e1 saltando a seguridade: estase cumprindo a norma no momento correcto e aproveitando a exenci\u00f3n prevista para o recorrente. Por iso as subscrici\u00f3ns con Redsys en WooCommerce poden ser autom\u00e1ticas e cumprir a normativa \u00e1 vez.<\/p>\n

Na pr\u00e1ctica, isto significa que a carga da autenticaci\u00f3n recae no primeiro cobro. Se esa alta se fai ben, coa tarxeta correctamente tokenizada e o consentimento rexistrado, o resto do ciclo de vida da subscrici\u00f3n transcorre sen volver molestar o cliente con c\u00f3digos nin confirmaci\u00f3ns. De a\u00ed que a alta sexa o momento m\u00e1is delicado de todo o proceso e o que m\u00e1is conv\u00e9n coidar.<\/p>\n

Por que Bizum non serve para cobros recorrentes<\/h2>\n

Bizum \u00e9 r\u00e1pido, co\u00f1ecido e cunha excelente taxa de conversi\u00f3n para pagamentos puntuais. Pero est\u00e1 dese\u00f1ado precisamente para iso: pagamentos puntuais, un a un, co usuario confirmando no seu m\u00f3bil. Bizum non admite tokenizaci\u00f3n<\/strong>, \u00e9 dicir, non xera unha referencia reutilizable que permita ao comercio volver cobrar pola s\u00faa conta. Sen token non hai renovaci\u00f3n desatendida posible.<\/p>\n

A consecuencia pr\u00e1ctica \u00e9 clara: podes ofrecer Bizum para o primeiro pagamento se aos teus clientes lles resulta c\u00f3modo, pero a renovaci\u00f3n dunha subscrici\u00f3n necesita, si ou si, unha tarxeta tokenizada a trav\u00e9s de Redsys. Presentar Bizum como m\u00e9todo de “subscrici\u00f3n” ser\u00eda enganoso, porque cada mes esixir\u00eda ao cliente confirmar o pagamento manualmente, e iso xa non \u00e9 unha subscrici\u00f3n: \u00e9 unha serie de compras soltas que dependen de que o cliente se acorde e queira.<\/p>\n

T\u00e1boa comparativa: Redsys tokenizado fronte a outras opci\u00f3ns<\/h2>\n
\n\n\n\n\n\n\n\n\n
M\u00e9todo<\/th>\nRenovaci\u00f3n autom\u00e1tica<\/th>\nTokenizaci\u00f3n<\/th>\nSCA unha soa vez<\/th>\nUso recomendado<\/th>\n<\/tr>\n<\/thead>\n
Redsys (pagamento por referencia)<\/td>\nSi<\/td>\nSi<\/td>\nSi, na alta<\/td>\nSubscrici\u00f3ns e cotas recorrentes<\/td>\n<\/tr>\n
Bizum<\/td>\nNon<\/td>\nNon<\/td>\nNon aplica<\/td>\nS\u00f3 pagamentos puntuais ou primeiro cobro<\/td>\n<\/tr>\n
Domiciliaci\u00f3n SEPA<\/td>\nSi<\/td>\nMandato, non token de tarxeta<\/td>\nNon aplica<\/td>\nRecorrente B2B ou cotas grandes<\/td>\n<\/tr>\n
Tarxeta internacional (outras pasarelas)<\/td>\nSi<\/td>\nSi<\/td>\nSi<\/td>\nVendas f\u00f3ra de Espa\u00f1a<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

Para un negocio espa\u00f1ol que vende a clientes espa\u00f1ois, montar subscrici\u00f3ns con Redsys en WooCommerce adoita ser a combinaci\u00f3n m\u00e1is natural: cota baixa, integraci\u00f3n directa co banco de sempre e compatibilidade total co cobro recorrente.<\/p>\n

Como configurar o cobro recorrente de Redsys na t\u00faa tenda<\/h2>\n

Non entraremos no detalle t\u00e9cnico de cada entidade para po\u00f1er en marcha as subscrici\u00f3ns con Redsys en WooCommerce, porque cada banco ten o seu propio panel, pero si conv\u00e9n saber que pedir e que buscar para non levar sorpresas.<\/p>\n

Que pedir ao teu banco<\/h3>\n