Guide

Mercanet et WooCommerce : fonctionnement et configuration

Mis à jour le 24 septembre 2026

Réponse courte

Mercanet, la solution de paiement en ligne de BNP Paribas, repose sur Worldline Sips 2.0. Avec WooCommerce, vous utilisez la page de paiement hébergée « Paypage POST ». La boutique prépare un formulaire scellé (HMAC-SHA-256). Le navigateur du client l’envoie à Mercanet. Le client paie sur la page de la banque. Mercanet prévient ensuite la boutique par une « réponse automatique ». Pour configurer, il vous faut trois valeurs par environnement : merchantId, keyVersion et la clé secrète. Seule la réponse automatique, à sceau valide, doit faire passer une commande en payée.

Comment Mercanet fonctionne avec une boutique

Mercanet, Sherlock’s (LCL) et Sogenactif (Société Générale) utilisent le même protocole Sips 2.0. Les champs, le calcul du sceau et les codes réponse sont identiques. Seuls changent les adresses des serveurs, les comptes de test et le nom des extranets. Le fonctionnement décrit ci-dessous vaut donc aussi pour les deux autres banques. Les adresses (étape 2), les comptes et les cartes de test (étape 4) sont en revanche propres à Mercanet.

La requête de paiement

Le navigateur du client envoie automatiquement un formulaire POST vers l’adresse paymentInit de Mercanet. Il vaut mieux y mettre ces cinq champs :

Champ	Contenu
`Data`	les données du paiement, des paires `clé=valeur` séparées par une barre verticale, encodées en base64
`InterfaceVersion`	`HP_3.4`, version recommandée par la documentation
`Seal`	le sceau HMAC-SHA-256 de `Data` encodée
`SealAlgorithm`	`HMAC-SHA-256`
`Encode`	`base64`

La documentation Sips classe les deux derniers, SealAlgorithm et Encode, parmi les données optionnelles. Le premier permet d’obtenir un sceau HMAC-SHA-256. Le second indique que Data est encodée en base64. Cet encodage est imposé dès que Data contient des caractères spéciaux, comme des accents.

Dans Data, les champs obligatoires sont le montant en centimes (amount), la devise (currencyCode, 978 pour l’euro), merchantId, keyVersion, l’adresse de retour du client (normalReturnUrl) et le canal (orderChannel=INTERNET). L’adresse de la réponse automatique (automaticResponseUrl) est facultative pour Sips, mais indispensable pour une boutique fiable.

Le sceau

Le sceau se calcule sur Data telle qu’envoyée (donc encodée), avec la clé secrète utilisée comme texte UTF-8. Contrairement à la clé HMAC d’Up2pay, elle n’est pas décodée depuis l’hexadécimal. Si SealAlgorithm est absent, Sips applique par défaut un SHA-256 simple, que la documentation ne recommande plus.

Les deux réponses

Mercanet renvoie deux réponses au contenu identique :

la réponse manuelle, envoyée par le navigateur vers normalReturnUrl quand le client clique sur « Continuer ». Elle n’est pas assurée : le client peut fermer la page ;
la réponse automatique, envoyée de serveur à serveur en POST vers automaticResponseUrl. En cas d’abandon, elle arrive environ 15 à 16 minutes après la redirection, avec le code 97. Selon la documentation, elle peut aussi arriver en retard, ou jamais.

Une réponse sans sceau, ou avec un sceau faux, doit être ignorée. La documentation Sips dit alors de laisser la transaction en l’état.

3-D Secure

Avec Paypage, vous n’avez aucun champ 3-D Secure à renseigner : il est activé par défaut sur toute nouvelle boutique. Évitez de demander une authentification sans challenge (champ fraudData.challengeMode3DS) : selon le guide 3-D Secure de Sips, l’indicateur guaranteeIndicator passe alors à N. Le paiement perd ainsi la protection apportée par 3-D Secure.

Configurer pas à pas

1. Réunir vos identifiants

Pour chaque environnement (test et production), notez :

le merchantId (identifiant de boutique, jusqu’à 15 chiffres) ;
la keyVersion (version de la clé) ;
la clé secrète.

La documentation ne fixe pas le format de la clé secrète. Collez-la telle quelle, sans espace.

2. Choisir la bonne adresse de serveur

Adresses paymentInit de Mercanet :

recette (test) : https://payment-webinit-mercanet.test.sips-services.com/paymentInit ;
production : https://payment-webinit.mercanet.com/paymentInit.

Le dictionnaire de données cite aussi une adresse de simulation https://payment-webinit.simu.mercanet.com/paymentInit. Le 24/09/2026, la résolution DNS de ce nom de domaine échouait. Le test sur le serveur de recette ci-dessus a fonctionné.

3. Rendre l’adresse de réponse automatique joignable

La boutique la transmet dans chaque requête de paiement (champ automaticResponseUrl de Data). Elle doit être joignable depuis Internet. Sips accepte les ports 80 à 9999. Un site en local ne reçoit pas la réponse automatique.

4. Tester en recette

Les identifiants de test publics figurent à l’étape 3 « Tester sur l’environnement de recette » de la page Mercanet Paypage POST. Ce serveur de recette n’accepte que l’euro.

Les cartes de test sont sur la page cartes de test Mercanet. Exemples : 4112948576210600 (code acquéreur 00, accepté) et 5017679110380905 (05, refusé). Date d’expiration égale ou postérieure au mois en cours, cryptogramme à 3 chiffres.

Parcours observé en recette le 24/09/2026 : page de choix « Payer par carte », saisie de la carte, puis ticket. La carte 4112948576210600 n’étant pas enrôlée, aucune page 3-D Secure ne s’est affichée.

5. Lire le résultat

Le champ responseCode de la réponse donne l’issue :

Code	Sens
`00`	autorisation acceptée
`60`, `62`	en attente
`17`, `97`	annulation par l’acheteur, session expirée ou abandon
`05` avec `scoreColor=ORANGE`	avertissement fraude : autorisé par l’acquéreur, à accepter ou refuser par le commerçant
`05`, `51` et autres codes de refus	refusé

Attention au code 00 : il signifie « autorisé », pas forcément « remisé ». Si votre boutique est en captureMode VALIDATION, les fonds ne sont pas remisés sans action de votre part.

Pièges fréquents

Code 34 après un changement de clé. Une nouvelle clé impose une nouvelle keyVersion. Voir Sips : code 34.

Code 94 « Transaction dupliquée ». La transactionReference doit être unique pendant toute la vie de la boutique. Un client qui actualise la page ou revient en arrière doit recevoir une nouvelle référence. Le merchantId de test est public, donc partagé avec tous ceux qui testent, en recette Mercanet comme en simulation Sips. Pour la simulation, la documentation Sips recommande de préfixer vos références. Voir transaction dupliquée.

Commande restée en attente. La réponse automatique n’est pas arrivée ou a été rejetée (sceau, montant, référence). Voir commande en attente.

Mélange test et production. Une réponse issue d’un paiement de test ne doit jamais valider une commande en production.

Pas de serveur de secours documenté. La documentation Sips 2.0 ne décrit ni page de disponibilité ni serveur de secours. Aucune liste d’adresses IP sortantes n’est publiée : seul le sceau fait foi.

Ce que fait Relqor

Le plugin « Relqor — Gateway for Worldline Sips » (version 0.1.0) est terminé, mais pas encore publié sur WordPress.org. Il propose :

un réglage « banque » (Mercanet, Sherlock’s, Sogenactif ou Sips générique) avec des adresses figées ;
des identifiants séparés pour le test et la production ;
un sceau HMAC-SHA-256 dans les deux sens ;
un changement de statut uniquement par la réponse automatique vérifiée ;
une nouvelle référence à chaque affichage du formulaire.

Il n’écrase pas la configuration de votre boutique chez Worldline : il n’envoie ni captureMode, ni captureDay, ni liste de moyens de paiement, ni fraudData.challengeMode3DS. Les valeurs par défaut de votre boutique s’appliquent donc. Le 24/09/2026, sur un site de test public, la réponse automatique de la recette Mercanet a été reçue et a fait passer à elle seule la commande en « En cours », sans clic sur « Continuer ». Voir la page Mercanet et la documentation installation et réglages Sips.