YuKassa et Tinkoff pour WooCommerce : paiement sans plugins inutiles

La semaine dernière, j'ai analysé le site d'un client - une entreprise de vente en gros, des filtres industriels, environ trois mille articles dans le catalogue, WooCommerce sur WordPress. Le site a trois ans, fonctionne bien, mais voici ce qui m'a tué : vingt-quatre plugins actifs. Vingt-quatre. Et c'est sans compter les mu-plugins et ceux qui sont désactivés « au cas où ». Parmi ces vingt-quatre se trouvent deux plugins distincts pour accepter les paiements. Un pour YuKassa, le second pour Tinkoff. Chacun avec ses propres paramètres, ses propres mises à jour, ses propres conflits. Le plugin YuKassa a été mis à jour il y a six mois et a interrompu le processus de commande sur les appareils mobiles - la caisse ne s'est tout simplement pas chargée. Deux jours d'arrêt le temps de régler le problème. Le plugin Tinkoff n'a pas été mis à jour du tout depuis plus d'un an - et lors du passage à PHP 8.2, il a commencé à saupoudrer des erreurs obsolètes dans le journal pendant une centaine de mégaoctets par jour.

Cela vous semble familier ? Je serais surpris sinon. Parce que c'est une douleur typique pour quiconque crée une boutique en ligne sur WooCommerce en Russie. Nous avons besoin de systèmes de paiement russes - YuKassa, Tinkoff, SBP. Et pour chacun, il existe un plugin distinct avec un cycle de vie distinct, des développeurs distincts et un historique de compatibilité distinct. Et si vous avez également des clients B2B qui doivent émettre des factures à une personne morale, bienvenue dans le monde des béquilles, des hooks WooCommerce, des caisses refaites et des nuits blanches.

J'ai longtemps réfléchi à la raison pour laquelle cela se produit. Pourquoi en 2026 accepter des paiements sur un site russe WooCommerce est une quête. Et la réponse était évidente : personne ne considère les paiements comme faisant partie d’un système unique. Chaque plugin de paiement est un microcosme distinct. Il possède ses propres tables dans la base de données, ses propres hooks, ses propres fichiers JavaScript, qui sont chargés lors du paiement. Et lorsque ces microcosmes commencent à entrer en collision les uns avec les autres au sein d’un même WordPress, des étincelles volent. Conflits de style, duplication de scripts, conditions de concurrence lors du traitement des rappels. J'ai vu un site sur lequel deux plugins essayaient de traiter le même webhook en même temps - et la commande était marquée comme payée deux fois, ce qui rompait le contrôle des stocks.

Lorsque nous avons conçu le module de paiement dans COS WP Woo, l'idée était simple et, me semble-t-il, correcte : les passerelles de paiement doivent être intégrées à l'outil qui gère déjà la boutique. Pas en tant que plugins séparés, mais dans le cadre d'une architecture unique. Un plugin – un point de configuration – une mise à jour. Cela semble évident, mais pour une raison quelconque, il s’agit d’une révolution dans l’écosystème WordPress.

Et vous savez ce qui est le plus surprenant ? Lorsque je discute de cette idée avec des commerçants, la première réaction est presque toujours la même : "Pourquoi ? C'est comme ça que ça marche pour moi". Cela fonctionne jusqu'à ce qu'il se brise. Jusqu'à ce que WooCommerce soit mis à jour vers la prochaine version majeure. Jusqu'à ce que PHP passe à une nouvelle version. Jusqu'à ce que YuKassa change l'API. Et puis la panique commence : le plugin n'est pas compatible, la caisse ne fonctionne pas, les clients ne peuvent pas payer, l'argent n'arrive pas. Et à ce moment-là, il s'avère que l'auteur du plugin est un développeur de Novossibirsk, qui met à jour le code pendant son temps libre par rapport à son travail principal. Et il n'a plus le temps maintenant, car il a une date limite pour son projet principal. Et vous avez un magasin. Je ne blâme pas ce développeur – il fait un excellent travail, souvent gratuitement. Mais dépendre d’une seule personne sur une question qui affecte directement les revenus est un risque qui peut et doit être supprimé.

Pourquoi chaque plugin supplémentaire n'est pas simplement « un autre plugin »

Parlons de ce qui se passe réellement lorsque vous installez un plugin distinct pour accepter les paiements. Il ne s'agit pas seulement de fichiers dans un dossierwp-content/plugins. Ce sont des requêtes supplémentaires dans la base de données à chaque fois que la page est chargée - car WordPress charge les métadonnées du plugin, vérifie son statut, charge son domaine de texte pour les traductions. Il s'agit de requêtes HTTP supplémentaires lors du paiement, car le plugin récupère avec lui ses fichiers CSS et JS. C'est un point d'échec supplémentaire lors de la mise à jour - et quiconque travaille avec WooCommerce depuis plus d'un an sait que les mises à jour de WooCommerce aiment casser les plugins avec une régularité enviable.

Mais ce n'est même pas une question de performances. C'est une question de contrôlabilité. Lorsque vous disposez de deux ou trois plugins de paiement distincts, vous obtenez deux ou trois interfaces de configuration distinctes. YuKassa est configuré à un endroit, Tinkoff à un autre, le paiement manuel d'une facture à un troisième. Et chaque fois qu'un gestionnaire ou un propriétaire de site souhaite modifier quelque chose - par exemple, activer le paiement échelonné via Tinkoff ou ajouter un mode de paiement pour les clients B2B - il doit se rappeler où tout se trouve. Et si ce n’est pas lui, mais un entrepreneur qui l’a installé il y a six mois, bonne chance dans votre recherche.

J'ai rencontré cela des dizaines de fois. Un client appelle : « Notre paiement par carte a disparu de notre site internet. » Vous commencez à comprendre - il s'avère que WooCommerce a été mis à jour, le plugin YuKassa n'est pas compatible avec la nouvelle version et la passerelle a été automatiquement désactivée. Mais la notification à ce sujet a été envoyée dans un e-mail que personne ne lit. Et les clients à la caisse voient le seul mode de paiement disponible : le virement bancaire, qui est configuré via la passerelle WooCommerce BACS standard. Et ils partent. Parce que qui, sensé, ferait un virement bancaire alors qu'il souhaite acheter un filtre pour deux mille roubles.

Cela devient encore plus amusant lorsqu'un plugin de système de paiement entre en conflit avec autre chose. Je me souviens d'un projet où le plugin YuKassa était en conflit avec le plugin multilingue - lors du changement de langue lors du paiement, l'URL de rappel était perdue et le paiement échouait toujours avec une erreur. Ou un autre cas : le plugin Tinkoff a utilisé sa version de la bibliothèque pour travailler avec des requêtes HTTP, ce qui était en conflit avec les abonnements WooCommerce. Ces événements sont impossibles à prévoir et se produisent aux moments les plus inopportuns, généralement le vendredi soir, lorsque la publicité est diffusée et que le trafic est à son maximum.

C'est pourquoi je pense qu'il est fondamentalement important de supprimer tout ce qui peut être supprimé de WordPress et de consolider les fonctionnalités en un seul endroit. Pas par cupidité - disent-ils, regroupons tout dans un seul plugin et il y aura un monolithe. Non. Du bon sens en ingénierie. Les passerelles de paiement ne sont pas compliquées. Il s'agit d'intégrations d'API avec des protocoles clairement documentés. YuKassa et Tinkoff disposent d'une excellente documentation et d'API stables. Il n’y a aucune raison pour qu’il s’agisse d’un plugin distinct avec une vie distincte.

Ce que peuvent faire les passerelles intégrées : méthodes YuKassa, Tinkoff et B2B

Quand je dis « passerelles de paiement intégrées », voici ce que je veux dire : dans COS WP Woo, il y a une implémentation complète de YuKassa, Tinkoff et trois méthodes de paiement B2B qui s'enregistrent comme passerelles de paiement WooCommerce standard. Pour WooCommerce, ils ressemblent exactement à ses passerelles intégrées : virement bancaire ou paiement à la livraison. Ils sont visibles dans les paramètres de WooCommerce, le paiement et les commandes. Mais ils sont gérés depuis une seule interface, testés ensemble, mis à jour ensemble.

Voyons ce qui est exactement disponible et pourquoi cela est nécessaire.

YuKassa est en fait un standard de paiement en ligne dans le e-commerce russe. Si vous possédez une boutique en ligne sur WooCommerce et acceptez les paiements de particuliers, vous avez besoin de YuKassa. Notre passerelle intégrée prend en charge trois méthodes principales : le paiement par carte bancaire, le système de paiement rapide et YuMoney - un portefeuille électronique. Pourquoi ces trois-là ? Parce qu’ils couvrent quatre-vingt-quinze pour cent des scénarios. Cartes - pour ceux qui ont l'habitude de payer avec Visa ou MasterCard (enfin, ou Mir, pour être plus précis - nous sommes en 2026). SBP s'adresse à ceux qui paient via une banque mobile à l'aide d'un code QR, et cette méthode gagne rapidement en popularité, en particulier pour les paiements jusqu'à quinze mille roubles. YuMoney s'adresse à ceux qui utilisent le portefeuille YuMoney, et il y en a aussi beaucoup, notamment parmi le public des 25-40 ans.

L'installation prend littéralement quelques minutes. Entrez votre identifiant de boutique et votre clé secrète depuis votre compte personnel YuKassa, choisissez les méthodes à activer, et c'est tout - la passerelle fonctionne. Pas de plugins séparés, pas de tables supplémentaires dans la base de données, pas de fichiers JS supplémentaires pour le paiement. Le webhook pour les notifications de paiement est traité via le rappel standard de WooCommerce, et la commande est automatiquement transférée au statut « Traitement » une fois le paiement réussi.

Et c'est ici que le plaisir commence : le paiement en deux étapes, également appelé retenue. Il s’agit d’une fonctionnalité que peu de plugins implémentent correctement, et pour certaines entreprises, elle est d’une importance cruciale. L’idée est simple : lors du paiement, l’argent n’est pas débité de la carte du client, mais est bloqué et retenu. Le magasin constate que le paiement a été effectué et commence à préparer la commande. Et ce n’est que lorsque la commande est effectivement prête à être expédiée que le gérant confirme le débit et que l’argent est transféré sur le compte du magasin. Si la commande est annulée pour une raison quelconque, la retenue est supprimée, l'argent est restitué au client automatiquement, sans remboursement, sans opérations inutiles.

Pourquoi est-ce nécessaire ? Imaginez : vous vendez du matériel industriel. Le client commande une pompe pour quatre cent mille roubles. Vous vérifiez la disponibilité dans l'entrepôt - mais elle n'y est pas, vous devez commander auprès du fournisseur, le délai est de trois semaines. Sans retenue, vous radieriez l'argent immédiatement, puis vous inquiéteriez pendant trois semaines au cas où le client changerait d'avis et exigerait un remboursement, mais l'argent est déjà en circulation. Avec la retenue, l'argent est bloqué sur la carte du client, vous commandez sereinement auprès du fournisseur, et n'êtes débité que lorsque les marchandises arrivent effectivement à l'entrepôt et sont prêtes à être expédiées. Le client est également calme - il voit que l'argent n'a pas disparu, mais a seulement été gelé. Il s’agit d’un niveau de confiance fondamentalement différent entre l’acheteur et le vendeur.

Dans notre passerelle, le paiement en deux étapes est activé avec un seul interrupteur dans les paramètres. Après cela, tous les paiements via YuKassa sont traités en mode attente. Le gestionnaire peut confirmer ou annuler le paiement directement depuis la carte de commande dans WooCommerce - les boutons correspondants y apparaissent. Pas besoin de vous connecter à votre compte personnel YuKassa, pas besoin de basculer entre les fenêtres. Tout en un seul endroit.

Parlons maintenant de Tinkoff. Tinkoff Acquiring est la deuxième passerelle de paiement la plus populaire en Russie après YuKassa, et pour certains types d'entreprises, elle est même préférable. Premièrement, les conditions d'acquisition de Tinkoff sont souvent meilleures : les frais de transaction sont inférieurs, en particulier pour les entreprises de taille moyenne dont le chiffre d'affaires dépasse un million de roubles par mois. Deuxièmement, Tinkoff dispose d'un plan de versement intégré - et c'est une fonctionnalité intéressante pour les magasins qui vendent des produits coûteux.

La passerelle Tinkoff intégrée dans COS WP Woo fonctionne sur le même principe : saisissez la clé du terminal et le mot de passe depuis votre compte personnel Tinkoff, et la passerelle est prête. L'acquisition standard est prise en charge - paiement par carte et en plusieurs fois - lorsque le client peut répartir le paiement sur plusieurs mois sans intérêts. Le magasin paie en plusieurs fois sous la forme d'une commission de Tinkoff, mais pour des marchandises coûtant entre dix et quinze mille roubles, cela rapporte absolument - la conversion augmente de vingt à trente pour cent, car il est psychologiquement plus facile pour le client d'en payer trois mille par mois que d'en payer quinze mille d'un coup.

Tinkoff prend également en charge le paiement en deux étapes, et notre passerelle l'implémente. La logique est la même : retenue, confirmation de débit de la carte de commande, annulation automatique de la retenue lors de l'annulation de la commande. L'uniformité est importante. Le manager n'a pas besoin de se rappeler que la confirmation fonctionne de cette façon pour YuKassa, mais différemment pour Tinkoff. L'interface est la même, les boutons sont les mêmes, la logique est la même.

Mais passons ensuite à ce qui distingue COS WP Woo de toutes les autres solutions : les méthodes de paiement B2B. Et franchement, c’est le domaine pour lequel j’ai commencé à écrire cet article.

Paiement B2B : quand le "paiement par carte" ne fonctionne pas

Si vous travaillez uniquement avec des clients particuliers - des particuliers qui visitent le site, ajoutent des marchandises au panier et paient par carte - YuKassa et Tinkoff peuvent vous suffire. Mais une fois que l’on commence à travailler avec des personnes morales, on se retrouve dans un monde complètement différent. Un monde où personne ne paie par carte. Lorsque le paiement s'effectue sur facture, via le compte bancaire de l'entreprise. Entre la passation d'une commande et la réception effective de l'argent, cela peut prendre une semaine, voire deux. Et là où les passerelles WooCommerce standard ne sont pas seulement gênantes, elles sont fondamentalement inadaptées.

J'ai vu des entreprises tenter de résoudre ce problème. L'option la plus courante est que le responsable génère une facture manuellement dans 1C ou Excel, l'envoie au client par e-mail et attend. Lorsque l'argent arrive, il modifie manuellement le statut de la commande dans WooCommerce. S’il y a cinq commandes par jour, c’est tolérable. Si cinquante ans, c'est l'enfer. Et les erreurs sont inévitables : ils ont oublié de modifier le statut, ils ont confondu la commande, la facture a été envoyée avec des détails erronés.

Une autre option est le BACS (compte bancaire/paiements par chèque) standard de WooCommerce. Techniquement, il s'agit d'un virement bancaire. Vous précisez les coordonnées de l'entreprise dans les paramètres, le client les voit sur la page « Merci pour votre commande » et dans l'e-mail. Mais il s’agit d’informations textuelles – pas de comptage normal. Aucun détail sur l'acheteur. Pas de génération automatique de documents. Pour le B2B, ce n’est tout simplement pas grave. Lorsqu’un comptable de la société acheteuse recevra un e-mail avec le texte « Transférer 47 800 roubles sur le compte courant de tel ou tel », il sera pour le moins surpris. Il a besoin d'un compte normal - avec un numéro d'identification fiscale, un point de contrôle, une adresse légale, des coordonnées bancaires, un sceau et une signature. Un document qui peut être imprimé, classé dans un dossier et présenté pour inspection.

Dans COS WP Woo, nous avons implémenté trois méthodes de paiement pour le B2B, et chacune résout un problème différent.

Le premier est le paiement par facture, Invoice Gateway. C'est exactement ce dont la plupart des entreprises B2B ont besoin. Lors du paiement, le client sélectionne « Paiement sur facture », indique les coordonnées de son entreprise - ou celles-ci sont automatiquement extraites de son profil s'il est déjà enregistré en tant qu'utilisateur B2B. Après avoir passé une commande, le système génère automatiquement une facture de paiement - un document complet avec les coordonnées du vendeur et de l'acheteur, le numéro de facture, la date, la liste des marchandises, le montant et les coordonnées bancaires. Cette facture est téléchargeable au format PDF directement depuis votre compte personnel ou depuis une notification par email. Le gestionnaire peut renvoyer la facture si le client a perdu la lettre. Lorsque le paiement arrive, le statut de la commande change et le client reçoit une notification.

Voici le problème : ce n'est pas seulement un modèle de texte. Il s'agit d'un véritable document généré sur la base des données de commande. Les coordonnées du vendeur sont extraites des paramètres - INN, KPP, OGRN, adresse légale, coordonnées bancaires. Détails de l'acheteur - à partir du profil utilisateur ou des champs de paiement. Le numéro de compte est généré automatiquement en tenant compte de la numérotation que vous avez configurée. Je sais que cela semble être une bagatelle pour la comptabilité, mais lorsqu'une centaine de comptes de ce type sont générés par mois, l'automatisation fait gagner des dizaines d'heures.

La deuxième méthode est le bon de commande, ou ordre de paiement. Il s'agit d'une forme plus libre de paiement B2B, courante dans la pratique internationale et que l'on retrouve de plus en plus dans les grandes entreprises russes. En résumé : l'acheteur indique le numéro de son bon de commande interne - Numéro de Bon de Commande, ou PO. Il s'agit d'un document convenu au sein de la société acheteuse et selon lequel le paiement sera effectué. Pour le vendeur, cela signifie que la commande a été confirmée et que le paiement sera effectué - mais pas maintenant, mais après que l'acheteur aura traité les documents chez lui. Généralement, le délai de paiement est de quatorze à trente jours.

Cette méthode est particulièrement demandée dans les entreprises industrielles, où les achats passent par plusieurs étapes d'approbation. Le responsable des achats crée une demande, le chef de service approuve, le directeur financier signe et le service comptable génère le paiement. L'ensemble de ce processus peut prendre de deux à trois semaines. Et pendant tout ce temps, la commande reste bloquée dans WooCommerce avec le statut « En attente de paiement » avec un numéro de bon de commande associé. Le responsable du vendeur voit ce numéro et sait que le paiement est en cours. Et quand l'argent arrive, il confirme la commande.

La troisième méthode est le portefeuille interne, Wallet Gateway. C’est une tout autre histoire et, à mon avis, elle est sous-estimée. L'essentiel : pour chaque client B2B, un solde interne est créé dans le système - un portefeuille. Le client peut le recharger par virement bancaire pour n'importe quel montant, par exemple un million de roubles. Et après cela, payez les commandes instantanément - l'argent est débité du solde de votre portefeuille, sans attendre un virement bancaire, sans générer de facture pour chaque commande.

Pourquoi est-ce nécessaire ? Imaginez un gros client grossiste qui passe vingt à trente commandes par mois. Chaque commande implique la génération d'une facture, l'attente du paiement et le contrôle de la réception. Avec vingt commandes par mois, cela signifie vingt factures, vingt paiements, vingt jours bancaires d'attente. Et avec un wallet : un seul virement pour le montant total, puis le client règle ses commandes instantanément, en un clic. Le solde est vu à la fois par le client dans son compte personnel et par le gestionnaire dans le panneau d'administration. Toutes les transactions sont enregistrées - dépôts, débits, retours. Transparent tant pour le vendeur que pour l’acheteur.

J'ai parlé avec le propriétaire d'une entreprise qui vend des pièces détachées pour équipements spéciaux. Ils comptent deux cents clients B2B réguliers et réalisent chacun entre cinq et quinze commandes par mois. Lorsqu'ils ont introduit le système de portefeuille interne, le comptable a littéralement versé des larmes - au lieu de mille deux cents comptes par mois, il y avait deux cents dépôts. La charge de travail a été divisée par six. Et dans le même temps, les clients ont commencé à commander plus souvent : le paiement étant instantané, il n'est pas nécessaire d'attendre l'approbation à chaque fois.

Les trois méthodes B2B sont intégrées dans un seul module de vente B2B COS WP Woo. Ils travaillent en collaboration avec des groupes de clients, des tarifs personnalisés, des quantités minimales de commande et d'autres fonctionnalités B2B. Il ne s'agit pas d'un module complémentaire : il fait partie d'un système unique où tout est connecté et tout fonctionne ensemble.

Sécurité des paiements : ce à quoi on ne pense généralement pas avant le premier incident

Puisque nous parlons de passerelles de paiement, nous ne pouvons ignorer le sujet de la sécurité. Et je ne parle pas maintenant de PCI DSS et de certification - c'est la responsabilité de YuKassa et Tinkoff eux-mêmes, les données de carte sont traitées de leur côté et la boutique WooCommerce ne voit jamais le numéro de carte du client. Je parle d'autre chose : de la sécurité de l'intégration elle-même.

Chaque plugin de paiement WordPress est un point d'entrée potentiel. Il possède une URL de rappel à laquelle le système de paiement envoie des notifications. Cette URL est accessible depuis Internet. Sinon, comment YuKassa informera-t-elle votre site que le paiement a été effectué ? Et cette URL doit être protégée. Vous devez vérifier la signature de la demande, vous devez valider l'adresse IP de l'expéditeur, vous devez vérifier que le montant et le numéro de commande correspondent à ce qui est stocké dans la base de données. Si vous ne le faites pas, un attaquant peut envoyer une fausse demande à votre URL de rappel et « confirmer » le paiement d’une commande que personne n’a payée. Les marchandises iront à l'escroc, mais pas l'argent.

Cela vous semble paranoïaque ? En théorie – oui. En pratique, je connais au moins trois cas où c'est exactement ce qui s'est produit. Dans un cas, le plugin du système de paiement a vérifié la signature de la demande, mais n’a pas vérifié le montant. L'attaquant a créé une commande de cent mille roubles, puis a envoyé un faux rappel d'un montant d'un rouble - et la signature était valide car il a utilisé son compte test du système de paiement. La commande est passée au statut « payée ». Le gérant a expédié la marchandise. La perte est de cent mille roubles moins un rouble.

Lorsque les passerelles sont intégrées dans un système unique, la sécurité ne relève pas de la responsabilité de l'auteur individuel du plugin, mais fait partie de l'architecture globale. Dans COS WP Woo, tous les gestionnaires de rappel passent par une seule couche de validation : vérification de la signature, vérification du montant, vérification de la conformité des commandes, vérification de l'adresse IP (pour YuKassa - la gamme IP Yoomoney, pour Tinkoff - leur gamme de serveurs). Toutes les demandes suspectes sont enregistrées dans le système d'activité. Si quelqu'un essaie de simuler un webhook, vous le saurez grâce au journal, et non grâce à un appel d'un client en colère.

Un autre aspect de la sécurité auquel peu de gens pensent est le stockage des clés API. Identifiant de boutique et clé secrète YuKassa, Terminal Key Tinkoff - ce sont en fait les clés de votre compte courant. Si quelqu'un y accède, il peut rediriger les paiements vers un autre compte. Et ici, la manière dont le plugin stocke ces données est importante. La plupart des plugins stockent les clés en texte clair danswp_options- Tableau des paramètres WordPress standard. Cela signifie que tout autre plugin ayant accès à la base de données (et dans WordPress, il s'agit essentiellement de n'importe quel plugin) peut lire vos clés. Dans COS WP Woo, les clés secrètes sont stockées cryptées et cachées dans l'interface – vous ne voyez que les quatre derniers caractères. Lors d'une requête GET à l'API des paramètres, les clés ne sont jamais renvoyées en texte clair. Ce n’est pas de la paranoïa, c’est une hygiène de base.

Point de configuration unique – et pourquoi c'est plus important qu'il n'y paraît

J'ai passé beaucoup de temps à expliquer aux clients pourquoi la consolidation des passerelles de paiement en un seul endroit n'est pas un gadget marketing, mais une nécessité technique. Et à chaque fois, les arguments sont les mêmes, mais les gens ont besoin de temps pour le ressentir.

Voici une situation typique. La société propose trois modes de paiement sur son site Internet : YuKassa pour les particuliers, Tinkoff pour les versements et le virement bancaire manuel pour le B2B. Trois plugins différents, trois réglages différents. Le gestionnaire souhaite désactiver temporairement le plan de versement car la promotion est terminée et les conditions ont changé. Il va dans WooCommerce → Paramètres → Paiements. Affiche une liste de passerelles. Trouve Tinkoff. Clique sur "Gérer". Accédez à la page des paramètres du plugin Tinkoff. Désactive les plans de versement. Enregistre. Prêt? Presque - mais il a oublié que le plugin Tinkoff a une page de paramètres distincte dans le menu principal de WordPress, et qu'il y a également un commutateur de versement. Et ils ne sont pas synchronisés. Deux heures plus tard, il vérifie : les plans de versement sont à nouveau disponibles à la caisse. Parce que le paramètre du menu principal du plugin a remplacé le paramètre de WooCommerce Payments.

Cela ressemble à une blague ? C'est une histoire vraie. Et j'ai des dizaines d'histoires similaires.

Dans COS WP Woo, toutes les passerelles de paiement sont configurées au même endroit - sur un seul onglet, dans une seule interface. YuKassa, Tinkoff, paiement de facture, bon de commande, portefeuille, tout est à proximité, sur un seul écran. Voulez-vous désactiver les versements ? Un interrupteur. Voulez-vous modifier les détails de votre facture? Juste ici, juste là. Souhaitez-vous activer le paiement en deux étapes pour YuKassa ? Un clic. Et il n'existe aucun paramètre « alternatif » susceptible d'écraser vos modifications.

Mais ce n'est pas seulement une question de commodité pour le manager. Une architecture unifiée offre des avantages techniques qui ne sont pas évidents au premier abord. Lorsque toutes les passerelles résident dans un seul plugin, elles utilisent une infrastructure commune : un enregistreur commun, un système de gestion des erreurs commun, des hooks WooCommerce communs. Cela signifie que lors de la mise à jour de WooCommerce, vous devez vérifier la compatibilité d’un plugin, et non de trois. Et si quelque chose ne va pas, déboguez un point d’intégration, pas trois.

Il existe un autre aspect dont on parle rarement : les conflits de paiement. La page de paiement dans WooCommerce est le point le plus faible. Chaque plugin qui ajoute sa propre logique de paiement augmente la probabilité d'un conflit. J'ai vu des situations où deux plugins de paiement connectaient la même bibliothèque jQuery de versions différentes, et la caisse tombait en panne - le bouton « Payer » ne répondait pas au clic. Ou lorsque les gestionnaires AJAX d'un plugin ont intercepté les événements d'un autre. Ou lorsque le CSS d’une passerelle cassait l’affichage du formulaire d’une autre. Lorsque tout se trouve dans un seul plugin, de tels problèmes n’existent tout simplement pas. Un ensemble de scripts, un ensemble de styles, un gestionnaire AJAX.

Dernier point mais non le moindre : les mises à jour. Chaque plugin individuel est un cycle de mise à jour distinct. YuKassa est mis à jour une fois par mois. Tinkoff - une fois tous les six mois (si vous avez de la chance). Une facture WooCommerce - quand l'auteur s'en souvient. Et chaque mise à jour est une source potentielle de problèmes. Vous devez vérifier la compatibilité avec la version actuelle de WordPress, avec la version actuelle de WooCommerce, avec la version actuelle de PHP, avec tous les autres plugins. Lorsque vous disposez d'un plugin avec des passerelles intégrées - une mise à jour, une vérification, un bouton « Mettre à jour ». Nous testons la compatibilité de toutes les passerelles avant chaque version. Et si une mise à jour de WooCommerce casse quelque chose, nous réparons toutes les passerelles en même temps, plutôt que d'attendre que l'auteur de chaque plugin daigne publier un correctif.

Vous savez, au fil des années de travail avec WooCommerce, je suis arrivé à une règle simple : moins il y a de plugins sur le site, plus le site est stable. Cela ne signifie pas que vous devez tout écrire vous-même et abandonner l'écosystème. Cela signifie que vous devez choisir consciemment les fonctions à intégrer dans des plugins séparés et celles qu'il est plus raisonnable d'avoir dans l'outil principal. Les passerelles de paiement sont définitivement une fonctionnalité qu’il est préférable d’intégrer. Parce qu’ils sont critiques pour l’entreprise, étroitement liés au processus de commande et extrêmement sensibles aux conflits.

Et si on regardait les choses différemment ? Et si nous considérions les passerelles de paiement non pas comme une « fonctionnalité supplémentaire », mais comme le fondement du commerce électronique ? Sans paiement, il n'y a pas de vente. Sans ventes, il n’y a pas d’entreprise. Et cette fondation doit être aussi fiable que possible, aussi prévisible que possible, aussi contrôlable que possible. Lorsque votre fondation est constituée de trois plugins distincts provenant de trois développeurs différents avec trois calendriers de mise à jour différents et trois approches différentes en matière de sécurité, la fondation est fragile. Lorsque la fondation fait partie d’un système unique que vous contrôlez entièrement, elle est solide.

Je ne dis pas que les plugins séparés pour YuKassa ou Tinkoff sont mauvais. Ils résolvent leur problème et de nombreux magasins en ont assez. Mais si vous construisez un e-commerce sérieux, notamment avec une composante B2B, le nombre de plugins commence à jouer en votre défaveur. Et chaque plugin qui peut être supprimé sans perte de fonctionnalité est une étape vers un site plus stable, plus rapide et plus gérable.

Comment ça marche en pratique : de la configuration au premier paiement

Laissez-moi vous expliquer à quoi ressemble le processus dans la pratique : de l'installation à l'acceptation effective des paiements. Sans abstractions, en particulier.

Vous installez COS WP Woo sur votre site WooCommerce. Accédez à la section des paramètres du module « Livraison et paiement » - c'est l'un des onglets de l'interface du plugin. Voir toutes les passerelles de paiement disponibles. Chacun avec un interrupteur marche/arrêt et un bouton de réglage.

Commençons par YuKassa. Cliquez sur « Configurer ». Entrez deux paramètres : ID de boutique et clé secrète. Vous prenez les deux depuis votre compte personnel YuKassa - la section « Intégration ». Choisissez les modes de paiement : cartes bancaires, SBP, YuMoney - individuellement ou tous ensemble. Si vous souhaitez un paiement en deux étapes, activez le commutateur « Holding ». Spécifiez après combien de jours une retenue non confirmée est automatiquement annulée - généralement sept jours, mais vous pouvez la personnaliser vous-même. Sauvegarder. Ça y est, YuKassa fonctionne.

Point important : l'URL du webhook pour YuKassa est générée automatiquement. Vous devez le copier depuis les paramètres de la passerelle et le coller dans votre compte personnel chez YuKassa, dans la section « Notifications HTTP ». Une fois, lors de la configuration initiale. Après cela, YuKassa informera automatiquement votre site de l'état des paiements - paiement réussi, refus, retour. Une commande dans WooCommerce changera automatiquement son statut. Le gestionnaire n'a pas besoin de surveiller les paiements manuellement.

Tinkoff est configuré de la même manière. Clé de terminal et mot de passe - à partir de votre compte personnel Tinkoff Acquiring. Incluez l’acquisition standard, les versements – ou les deux. S'il s'agit d'un plan de versement, indiquez le montant minimum de commande auquel il est disponible. Il ne sert à rien d'offrir des versements pour des marchandises de cinq cents roubles - cela semble étrange et ne rapporte pas à cause de la commission. Habituellement, le seuil minimum est de trois à cinq mille roubles, mais cela dépend de votre activité et de vos marges. L'URL du webhook est également générée automatiquement. Enregistrez - vous avez terminé.

Désormais méthodes B2B. Paiement par facture - vous devez ici renseigner les coordonnées de votre entreprise : nom de l'organisation, INN, KPP, OGRN, adresse légale, compte courant, BIC, nom de la banque, compte correspondant. Si vous disposez du sceau et de la signature du réalisateur sous forme d'images, téléchargez-les, elles seront automatiquement ajoutées à la facture PDF. Configurez un modèle de numérotation de compte - par exemple, « SCh-{année}-{numéro} », et chaque compte recevra un numéro unique au format « SCH-2026-00001 ». Allumez-le et la méthode « Paiement sur facture » ​​apparaît sur la caisse, disponible pour les utilisateurs B2B enregistrés.

Lorsqu'un client B2B passe une commande avec paiement par facture, le système génère automatiquement un PDF de la facture. Il contient tout : les coordonnées du vendeur et de l'acheteur, une liste des marchandises avec prix et quantités, le montant total, la TVA, les coordonnées bancaires pour le virement, le cachet et la signature. Ce document est adressé au client par email et est disponible en téléchargement dans son compte personnel. Le responsable le voit également dans la fiche de commande et peut la reformater ou la renvoyer si nécessaire. Pas de travail manuel, pas d'Excel, pas de 1C à ce stade.

Bon de commande est encore plus simple : le champ « Numéro de bon de commande » apparaît à la caisse, le client saisit son numéro de bon de commande et passe une commande. La commande est créée au statut « En attente de paiement » avec un bon de commande associé. Le gestionnaire voit ce numéro dans la commande et peut le vérifier. Lorsque le paiement arrive - manuellement ou automatiquement via l'intégration bancaire - le statut passe à « Traitement ».

Wallet - ici, le client voit son solde directement à la caisse. S'il y a suffisamment de fonds, vous pouvez payer en un clic. Si cela ne suffit pas, il voit un message concernant un manque de fonds et une offre de reconstitution du portefeuille. Le réapprovisionnement s'effectue par virement bancaire aux coordonnées spécifiées (en indiquant le numéro de portefeuille dans l'objet du paiement) ou via la même passerelle YuKassa/Tinkoff - si vous configurez cette option. Solde, historique des transactions, opérations de réapprovisionnement et de débit, tout est visible aussi bien par le client dans son compte personnel que par le gestionnaire dans le panneau d'administration.

Par ailleurs, je voudrais parler des retours - c'est un sujet qui blesse chaque propriétaire de boutique en ligne. Le client a payé, puis a changé d'avis, l'argent doit être restitué. Lorsque vous travaillez avec des plugins individuels, le retour est une quête distincte. Vous devez vous rendre sur la carte de commande, retrouver la transaction, comprendre par quelle passerelle le paiement est passé, accéder aux paramètres de cette passerelle, vérifier si elle prend en charge les retours automatiques ou si cela doit être effectué manuellement via votre compte personnel du système de paiement. Dans COS WP Woo, les retours fonctionnent de la même manière pour toutes les passerelles : cliquez sur le bouton « Retour » dans la fiche de commande, indiquez le montant (remboursement total ou partiel) et confirmez. Le système détermine lui-même par quelle passerelle le paiement est passé et envoie une demande de remboursement via l'API YuKassa ou Tinkoff. Pour un portefeuille B2B, l’argent est automatiquement restitué sur votre solde. Pour payer par facture, une notification est générée au responsable concernant la nécessité d'un remboursement manuel via la banque. Tout est transparent, tout est enregistré, rien n'est perdu.

Et voici ce qui me semble important de souligner : toutes ces méthodes fonctionnent en parallèle. Lors du paiement, le client voit exactement les moyens de paiement qui s'offrent à lui. Un individu aperçoit YuKassa et Tinkoff. Un client B2B voit le paiement par facture, bon de commande, portefeuille - et, s'il le souhaite, peut également payer par carte via YuKassa ou Tinkoff. La visibilité des méthodes est configurée via des groupes B2B : vous pouvez afficher différentes méthodes de paiement à différents groupes de clients. Les grands grossistes n’ont besoin que d’une facture et d’un portefeuille. Pour les petits revendeurs - un compte et une carte. Pour les clients de détail - carte, SBP et plan de versement. Flexibilité totale.

Honnêtement, lorsque j'ai vu pour la première fois ce travail dans un vrai magasin - à la caisse d'un de nos clients, un distributeur d'huile moteur - j'ai ressenti une sorte de satisfaction professionnelle. Parce que c’est exactement ce qui m’a toujours manqué dans les projets. Quand tout - paiement en ligne pour les particuliers, factures automatiques pour les personnes morales et portefeuilles internes pour les grossistes réguliers - réside au même endroit, est contrôlé depuis une seule interface et fonctionne de manière prévisible. Il n'est pas nécessaire d'expliquer au responsable que « ce bouton est dans ce plugin, et celui-ci est dans un autre ». Il n'est pas nécessaire de se rappeler à quel endroit des trois vous devez modifier les détails lorsque l'entreprise déménage vers une nouvelle adresse légale. Il n'y a pas lieu de paniquer après la mise à jour de WooCommerce : « et si quelque chose interrompait à nouveau les paiements ?

J'entends souvent la question : n'est-il pas plus simple d'utiliser des plugins tout faits ? Ils sont gratuits, pris en charge par les développeurs de systèmes de paiement et constamment mis à jour. Et oui, à première vue, c'est logique. Mais soyons honnêtes : le plugin YuKassa « gratuit » vous coûte en réalité du temps : du temps pour la configuration, du temps pour déboguer les conflits, du temps pour attendre les mises à jour en cas de panne. « Pris en charge par les développeurs » - formellement oui, mais essayez d'obtenir une réponse du support technique du plugin YuKassa lorsque vous rencontrez un conflit avec WooCommerce lors du paiement. Je l'ai essayé. La réponse standard est : « Désactivez tous les autres plugins et vérifiez. » Merci, cela a beaucoup aidé. "Constamment mis à jour" - consultez le journal des modifications pour connaître les dernières mises à jour. Le plus souvent, il s'agit de « corrections d'erreurs mineures » une fois tous les deux à trois mois. Et si votre problème ne vient pas de leurs « erreurs mineures », mais d’un conflit avec un autre plugin, vous êtes en ligne pour l’éternité.

D'accord, j'ai probablement l'air trop dur. Laissez-moi vous dire ceci : pour une simple boutique de dix produits avec paiement uniquement par carte, le plugin YuKassa séparé est un choix tout à fait normal. Installez, configurez, ça marche, oubliez. Mais dès que votre boutique se développe - des clients B2B apparaissent, vous avez besoin de versements, vous avez besoin de factures, vous avez besoin d'un paiement en deux étapes - vous commencez à accrocher WordPress avec des plugins comme un arbre de Noël avec des jouets. Et à un moment donné, l’arbre tombe.

Il me semble que la bonne approche consiste à réfléchir dès le début à l'infrastructure de paiement. Non pas comme quelque chose qui serait « vissé » au magasin avec des plugins séparés, mais comme un élément fondamental du système de commerce électronique. Avec le catalogue, avec la livraison, avec le CRM et l'analyse. Système unique – responsabilité unique – point de contrôle unique.

Et si vous êtes maintenant confronté à un choix - assembler une infrastructure de paiement à partir de plugins séparés ou utiliser une solution unique - je vous conseillerais d'essayer au moins la deuxième option. Non pas parce que le premier est mauvais, mais parce que le second, d'après mon expérience, permet d'économiser du temps, des nerfs et de l'argent. Surtout lorsque l’entreprise se développe et devient plus complexe.

Enfin, je vais vous raconter une histoire. L'un de nos clients est une entreprise qui vend des lubrifiants et des huiles industrielles, environ cinq cents clients B2B et plusieurs milliers de clients particuliers via le site Web. Avant de passer à COS WP Woo, ils disposaient de quatre plugins liés au paiement : YuKassa, Tinkoff, une sorte de plugin pour générer des factures (payées d'ailleurs avec un abonnement annuel) et un autre pour comptabiliser les paiements des personnes morales. Au total, ces quatre plugins ont chargé huit fichiers JS supplémentaires et trois CSS lors du paiement. Le temps de chargement de la page de paiement est de quatre secondes et demie sur mobile. Après la transition - un peu plus de deux. Les taux d'abandon de panier ont chuté de dix-huit pour cent au cours du premier mois. Non pas parce que le paiement est devenu plus beau, mais parce qu'il est devenu plus rapide. Deux secondes et demie de différence - et presque un client sur cinq qui était parti auparavant attend désormais que la page se charge et paie.

Je ne prétendrai pas que COS WP Woo soit une pilule magique pour tous les problèmes du e-commerce. Il y a suffisamment de problèmes pour tout le monde et de nouveaux apparaîtront chaque jour. Mais spécifiquement lorsqu'il s'agit d'accepter des paiements - surtout si vous avez besoin de systèmes de paiement russes plus B2B - une solution unique est objectivement meilleure qu'un zoo de plugins séparés. Ce n'est pas mon opinion - c'est l'expérience de dizaines de projets et de centaines d'heures de débogage qui se sont transformées en solutions d'ingénierie concrètes.

Essayez COS WP Woo - 14 jours gratuits. Installez, configurez les passerelles de paiement en dix minutes, acceptez le premier paiement. Et puis comparez avec la façon dont cela fonctionnait auparavant. Je pense que la différence sera évidente.