{"id":10577,"date":"2026-08-05T10:02:23","date_gmt":"2026-08-05T08:02:23","guid":{"rendered":"https:\/\/consultoriaehero.com\/?p=10577"},"modified":"2026-08-05T10:02:23","modified_gmt":"2026-08-05T08:02:23","slug":"subscriptions-with-redsys-in-woocommerce-guide-2026","status":"publish","type":"post","link":"https:\/\/consultoriaehero.com\/en\/subscriptions-with-redsys-in-woocommerce-guide-2026\/","title":{"rendered":"Subscriptions with Redsys in WooCommerce: guide 2026"},"content":{"rendered":"

Charging subscriptions with Redsys in WooCommerce<\/strong> is now the standard way to manage recurring payments in Spain, because Redsys is the platform used by most Spanish banks (BBVA, Santander, CaixaBank, Sabadell, and many more). The key is not the first charge, which any gateway can handle, but the second, the third, and all the ones after that: renewals that are charged automatically, month after month, without the customer having to enter their card again. In this article we explain how tokenization makes this possible, how it fits with SCA\/PSD2 regulations, and why Bizum, despite being convenient, cannot be used for recurring payments. The goal is for you to set up a reliable subscription model, where an authorized first payment enables subsequent charges without friction.<\/p>\n

\"Recurring<\/figure>\n

Subscriptions with Redsys in WooCommerce: why tokenization changes everything<\/h2>\n

A recurring charge has a particular requirement: the business must be able to charge again without the customer being present. That means storing a reusable “payment credential” securely. Redsys solves this with payment by reference<\/strong>, which is its name for tokenization: on the first payment, it not only charges the card, but also requests a reference from the bank that represents that card and is linked to the merchant. On renewals, the store sends only that reference and the amount, and the bank processes the charge.<\/p>\n

It is worth emphasizing an idea that is often overlooked: the store never handles the real card number again. It only stores and reuses that reference, so sensitive data always remains on the bank\u2019s and Redsys\u2019 side, not on your server. This reduces your exposure and simplifies compliance with card-data security obligations.<\/p>\n

What payment by reference is (tokenization)<\/h3>\n

The reference is an opaque identifier. It is not the card number, it does not reveal the customer\u2019s sensitive data, and it only works for that specific merchant. That is why it is safe to store: even if someone intercepted it, they could not use it elsewhere or reconstruct the original card. This mechanism is what separates a simple payment gateway from one capable of supporting real subscriptions. Without a token, every renewal would require the customer to pay manually again, and in practice that kills any recurring model.<\/p>\n

How recurring charging with Redsys works step by step<\/h2>\n

To understand how subscriptions with Redsys in WooCommerce work, it helps to mentally separate two very different moments, because they have different technical and legal requirements.<\/p>\n

The first payment: setting up the reference<\/h3>\n

At the initial checkout, the customer is present. They enter their card in Redsys\u2019 virtual POS and, if their bank requires it, complete strong authentication (usually a code sent through the banking app or by SMS). In that same operation, the store requests the reference to be created. At the end, two things have happened: the first installment has been charged and the token has been saved for the future.<\/p>\n

Automatic renewals: charging without friction<\/h3>\n

When the renewal date arrives, the process is fully unattended. WooCommerce triggers the charge, sends the saved reference to Redsys, and the bank charges the amount. The customer receives no form, has to do nothing, and if everything goes well, they may not even notice until they see the charge on their statement. When the bank responds, Redsys sends the store a confirmation notification; with that, WooCommerce marks the renewal order as paid and extends the subscription automatically. This is exactly the behavior that the WooCommerce subscriptions guide<\/a> describes as essential for any subscription business: the renewal should not depend on the customer\u2019s memory.<\/p>\n

SCA and PSD2: strong authentication without breaking renewals<\/h2>\n

The European PSD2 regulation introduced Strong Customer Authentication (SCA): in many electronic payments, the user must prove who they are with two factors. At first glance, this seems to conflict with the idea of an unattended charge, because on renewal the customer is not there to authenticate. This is where properly implemented tokenization makes the difference.<\/p>\n

How subscriptions with Redsys in WooCommerce safely bypass SCA<\/h3>\n

PSD2 itself covers merchant-initiated transactions (MITs). The logic is simple: strong authentication is performed once<\/strong>, on the first payment with the customer present, and that consent is associated with the reference. Subsequent renewals are marked as recurring charges initiated by the merchant, and are exempt from repeating the second factor. This is not bypassing security: it is complying with the rule at the right moment and taking advantage of the exemption provided for recurring payments. That is why subscriptions with Redsys in WooCommerce can be both automatic and compliant.<\/p>\n

In practice, this means the authentication burden falls on the first charge. If that setup is done correctly, with the card properly tokenized and consent recorded, the rest of the subscription lifecycle proceeds without bothering the customer again with codes or confirmations. That is why the initial setup is the most delicate moment in the whole process and the one that deserves the most care.<\/p>\n

Why Bizum is not suitable for recurring charges<\/h2>\n

Bizum is fast, well known, and has an excellent conversion rate for one-off payments. But it is designed precisely for that: one-off payments, one by one, with the user confirming on their phone. Bizum does not support tokenization<\/strong>, meaning it does not generate a reusable reference that allows the merchant to charge again on their own. Without a token, unattended renewals are not possible.<\/p>\n

The practical consequence is clear: you can offer Bizum for the first payment if your customers find it convenient, but renewing a subscription requires, yes or yes, a tokenized card through Redsys. Presenting Bizum as a “subscription” method would be misleading, because every month it would require the customer to confirm the payment manually, and that is no longer a subscription: it is a series of separate purchases that depend on the customer remembering and wanting to do it.<\/p>\n

Comparison table: tokenized Redsys versus other options<\/h2>\n
\n\n\n\n\n\n\n\n\n
Method<\/th>\nAutomatic renewal<\/th>\nTokenization<\/th>\nSCA once<\/th>\nRecommended use<\/th>\n<\/tr>\n<\/thead>\n
Redsys (payment by reference)<\/td>\nYes<\/td>\nYes<\/td>\nYes, at signup<\/td>\nSubscriptions and recurring fees<\/td>\n<\/tr>\n
Bizum<\/td>\nNo<\/td>\nNo<\/td>\nNot applicable<\/td>\nOnly one-off payments or first charge<\/td>\n<\/tr>\n
SEPA direct debit<\/td>\nYes<\/td>\nMandate, not card token<\/td>\nNot applicable<\/td>\nRecurring B2B or large fees<\/td>\n<\/tr>\n
International card (other gateways)<\/td>\nYes<\/td>\nYes<\/td>\nYes<\/td>\nSales outside Spain<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/figure>\n

For a Spanish business selling to Spanish customers, setting up subscriptions with Redsys in WooCommerce is usually the most natural combination: low fee, direct integration with the usual bank, and full compatibility with recurring charging.<\/p>\n

How to configure Redsys recurring charging in your store<\/h2>\n

We will not go into the technical details of each bank to set up subscriptions with Redsys in WooCommerce, because each bank has its own dashboard, but it is useful to know what to ask for and what to look for so you are not surprised.<\/p>\n

What to ask your bank for<\/h3>\n