Sylius 2 : mes moyens de paiement fonctionneront-ils ?
Vos moyens de paiement continueront de fonctionner après la migration Sylius 2, à condition d'être repris : l'intégration du paiement fait partie des points qui changent le plus. Sylius 2 retire de son cœur les passerelles Stripe et PayPal Express historiques, déplace Payum dans un bundle dédié et introduit les Payment Requests. Chaque moyen de paiement doit donc être vérifié, adapté ou remplacé, puis testé de bout en bout avant la bascule.
Le paiement est le point où une erreur coûte immédiatement de l'argent : une carte refusée sans raison, une commande payée qui reste « en attente », un remboursement impossible depuis l'administration. Je le traite comme un poste à part dans chaque migration. Voici ce que dit la documentation officielle, ce que cela veut dire pour votre boutique et comment je m'y prends.
Que dit la documentation officielle sur les paiements dans Sylius 2 ?
Le guide officiel UPGRADE-2.0 est explicite sur plusieurs points. Les paquets payum/paypal-express-checkout-nvp, payum/stripe et stripe/stripe-php sont retirés des dépendances principales. Les classes qui servaient à configurer ces passerelles dans l'administration, comme les formulaires de configuration PayPal et Stripe ou le PayumController, sont supprimées.
Payum ne disparaît pas pour autant. Il est désormais chargé depuis SyliusPayumBundle, avec ses propres routes côté boutique, et la ressource de configuration des passerelles passe de sylius_payum à sylius_payment. En parallèle, Sylius 2 ajoute les Payment Requests, qui s'appuient sur deux nouveaux transports Symfony Messenger. Enfin, les fichiers de configuration de la machine à états des paiements ont été déplacés et renommés.
Pour un dirigeant, le résumé tient en une phrase : si votre boutique utilisait l'intégration Stripe ou PayPal fournie par l'ancien cœur de Sylius, elle ne fonctionnera pas telle quelle en version 2. Le détail technique de la nouvelle mécanique est dans l'article sur le passage de Payum aux Payment Requests.
Stripe, PayPal, virement : quel est le sort de chaque moyen de paiement ?
La réponse dépend de la façon dont chaque moyen de paiement est branché aujourd'hui. Je classe les situations ainsi.
| Situation actuelle | Ce qui se passe en Sylius 2 | Ce que je fais |
|---|---|---|
| Paiement hors ligne (virement, chèque, paiement à la livraison) | Reste simple : pas de prestataire externe | Vérification des instructions affichées et des e-mails |
| Stripe ou PayPal Express via l'ancien cœur | Intégration retirée du cœur | Remplacement par une intégration compatible Sylius 2 |
| PayPal via le plugin officiel Sylius | Le dépôt officiel propose des branches 2.x | Montée de version du plugin et nouveau paramétrage |
| Plugin de paiement tiers (banque, prestataire local) | Dépend de son éditeur | Vérification d'une version 2.x maintenue, sinon reprise ou remplacement |
| Passerelle développée sur mesure | Code à adapter à SyliusPayumBundle ou aux Payment Requests | Réécriture chiffrée à part |
Le cas le plus délicat est celui du plugin de paiement tiers, souvent fourni par une banque ou un prestataire régional. Si son éditeur ne publie pas de version compatible Sylius 2, la décision doit être prise tôt : attendre une version annoncée sans date est le moyen le plus sûr de rater l'échéance du 31 décembre 2026. La méthode générale de vérification est dans l'article sur les plugins compatibles Sylius 2.
Ce qu'il faut vérifier au-delà du bouton « Payer »
Un moyen de paiement ne se résume pas au formulaire de carte. Les problèmes apparaissent surtout dans ce qui se passe après. Je vérifie la notification envoyée par le prestataire quand le paiement est confirmé, parce que c'est elle qui fait passer la commande en « payée ». Je vérifie les paiements refusés puis repris, les paiements abandonnés, les authentifications fortes demandées par la banque, et les remboursements lancés depuis l'administration.
Je vérifie aussi les règles métier accrochées au paiement. En Sylius 1.x, elles étaient souvent écrites comme des callbacks winzou sur la machine à états des paiements. Avec le passage à Symfony Workflow par défaut et le déplacement de la configuration des états de paiement, ces règles doivent être portées, sinon un e-mail ou un export au paiement cesse simplement de partir.
Enfin, je vérifie la configuration chez le prestataire lui-même : adresses de retour et de notification, clés d'API, modes de test et de production. Une adresse de notification qui pointe vers une route supprimée est une cause classique de commandes payées qui restent en attente.
Comment je teste les paiements avant la bascule
Tous les tests se font en mode test chez le prestataire, sur une copie de la boutique avec vos vrais réglages de livraison et de taxes. Je déroule chaque moyen de paiement actif, sur ordinateur et sur mobile, avec et sans compte, puis je compare l'état de la commande, du paiement et des e-mails avec l'ancienne version. Avant la bascule, je fais une dernière vérification avec les clés de production sur un montant symbolique, quand le prestataire le permet.
Sylius Upgrade Analyzer, l'outil open source que j'ai créé et publié sur le Sylius Store, repère dans votre code les passerelles de l'ancien cœur, les références à Payum à déplacer et les plugins de paiement sans version 2.x connue. Si vous voulez la liste pour votre boutique, c'est le premier livrable du diagnostic de migration offert. La question des paiements encore en attente au moment de la mise en production est traitée dans l'article sur les commandes en cours à la bascule.
Ce que je vous propose
Je lance Sylius Upgrade Analyzer sur votre projet, j'inventorie vos moyens de paiement, leurs intégrations et les règles métier qui en dépendent, et je vous remets un diagnostic offert commenté avec une estimation en jours. Je vous rappelle sous 24 heures ouvrées. Si un de vos prestataires n'a pas d'intégration Sylius 2, vous le saurez assez tôt pour décider avant le 31 décembre 2026.