Cobrar subscricións con Redsys en WooCommerce é hoxe a vía estándar para xestionar pagos recorrentes en España, porque Redsys é a plataforma que dá servizo á maioría dos bancos españois (BBVA, Santander, CaixaBank, Sabadell e moitos máis). A clave non está no primeiro cobro, que calquera pasarela sabe facer, senón no segundo, no terceiro e en todos os que veñen despois: renovacións que se cobran soas, mes tras mes, sen que o cliente teña que volver introducir a súa tarxeta. Neste artigo explicámosche como o fai posible a tokenización, como encaixa coa normativa SCA/PSD2 e por que Bizum, malia ser cómodo, non pode usarse para o recorrente. O obxectivo é que montes un modelo de cotas fiable, no que un primeiro pagamento autorizado dea pé a cobros posteriores sen fricción.
Subscricións con Redsys en WooCommerce: por que a tokenización o cambia todo
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, que é o seu nome para a tokenización: no primeiro pagamento non só se cobra, senón que se solicita ao banco unha referencia que representa esa tarxeta e que queda vinculada ao comercio. Nas renovacións, a tenda envía unicamente esa referencia e o importe, e o banco executa o cargo.
Convén subliñar unha idea que a miúdo se pasa por alto: a tenda nunca volve manexar o número real da tarxeta. Só 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úa exposición e simplifica o cumprimento das obrigas de seguridade sobre datos de tarxeta.
Que é o pagamento por referencia (tokenización)
A referencia é un identificador opaco. Non é o número da tarxeta, non revela os datos sensibles do cliente e só serve para ese comercio concreto. Por iso é seguro almacenala: aínda que alguén a interceptase, non podería usala noutro sitio nin reconstruír a tarxeta orixinal. Este mecanismo é o que separa unha simple pasarela de pagamento dunha pasarela capaz de soster subscricións reais. Sen token, cada renovación esixiría que o cliente volvese pagar a man, e iso, na práctica, mata calquera modelo de recorrencia.
Como funciona o cobro recorrente con Redsys paso a paso
Para entender ben como funcionan as subscricións con Redsys en WooCommerce, convén separar mentalmente dous momentos moi distintos, porque teñen requisitos técnicos e legais diferentes.
O primeiro pagamento: alta da referencia
No checkout inicial o cliente si está presente. Introduce a súa tarxeta no TPV virtual de Redsys e, se o seu banco o pide, completa a autenticación reforzada (normalmente un código enviado pola app bancaria ou por SMS). Nesa mesma operación, a tenda solicita a alta da referencia. Ao rematar, ocorren dúas cousas: cobrouse a primeira cota e gardouse o token para o futuro.
As renovacións automáticas: cobro sen fricción
Cando chega a data de renovación, o proceso é totalmente desatendido. WooCommerce dispara o cobro, envía a referencia gardada a Redsys e o banco carga o importe. O cliente non recibe ningún 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ía á tenda unha notificación de confirmación; con ela, WooCommerce marca o pedido de renovación como pagado e prolonga a subscrición de forma automática. Este é exactamente o comportamento que a guía de subscricións en WooCommerce describe como imprescindible para calquera negocio de cotas: que a renovación non dependa da boa memoria do cliente.
SCA e PSD2: autenticación reforzada sen romper as renovacións
A normativa europea PSD2 introduciu a Autenticación Reforzada de Cliente (SCA): en moitos pagamentos electrónicos o usuario debe demostrar quen é cun dobre factor. A primeira vista isto choca coa idea dun cobro desatendido, porque na renovación o cliente non está diante para autenticarse. Aquí é onde a tokenización ben implementada marca a diferenza.
Como as subscricións con Redsys en WooCommerce sortean o SCA de forma segura
A propia PSD2 contempla as operacións iniciadas polo comercio (os chamados MIT, merchant-initiated transactions). A lóxica é sinxela: a autenticación forte realízase unha vez, no primeiro pagamento co cliente presente, e ese consentimento queda asociado á referencia. As renovacións posteriores márcanse como cargos recorrentes iniciados polo comercio, quedando exentas de repetir o dobre factor. Non se está saltando a seguridade: estase cumprindo a norma no momento correcto e aproveitando a exención prevista para o recorrente. Por iso as subscricións con Redsys en WooCommerce poden ser automáticas e cumprir a normativa á vez.
Na práctica, isto significa que a carga da autenticación 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ón transcorre sen volver molestar o cliente con códigos nin confirmacións. De aí que a alta sexa o momento máis delicado de todo o proceso e o que máis convén coidar.
Por que Bizum non serve para cobros recorrentes
Bizum é rápido, coñecido e cunha excelente taxa de conversión para pagamentos puntuais. Pero está deseñado precisamente para iso: pagamentos puntuais, un a un, co usuario confirmando no seu móbil. Bizum non admite tokenización, é dicir, non xera unha referencia reutilizable que permita ao comercio volver cobrar pola súa conta. Sen token non hai renovación desatendida posible.
A consecuencia práctica é clara: podes ofrecer Bizum para o primeiro pagamento se aos teus clientes lles resulta cómodo, pero a renovación dunha subscrición necesita, si ou si, unha tarxeta tokenizada a través de Redsys. Presentar Bizum como método de “subscrición” sería enganoso, porque cada mes esixiría ao cliente confirmar o pagamento manualmente, e iso xa non é unha subscrición: é unha serie de compras soltas que dependen de que o cliente se acorde e queira.
Táboa comparativa: Redsys tokenizado fronte a outras opcións
| Método | Renovación automática | Tokenización | SCA unha soa vez | Uso recomendado |
|---|---|---|---|---|
| Redsys (pagamento por referencia) | Si | Si | Si, na alta | Subscricións e cotas recorrentes |
| Bizum | Non | Non | Non aplica | Só pagamentos puntuais ou primeiro cobro |
| Domiciliación SEPA | Si | Mandato, non token de tarxeta | Non aplica | Recorrente B2B ou cotas grandes |
| Tarxeta internacional (outras pasarelas) | Si | Si | Si | Vendas fóra de España |
Para un negocio español que vende a clientes españois, montar subscricións con Redsys en WooCommerce adoita ser a combinación máis natural: cota baixa, integración directa co banco de sempre e compatibilidade total co cobro recorrente.
Como configurar o cobro recorrente de Redsys na túa tenda
Non entraremos no detalle técnico de cada entidade para poñer en marcha as subscricións con Redsys en WooCommerce, porque cada banco ten o seu propio panel, pero si convén saber que pedir e que buscar para non levar sorpresas.
Que pedir ao teu banco
- TPV virtual con pagamento por referencia activado. Non abonda cun TPV normal; hai que solicitar explicitamente a modalidade de referencia (tokenización). Ás veces chámase “pagamento por referencia” ou “pagamento recorrente”.
- Clave secreta de sinatura (SHA-256). Redsys asina cada operación; necesitarás esa clave para que WooCommerce e o banco se entendan.
- Confirmación de que soportan MIT. É o que permite marcar as renovacións como cargos iniciados polo comercio e evitar o dobre factor en cada cobro.
Proba primeiro no contorno de test
Redsys dispón dun contorno de probas independente do real, coas súas propias claves. Antes de abrir o cobro a clientes convén simular aí un alta de referencia e unha renovación completa, comprobando que a sinatura se valida correctamente e que a notificación de confirmación chega á tenda. Así detectas erros de configuración sen arriscar cobros reais nin deixar subscricións a medias. Lembra que a clave do contorno de probas e a de produción son distintas: cambialas ao pasar a real é un esquecemento habitual.
Que buscar no plugin
Para que as subscricións con Redsys en WooCommerce funcionen sen sobresaltos, o conector que uses debe facer tres cousas ben: dar de alta a referencia no primeiro pagamento, gardala asociada á subscrición e lanzar as renovacións enviando esa referencia coa sinatura correcta. EHERO WooCommerce Subscriptions integra Redsys recorrente de forma nativa, de modo que a tokenización, o ciclo de renovación e o manexo da exención SCA veñen resoltos sen plugins intermedios nin parches. Se queres validar o plantexamento sobre a base de WooCommerce, a documentación oficial de WooCommerce é unha boa referencia do comportamento estándar da plataforma.
Facturación automática das renovacións
Un cobro recorrente xera, cada mes, unha obriga contable. Se cada renovación te obriga a emitir unha factura a man, o aforro de tempo do cobro automático pérdese na xestoría. Por iso, cando xestionas subscricións con Redsys en WooCommerce, ten sentido ligar os cobros coa facturación: cando unha subscrición se renova e Redsys confirma o cargo, a factura debería emitirse soa. Documentar cada renovación non é só comodidade: é unha obriga fiscal, e automatizar a factura evita esquecementos e cadra os importes co realmente cobrado por Redsys. EHERO Woo Holded cobre xustamente ese tramo, sincronizando os pedidos de WooCommerce co teu sistema de facturación para que as renovacións queden documentadas sen intervención manual.
Preguntas frecuentes
Podo usar Bizum para cobrar unha subscrición cada mes?
Non de forma automática. Bizum non permite tokenizar a tarxeta, así que cada cobro esixiría que o cliente confirmase o pagamento a man. Serve para o primeiro pagamento, non para a renovación.
O cliente ten que autenticarse en cada renovación polo SCA?
Non. A autenticación reforzada realízase unha soa vez, na alta da referencia. As renovacións márcanse como cargos iniciados polo comercio e quedan exentas do dobre factor.
Que pasa se a tarxeta tokenizada caduca ou o banco rexeita o cargo?
A renovación falla e a subscrición queda pendente de pagamento. O ideal é que o sistema reintente o cobro e avise o cliente para que actualice a súa tarxeta antes de suspender o servizo.
Necesito un TPV virtual especial do meu banco para tokenizar?
Necesitas o mesmo TPV de Redsys, pero coa modalidade de pagamento por referencia habilitada. É un axuste que o teu banco activa por petición; convén confirmalo antes de lanzar as subscricións.
Conclusión
Montar subscricións con Redsys en WooCommerce non é complicado cando entendes a peza central: a tokenización ou pagamento por referencia, que converte un primeiro pagamento autenticado nunha serie de renovacións automáticas e conformes coa PSD2. Bizum queda para os pagamentos puntuais; a recorrencia vive na tarxeta tokenizada. Se queres cobrar cotas cada mes sen fricción, co respaldo do teu banco español e sen depender de terceiros, bótalle un ollo a EHERO WooCommerce Subscriptions: integra Redsys recorrente de forma nativa e afórrache o maior dor de cabeza de calquera negocio de subscrición, que é o cobro que chega, sen fallos, mes tras mes.