Up2pay e‑Transactions
Mode test et passage en production (Up2pay)
Le plugin a deux modes : test et production. Chaque mode a ses propres identifiants, sa propre clé HMAC et ses propres serveurs. Vous passez de l’un à l’autre avec le réglage « Mode ».
Les serveurs
| Plateforme | URL de la page de paiement |
|---|---|
| Recette (test) | https:// |
| Production, principal | https:// |
| Production, secondaire | https:// |
Ce sont les hôtes indiqués dans le manuel d’intégration Up2pay e‑Transactions du Crédit Agricole. Ils sont préremplis dans les réglages.
Le compte de test mutualisé
Le document « Up2pay e‑Transactions – Réalisation des tests d’intégration » du Crédit Agricole publie un compte de test partagé : SITE 1999887. Plusieurs couples RANG / IDENTIFIANT y sont listés. Le couple 32 / 215 (sans 3-D Secure, plusieurs moyens de paiement) était actif le 24/09/2026. Les autres couples n’ont pas été testés.
La clé HMAC de démonstration de ce compte figure dans ce même document. Elle est aussi disponible dans l’onglet « Paramètres » du back-office Vision de ces comptes. Nous ne la reproduisons pas ici.
Si votre banque vous a fourni des identifiants de test propres à votre boutique, utilisez-les.
Les cartes de test
En recette uniquement. La date d’expiration et le cryptogramme ne sont pas contrôlés. Pour les cartes 3-D Secure v2, la documentation indique une expiration en janvier de l’année suivante.
| Carte | Cas prévu par la documentation |
|---|---|
4000000000001000 (Visa) | succès sans authentification forte |
4000000000001018 (Visa) | échec sans authentification forte |
4000000000001091 (Visa) | succès avec authentification |
5200000000001005 (Mastercard) | succès sans authentification forte |
1111222233334444 (CB) | carte enrôlée 3-D Secure |
La documentation de 2021 indique que la recette simule le 3-D Secure et le valide systématiquement. Les cas d’échec peuvent donc ne pas se produire en recette.
Ce que vous voyez en recette
- Le nom de la boutique est précédé de « ***TEST*** » sur la page de paiement.
- Le numéro d’autorisation vaut toujours
XXXXXX.
Vérifier un paiement de test
- Passez une commande sur votre boutique et payez avec une carte de test.
- Au retour, la page de confirmation peut afficher « Paiement en cours de confirmation » : la notification (IPN) n’est pas encore arrivée. Rechargez la page un peu plus tard.
- Dans WooCommerce › Commandes, ouvrez la commande. Un paiement accepté la fait passer en « En cours », ou en « Terminée » si tous les articles sont virtuels et téléchargeables.
- Lisez la note de commande : « Paiement accepté », suivie du numéro d’autorisation, du numéro de transaction et des informations 3-D Secure.
- Ouvrez WooCommerce › État › Journaux et choisissez la source
relqor. Sur un site en français, les messages s’affichent en français (ils sont écrits en anglais et traduits). Ils contiennent l’ID de commande et la référence du paiement.
La notification (IPN) et PBX_REPONDRE_A
Le plugin envoie l’adresse de notification, ?wc-api=relqor_ipn, avec chaque paiement (paramètre PBX_REPONDRE_A). Elle est prioritaire sur l’URL enregistrée dans Vision.
La plateforme appelle cette adresse à chaque tentative, acceptée ou refusée. Le plugin vérifie la signature avant toute modification. Une signature invalide est refusée et la commande ne change pas. La page de retour du client, elle, ne change jamais le statut.
Correspondance des statuts
| Résultat | Statut WooCommerce |
|---|---|
Paiement accepté (00000 avec autorisation) | En cours (ou Terminée si virtuel et téléchargeable) |
En attente de validation par la banque (99999) | En attente ; une notification définitive suit |
Refus bancaire (001xx) et autres erreurs | Échouée, avec le code dans la note |
| Code inconnu | Échouée, note « Code de retour inconnu » |
Le client voit un message de refus générique, sans le code. Le code précis figure dans la note de commande et dans le journal. Une commande déjà payée ne repasse jamais à un statut inférieur.
Passer en production
- Récupérez vos identifiants de production : SITE, RANG, IDENTIFIANT.
- Récupérez votre clé HMAC de production. Elle est distincte de la clé de test : une clé de test ne fonctionne pas en production.
- Saisissez-les dans le jeu « production » des réglages.
- Réglez le mode sur production et enregistrez.
- Nous vous conseillons de faire un premier paiement réel d’un faible montant, puis de vérifier le statut, la note de commande et le journal comme ci-dessus.
La clé expire un an après son activation, sans être désactivée automatiquement. Notez sa date.
Test de disponibilité et bascule
Avant de rediriger le client, le plugin vérifie que le serveur répond, avec la méthode décrite dans le manuel Paybox System : il lit la page load.html du serveur principal et contrôle qu’elle indique OK.
- Si le principal ne répond pas, le plugin essaie le secondaire et écrit un avertissement dans le journal.
- Si aucun ne répond, le client n’est pas redirigé : il voit un message et le journal enregistre une erreur.
- Le résultat est gardé 60 secondes par serveur, pour ne pas interroger la plateforme à chaque commande.
Voir aussi : Installation et réglages et Commande restée « En attente de paiement ».