Menu

Mercanet, Sherlock’s, Sogenactif (Sips)

Relqor Sips : mode test et passage en production

Mis à jour le

Les environnements de test

Chaque banque met à disposition un environnement de test (simulation, ou recette pour Mercanet) avec des comptes publics. Les identifiants de ces comptes sont publiés dans la documentation de chaque banque, à l’« Étape 3 » de la page Paypage POST :

BanqueOù trouver les comptes publicsParticularité
Worldline SipsSips Paypage POST, Étape 3, « Table 1 : transactionReference généré par le commerçant »4 comptes (Tables 1 à 4)
MercanetMercanet Paypage POST, Étape 3, « Tester sur l’environnement de recette »serveur de recette, euro uniquement
Sherlock’sSherlock’s Paypage POST, Étape 3, « Table 1 : transactionReference généré par Sherlock’s »un seul compte public
SogenactifSogenactif Paypage POST, Étape 3, « Table 1 : transactionReference généré par le commerçant »4 comptes

Saisissez les identifiants du compte choisi dans les champs test des réglages, puis sélectionnez le mode test.

Ces comptes sont partagés entre tous les commerçants. Le plugin crée une nouvelle référence, avec un suffixe aléatoire, à chaque affichage du formulaire de paiement, pour éviter les refus pour référence déjà utilisée.

Les cartes de simulation

Sur les environnements de simulation Worldline Sips, Sherlock’s et Sogenactif, le résultat dépend du numéro de carte :

  • les 6 premiers chiffres donnent le type de carte (par exemple 410000 pour VISA, 420000 pour CB, 510000 pour MASTERCARD) ;
  • les 2 derniers chiffres donnent le code réponse ;
  • le cryptogramme est quelconque (3 ou 4 chiffres).

Exemple de la documentation : 4100 0000 0000 0005 donne un refus (code 05). Un code non référencé donne un paiement accepté (00). En simulation, toutes les cartes sont enrôlées 3-D Secure : vous choisissez le résultat de l’authentification sur la page de simulation.

Mercanet publie ses propres cartes de test (page cartes-de-test.html de la documentation Mercanet), par exemple 4112948576210600 (acceptée) et 5017679110380905 (refusée, 05), avec une date d’expiration égale ou postérieure au mois en cours et un cryptogramme de 3 chiffres.

La réponse automatique, seule source de statut

Seule la réponse automatique de Sips, envoyée de serveur à serveur et dont le sceau est valide, change le statut d’une commande. Le retour du client sur votre site (bouton « Continuer ») ne modifie jamais la commande, car il passe par le navigateur. Tant que la réponse automatique n’est pas arrivée, la page « commande reçue » affiche « Paiement en cours de confirmation ».

Le plugin envoie l’adresse de réponse automatique avec chaque demande de paiement :

https://<site>/?wc-api=relqor_sips_notify

Pour recevoir cette réponse, votre site doit être joignable depuis Internet. Un site installé en local ne la reçoit pas. La réception réelle de la réponse automatique a été vérifiée le 24/09/2026 sur un site de test public, avec un paiement de test par banque (Sips, Mercanet, Sherlock’s, Sogenactif) : elle a suffi, sans clic sur « Continuer », à faire passer la commande en « En cours ». Testez-la aussi sur votre propre site avant la mise en production.

Avant tout changement, le plugin contrôle le sceau, puis le merchantId et la keyVersion du mode actif, la référence, la commande, le mode, le montant et la devise. Un sceau faux reçoit une réponse HTTP 403 et la commande n’est pas touchée. Un contrôle en échec ajoute une note sur la commande, si elle est retrouvée, et une erreur dans le journal, sans changer son statut.

Codes réponse et statuts WooCommerce

Code(s) responseCodeStatut de la commande
00 avec captureMode AUTHOR_CAPTURE ou IMMEDIATEpayée (via le traitement standard de WooCommerce)
00 avec un autre captureMode (VALIDATION, AUTHOR_NOCAPTURE) ou sans captureModeen attente, note « autorisation acceptée, remise en attente de validation »
60, 62en attente
05 avec scoreColor=ORANGEen attente, à valider dans l’extranet
17 (annulation par l’acheteur), 97 (session expirée ou abandon)annulée
02 03 05 11 12 14 30 34 40 51 54 55 57 63 75 90 99échouée
01 24 25 94, code inconnu ou absentaucun changement, note seulement

Règles complémentaires :

  • une commande déjà payée ne revient jamais en arrière ;
  • une annulation, un refus ou une mise en attente ne s’appliquent qu’à la dernière tentative de paiement d’une commande encore « en attente de paiement » ;
  • chaque réponse traitée ajoute une note avec le code, son libellé, la référence et les informations d’authentification, sans aucune donnée de carte.

captureMode : pourquoi une commande acceptée peut rester en attente

Le plugin n’envoie pas de captureMode : la configuration de votre boutique chez Worldline s’applique. En mode VALIDATION, les fonds ne sont remisés qu’après une action de votre part (validation de la transaction) : une réponse 00 met donc la commande en attente. Traitez-la ensuite.

Une réponse d’un autre mode est ignorée

Chaque tentative de paiement mémorise le mode (test ou production) dans lequel elle a été créée. Une réponse qui concerne une tentative créée dans un autre mode que le mode actif est ignorée. Une réponse de simulation ne peut donc jamais payer une commande en production.

Passer en production

  1. Vérifiez qu’un paiement de test complet a bien changé le statut de la commande sur votre site.
  2. Saisissez le merchantId, la keyVersion et la clé secrète de production.
  3. Vérifiez le réglage « banque ».
  4. Passez le mode sur « production » et enregistrez.

Voir aussi : Commande restée en attente après un paiement.