Guide

Configurer Up2pay e‑Transactions en mode test

Mis à jour le 24 septembre 2026

Réponse courte

Pour tester Up2pay e‑Transactions, envoyez vos paiements vers le serveur de recette https://recette-tpeweb.e-transactions.fr/php/ avec des identifiants de test : soit ceux de votre propre compte de test, soit le compte mutualisé public du Crédit Agricole (SITE 1999887). La clé HMAC de test est différente de la clé de production : ne mélangez jamais les deux. En recette, le numéro d’autorisation vaut toujours XXXXXX et le nom de la boutique est préfixé « ***TEST*** » : c’est ainsi que vous savez que vous n’êtes pas en production.

Comment fonctionne le mode test d’Up2pay

Up2pay e‑Transactions est la marque Crédit Agricole de la plateforme Paybox, exploitée par Verifone. Le manuel Paybox System v8.3 (Verifone) et le manuel d’intégration Up2pay e‑Transactions (Crédit Agricole) décrivent le même protocole, à quelques divergences près. Votre boutique envoie le client vers une page de paiement hébergée, avec un formulaire signé par une clé HMAC. La plateforme vérifie cette signature, affiche la page de saisie de carte, puis prévient votre boutique par une notification serveur à serveur (IPN).

Il existe deux plateformes distinctes :

Plateforme	Adresse de la page de paiement
Recette (test)	`https://recette-tpeweb.e-transactions.fr/php/`
Production, serveur principal	`https://tpeweb.e-transactions.fr/php/`
Production, serveur secondaire	`https://tpeweb1.e-transactions.fr/php/`

Le document de test du Crédit Agricole de 2021 cite aussi preprod-tpeweb.e-transactions.fr. C’est un alias du même serveur de recette, avec la même adresse IP.

Les identifiants sont le SITE (7 chiffres), le RANG (2 ou 3 chiffres) et l’IDENTIFIANT (1 à 9 chiffres), avec une clé HMAC. La clé dépend de la plateforme : une clé générée pour la recette ne fonctionne pas en production, et inversement.

Étapes pas à pas

1. Choisir les identifiants de test

Le document « Up2pay e‑Transactions – Réalisation des tests d’intégration » (Crédit Agricole, 01/03/2021) publie des comptes de test mutualisés : document de test du Crédit Agricole (PDF).

Le SITE est 1999887. Le document liste plusieurs couples RANG / IDENTIFIANT :

RANG / IDENTIFIANT	Usage indiqué par le document
`32` / `215`	non 3-D Secure, plusieurs moyens de paiement
`43` / `221`	tests 3-D Secure avec les pages de paiement
`63` / `222`	3-D Secure via API (hors page de paiement hébergée)
`85` / `218`	non 3-D Secure, pages et API

Seul le compte SITE 1999887, RANG 32, IDENTIFIANT 215 a été constaté actif le 24/09/2026, avec l’enseigne « ***TEST*** BOUTIQUE TESTS E-TRANSACTIONS ». Les rangs 43, 63 et 85 n’ont pas été vérifiés. Pour le rang 43, le document lui-même se contredit : il l’annonce pour les tests 3-D Secure, puis indique qu’on ne peut pas y initier de paiement 3-D Secure. Si vous avez votre propre compte de test chez le Crédit Agricole, préférez-le.

2. Récupérer la clé HMAC de test

Ne cherchez pas la clé de démonstration sur un forum ou dans un exemple de code. Elle est publiée à deux endroits :

en page 7 du document de test du Crédit Agricole cité plus haut (128 caractères hexadécimaux) ;
dans l’onglet « Paramètres » du back-office Vision des comptes de test, selon le même document.

Pour votre propre compte, la clé se génère dans Vision. Copiez-la sans espace ni retour à la ligne : une clé HMAC ne contient que des caractères hexadécimaux (0-9, A-F).

3. Renseigner les réglages de votre module

Quel que soit le module utilisé, vous devez indiquer :

le mode (test) ;
l’URL du serveur de recette, si votre module ne la préremplit pas ;
SITE, RANG et IDENTIFIANT de test ;
la clé HMAC de test.

Le RANG peut être saisi sur 2 ou 3 chiffres : 32 et 032 sont acceptés en recette, 0032 est refusé. La plateforme renvoie elle-même le rang sur 3 chiffres.

4. Faire un paiement avec une carte de test

En recette, la date d’expiration et le cryptogramme ne sont pas contrôlés, selon le document de test. Cartes publiées :

CB (document de test du Crédit Agricole) : 1111222233334444 (enrôlée 3-D Secure), 4012001037141112, 4012001038443335 (non enrôlée).
3-D Secure v2 Visa (manuel DSP2 de Verifone) : succès sans authentification forte 4000000000001000, échec sans authentification forte 4000000000001018, succès avec authentification 4000000000001091, échec 4000000000001109.
3-D Secure v2 Mastercard : succès sans authentification forte 5200000000001005, échec 5200000000001013.

Pour les cartes DSP2, le manuel indique comme date d’expiration « January of the following year ».

Le document de 2021 précise que la recette simule le 3-D Secure et « valide systématiquement ». La documentation ne dit pas si la recette de 2026 applique le simulateur DSP2 avec ses cas d’échec : ne tirez pas de conclusion d’un succès sur une carte censée échouer.

5. Vérifier le résultat

Un paiement de test réussi se reconnaît à deux signes :

la page de paiement affiche l’enseigne préfixée « ***TEST*** » ;
le numéro d’autorisation reçu vaut XXXXXX.

Regardez aussi à quel moment votre commande WooCommerce change de statut. Selon le manuel Paybox System v8.3, l’URL de retour du client (PBX_EFFECTUE) « n’est pas sécurisée » et « n’est pas garantie ». Le statut devrait donc changer à la réception de la notification (IPN), pas au retour du client sur la boutique.

Pour simuler un refus sans carte particulière, le manuel décrit une variable PBX_ERRORCODETEST, utilisable en mode test uniquement, jamais en production.

Pièges fréquents

« Incohérence des paramètres / Accès refusé ». Si le message mentionne « Error while proceeding authentication with HMAC key », la plateforme refuse la signature. Causes possibles : clé de production utilisée sur la recette (ou l’inverse), clé mal copiée, champs signés dans un autre ordre que celui du formulaire, valeurs encodées URL avant le calcul au lieu des valeurs brutes. Voir la page sur cette erreur.

Code 00006. Accès refusé, ou SITE, RANG, IDENTIFIANT incorrects. Vérifiez ces trois valeurs et la clé. Voir code 00006.

La commande reste « En attente de paiement ». L’IPN doit pouvoir joindre votre site depuis Internet. Un site en local (localhost) ne la reçoit pas. Les ports admis côté marchand sont 80, 443 et 8080 à 8085. Si votre boutique ne répond pas par un code 2xx, Verifone envoie un e‑mail « PAYBOX: WARNING!! ». L’URL de notification passée dans le paramètre PBX_REPONDRE_A est prioritaire sur celle enregistrée dans Vision.

Trop d’essais d’affilée. Le 24/09/2026, après environ 75 requêtes en une minute et demie, la recette a renvoyé 403 Forbidden sur toutes ses adresses, et le blocage a duré plus d’une heure. Espacez vos tests.

Devise. Up2pay n’accepte que l’euro (code 978). Une boutique qui vend dans une autre devise ne peut pas encaisser de paiement par Up2pay.

Passage en production. Changer le mode ne suffit pas : il faut aussi les identifiants et la clé de production, et les URL tpeweb et tpeweb1.

Documentation de référence : manuel d’intégration Up2pay e‑Transactions du Crédit Agricole.

Ce que fait Relqor

Le plugin Relqor pour Up2pay e‑Transactions garde deux jeux de réglages séparés, test et production (SITE, RANG, IDENTIFIANT, clé HMAC), et préremplit les URL de recette et de production, modifiables. Avant de rediriger le client, il vérifie la disponibilité du serveur par la page load.html. Le résultat est gardé 60 secondes, pour ne pas relire la page à chaque commande. En production, il bascule si besoin sur le serveur secondaire tpeweb1. En recette, aucun serveur secondaire n’est prérempli. Seule la notification vérifiée change le statut de la commande ; la page de retour ne le change jamais. La clé est masquée dans l’administration et n’apparaît jamais dans les journaux. Détails sur la page Up2pay e‑Transactions et dans la documentation mode test et production.