Encaisser des abonnements avec Redsys dans WooCommerce est aujourd’hui la voie standard pour gérer les paiements récurrents en Espagne, car Redsys est la plateforme qui dessert la majorité des banques espagnoles (BBVA, Santander, CaixaBank, Sabadell et bien d’autres). L’essentiel ne réside pas dans le premier encaissement, que n’importe quelle passerelle sait effectuer, mais dans le deuxième, le troisième et tous ceux qui suivent : des renouvellements prélevés automatiquement, mois après mois, sans que le client ait à ressaisir sa carte. Dans cet article, nous vous expliquons comment la tokenisation rend cela possible, comment elle s’articule avec la réglementation SCA/PSD2 et pourquoi Bizum, malgré sa praticité, ne peut pas être utilisé pour le récurrent. L’objectif est que vous mettiez en place un modèle d’abonnement fiable, dans lequel un premier paiement autorisé ouvre la voie à des prélèvements ultérieurs sans friction.
Abonnements avec Redsys dans WooCommerce : pourquoi la tokenisation change tout
Un encaissement récurrent a une exigence particulière : l’entreprise doit pouvoir prélever à nouveau sans que le client soit présent. Cela impose de conserver de manière sécurisée une « crédential de paiement » réutilisable. Redsys résout cela avec le paiement par référence, qui est son nom pour la tokenisation : lors du premier paiement, on ne fait pas que débiter, on demande aussi à la banque une référence qui représente cette carte et qui reste liée au commerçant. Lors des renouvellements, la boutique envoie uniquement cette référence et le montant, et la banque exécute le débit.
Il convient de souligner une idée souvent négligée : la boutique ne manipule jamais à nouveau le numéro réel de la carte. Elle ne stocke et ne réutilise que cette référence, de sorte que les données sensibles restent toujours du côté de la banque et de Redsys, et non sur votre serveur. Cela réduit votre exposition et simplifie le respect des obligations de sécurité relatives aux données de carte.
Qu’est-ce que le paiement par référence (tokenisation)
La référence est un identifiant opaque. Ce n’est pas le numéro de la carte, elle ne révèle pas les données sensibles du client et elle ne sert que pour ce commerçant précis. C’est pourquoi il est sûr de la stocker : même si quelqu’un l’interceptait, il ne pourrait pas l’utiliser ailleurs ni reconstruire la carte d’origine. Ce mécanisme est ce qui distingue une simple passerelle de paiement d’une passerelle capable de prendre en charge de véritables abonnements. Sans token, chaque renouvellement exigerait que le client paie à la main, et cela, en pratique, tue tout modèle récurrent.
Comment fonctionne l’encaissement récurrent avec Redsys, étape par étape
Pour bien comprendre comment fonctionnent les abonnements avec Redsys dans WooCommerce, il est utile de séparer mentalement deux moments très différents, car ils ont des exigences techniques et juridiques distinctes.
Le premier paiement : création de la référence
Lors du checkout initial, le client est bien présent. Il saisit sa carte dans le TPV virtuel de Redsys et, si sa banque l’exige, complète l’authentification renforcée (généralement un code envoyé par l’application bancaire ou par SMS). Dans cette même opération, la boutique demande la création de la référence. À la fin, deux choses se produisent : la première échéance a été encaissée et le token a été enregistré pour l’avenir.
Les renouvellements automatiques : encaissement sans friction
Lorsque la date de renouvellement arrive, le processus est entièrement automatisé. WooCommerce déclenche le paiement, envoie la référence enregistrée à Redsys et la banque débite le montant. Le client ne reçoit aucun formulaire, n’a rien à faire et, si tout se passe bien, ne s’en rend compte qu’en voyant le débit sur son relevé. Lorsque la banque répond, Redsys envoie à la boutique une notification de confirmation ; avec elle, WooCommerce marque la commande de renouvellement comme payée et prolonge automatiquement l’abonnement. C’est exactement le comportement que le guide des abonnements dans WooCommerce décrit comme indispensable pour toute activité d’abonnement : que le renouvellement ne dépende pas de la bonne mémoire du client.
SCA et PSD2 : authentification renforcée sans casser les renouvellements
La réglementation européenne PSD2 a introduit l’Authentification Forte du Client (SCA) : dans de nombreux paiements électroniques, l’utilisateur doit prouver son identité avec un double facteur. À première vue, cela entre en conflit avec l’idée d’un encaissement automatisé, car lors du renouvellement le client n’est pas là pour s’authentifier. C’est ici qu’une tokenisation bien mise en œuvre fait la différence.
Comment les abonnements avec Redsys dans WooCommerce contournent le SCA de manière sécurisée
La PSD2 elle-même prévoit les opérations initiées par le commerçant (les fameux MIT, merchant-initiated transactions). La logique est simple : l’authentification forte est réalisée une seule fois, lors du premier paiement avec le client présent, et ce consentement reste associé à la référence. Les renouvellements ultérieurs sont marqués comme des débits récurrents initiés par le commerçant, et sont donc exemptés de la répétition du double facteur. Il ne s’agit pas de contourner la sécurité : il s’agit de respecter la norme au bon moment et de profiter de l’exemption prévue pour le récurrent. C’est pourquoi les abonnements avec Redsys dans WooCommerce peuvent être automatiques tout en restant conformes à la réglementation.
En pratique, cela signifie que la charge de l’authentification repose sur le premier encaissement. Si cette création est bien faite, avec la carte correctement tokenisée et le consentement enregistré, le reste du cycle de vie de l’abonnement se déroule sans avoir à solliciter à nouveau le client avec des codes ou des confirmations. D’où le fait que la création soit le moment le plus délicat de tout le processus et celui qu’il convient le plus de soigner.
Pourquoi Bizum ne convient pas aux paiements récurrents
Bizum est rapide, connu et affiche un excellent taux de conversion pour les paiements ponctuels. Mais il est précisément conçu pour cela : des paiements ponctuels, un par un, avec l’utilisateur qui confirme sur son mobile. Bizum ne prend pas en charge la tokenisation, c’est-à-dire qu’il ne génère pas de référence réutilisable permettant au commerçant de prélever à nouveau de son propre chef. Sans token, pas de renouvellement automatisé possible.
La conséquence pratique est claire : vous pouvez proposer Bizum pour le premier paiement si vos clients le trouvent pratique, mais le renouvellement d’un abonnement nécessite impérativement une carte tokenisée via Redsys. Présenter Bizum comme un moyen d’« abonnement » serait trompeur, car chaque mois il faudrait que le client confirme le paiement manuellement, et ce n’est plus un abonnement : c’est une série d’achats isolés qui dépendent du fait que le client s’en souvienne et le souhaite.
Tableau comparatif : Redsys tokenisé face aux autres options
| Méthode | Renouvellement automatique | Tokenisation | SCA une seule fois | Usage recommandé |
|---|---|---|---|---|
| Redsys (paiement par référence) | Oui | Oui | Oui, à la création | Abonnements et échéances récurrentes |
| Bizum | Non | Non | Sans objet | Uniquement paiements ponctuels ou premier encaissement |
| Prélèvement SEPA | Oui | Mandat, pas de token de carte | Sans objet | Récurrent B2B ou montants élevés |
| Carte internationale (autres passerelles) | Oui | Oui | Oui | Ventes hors d’Espagne |
Pour une entreprise espagnole qui vend à des clients espagnols, mettre en place des abonnements avec Redsys dans WooCommerce est souvent la combinaison la plus naturelle : montant récurrent faible, intégration directe avec la banque habituelle et compatibilité totale avec l’encaissement récurrent.
Comment configurer l’encaissement récurrent Redsys dans votre boutique
Nous n’entrerons pas dans le détail technique de chaque établissement pour mettre en place les abonnements avec Redsys dans WooCommerce, car chaque banque a son propre tableau de bord, mais il est utile de savoir quoi demander et quoi vérifier pour éviter les mauvaises surprises.
Ce qu’il faut demander à votre banque
- TPV virtuel avec paiement par référence activé. Un TPV standard ne suffit pas ; il faut demander explicitement le mode référence (tokenisation). On l’appelle parfois « paiement par référence » ou « paiement récurrent ».
- Clé secrète de signature (SHA-256). Redsys signe chaque opération ; vous aurez besoin de cette clé pour que WooCommerce et la banque se comprennent.
- Confirmation de la prise en charge des MIT. C’est ce qui permet de marquer les renouvellements comme des débits initiés par le commerçant et d’éviter le double facteur à chaque encaissement.
Testez d’abord dans l’environnement de test
Redsys dispose d’un environnement de test indépendant du réel, avec ses propres clés. Avant d’ouvrir l’encaissement aux clients, il est conseillé d’y simuler une création de référence et un renouvellement complet, en vérifiant que la signature est correctement validée et que la notification de confirmation arrive bien à la boutique. Vous détecterez ainsi les erreurs de configuration sans risquer de vrais encaissements ni de laisser des abonnements en suspens. N’oubliez pas que la clé de l’environnement de test et celle de production sont différentes : les confondre lors du passage en réel est un oubli fréquent.
Que rechercher dans le plugin
Pour que les abonnements avec Redsys dans WooCommerce fonctionnent sans accroc, le connecteur que vous utilisez doit faire trois choses correctement : créer la référence lors du premier paiement, la conserver associée à l’abonnement et lancer les renouvellements en envoyant cette référence avec la bonne signature. EHERO WooCommerce Subscriptions intègre nativement le récurrent Redsys, de sorte que la tokenisation, le cycle de renouvellement et la gestion de l’exemption SCA sont déjà résolus, sans plugins intermédiaires ni rustines. Si vous souhaitez valider l’approche sur la base de WooCommerce, la documentation officielle de WooCommerce est une bonne référence du comportement standard de la plateforme.
Facturation automatique des renouvellements
Un encaissement récurrent génère, chaque mois, une obligation comptable. Si chaque renouvellement vous oblige à émettre une facture à la main, le gain de temps du paiement automatique se perd dans la gestion administrative. C’est pourquoi, lorsque vous gérez des abonnements avec Redsys dans WooCommerce, il est logique de relier les encaissements à la facturation : lorsqu’un abonnement est renouvelé et que Redsys confirme le débit, la facture devrait être émise automatiquement. Documenter chaque renouvellement n’est pas seulement une question de confort : c’est une obligation fiscale, et automatiser la facture évite les oublis et aligne les montants avec ce qui a réellement été encaissé par Redsys. EHERO Woo Holded couvre précisément cette étape, en synchronisant les commandes WooCommerce avec votre système de facturation afin que les renouvellements soient documentés sans intervention manuelle.
Questions fréquentes
Puis-je utiliser Bizum pour encaisser un abonnement chaque mois ?
Pas de manière automatique. Bizum ne permet pas de tokeniser la carte, donc chaque encaissement exigerait que le client confirme le paiement à la main. Il convient pour le premier paiement, pas pour le renouvellement.
Le client doit-il s’authentifier à chaque renouvellement à cause du SCA ?
Non. L’authentification forte est réalisée une seule fois, lors de la création de la référence. Les renouvellements sont marqués comme des débits initiés par le commerçant et sont exemptés du double facteur.
Que se passe-t-il si la carte tokenisée expire ou si la banque refuse le débit ?
Le renouvellement échoue et l’abonnement reste en attente de paiement. L’idéal est que le système retente le prélèvement et avertisse le client afin qu’il mette à jour sa carte avant la suspension du service.
Ai-je besoin d’un TPV virtuel spécial de ma banque pour tokeniser ?
Vous avez besoin du même TPV Redsys, mais avec le mode paiement par référence activé. C’est un réglage que votre banque active sur demande ; il est préférable de le confirmer avant de lancer les abonnements.
Conclusion
Mettre en place des abonnements avec Redsys dans WooCommerce n’est pas compliqué lorsque l’on comprend la pièce centrale : la tokenisation ou paiement par référence, qui transforme un premier paiement authentifié en une série de renouvellements automatiques conformes à la PSD2. Bizum reste réservé aux paiements ponctuels ; la récurrence vit dans la carte tokenisée. Si vous voulez encaisser des mensualités sans friction, avec le soutien de votre banque espagnole et sans dépendre de tiers, jetez un œil à EHERO WooCommerce Subscriptions : il intègre nativement le récurrent Redsys et vous épargne le plus gros casse-tête de toute activité d’abonnement, à savoir l’encaissement qui arrive, sans faille, mois après mois.