Tester votre intégration

Tester votre intégration ECR vous permet de confirmer que votre système de point de vente (POS) communique correctement avec le terminal de paiement Market Pay avant le passage en production. Une campagne de test structurée permet de détecter les défauts d’intégration avant le passage en production.

Voici notre outil d’auto-test en ligne : pos-test-suite.market-pay.com

Prérequis

Vous devez disposer d’un terminal de préproduction connecté à l’hôte acquéreur de test (Dummy) de Market Pay. Aucun fonds réel ne circule : les refus et les autorisations sont simulés.

La suite de tests d’intégration du POS

La suite de tests d’intégration du POS est un carnet de tests autonome qui vous guide tout au long d’une campagne d’intégration complète et vous permet d’enregistrer vos résultats, sans compte ni serveur requis. Tout est stocké localement dans votre navigateur. Cet outil vous permet de :

  • Filtrer les tests correspondant à votre périmètre. Sélectionnez votre protocole (Cloud API, Local API HTTP ou TCP/IP, App2App) et activez ou désactivez les fonctionnalités facultatives (préautorisation, DCC, pourboire, surcharge, S&F, etc.). Le carnet masque les tests qui ne s’appliquent pas — par exemple, la catégorie Session est automatiquement supprimée pour Cloud API.
  • Couvrir l’intégralité du carnet standard réparti en six catégories : Session, Transactions, Scénarios de refus, Abandon et annulation, Résilience, Transactions spéciales.
  • Fournir pour chaque test un scénario, le montant de déclenchement exact, les champs de réponse attendus et une indication pour le développeur — ainsi que des exemples de messages de requête/réponse pour chaque protocole.
  • Enregistrer le statut réussi / échoué / non exécuté pour chaque test et exporter un instantané JSON à partager avec votre contact Market Pay ou à archiver pour la certification.
  • Personnaliser : ajouter, modifier ou supprimer des tests et des catégories entières lorsque votre intégration nécessite des éléments qui ne figurent pas dans le carnet standard.

Cartes à utiliser pour les tests

Émulateur de carte

L’outil principal de la campagne est l’émulateur de cartes des réseaux de paiement, utilisé avec le serveur Dummy. Les scénarios sont déclenchés par le montant de la transaction : le serveur Dummy renvoie un code de réponse bancaire (BRC) spécifique en fonction du montant envoyé. Cela vous permet de contrôler de manière déterministe et reproductible les refus, les erreurs, les autorisations partielles et les flux spéciaux, sans avoir besoin de différentes cartes physiques.

Cartes de test officielles

Certains réseaux de paiement fournissent des cartes de test. Ces cartes peuvent être utilisées avec notre configuration Dummy ou dans un environnement de préproduction de bout en bout si nous disposons d’un MID à configurer avec l’acquéreur attendu.

Avertissement

Transactions avec contact (puce) uniquement : selon la carte, une transaction avec contact / puce peut être refusée lorsqu’elle est utilisée avec notre serveur Dummy qui émule la réponse.  Certaines cartes attendent des données réelles de l’émetteur que nous ne sommes pas en mesure de renvoyer à la carte dans un environnement émulé.

Simulation des réponses

Notre connecteur Dummy nous permet d’émuler certains scénarios et certaines réponses en fonction du montant saisi afin de vous aider dans votre intégration :

Montant Résultat déclenché
11.00 Ne pas honorer : refus générique (BRC 100)
11.01 Carte expirée (BRC 101)
11.04 Carte soumise à restrictions (BRC 104)
11.06 Nombre maximal de tentatives de saisie du code PIN dépassé (BRC 106)
11.09 Commerçant non valide (BRC 109)
11.16 Fonds insuffisants (BRC 116)
16.20 Autorisation partielle (autorisé = 16.20 − 0,50 €), si configurée
19.07 Émetteur de la carte non opérationnel (BRC 907) : délai d’attente de l’hôte de 30 secondes
19.09 Dysfonctionnement du système (BRC 909) : déclenche le mode hors ligne s’il est configuré

Interpréter correctement le résultat

Lors de la vérification du résultat d’une transaction, vérifiez la réponse au niveau des champs, et pas uniquement le statut HTTP :

  • L’autorisation ou le refus figure dans le message, et pas uniquement dans le code HTTP. Un code HTTP 200 peut tout de même correspondre à un paiement refusé. Vérifiez le champ de résultat dans le message de réponse.
  • Local API HTTP utilise un modèle POST → interrogation. POST renvoie 202 Accepted ; vous devez ensuite effectuer des interrogations avec GET. Un code 206 signifie que le traitement est en cours — continuez les interrogations ; un code 200 indique le résultat final. Ne clôturez jamais une transaction avec un code 206.
  • Enregistrez le POITransactionID renvoyé par le terminal. Les annulations, remboursements et consultations de statut y font référence — et non à votre propre référence de vente.
  • Conservez un ServiceID unique pour chaque transaction au sein d’une session. Sa réutilisation compromet la protection contre les paiements en double.
  • Signalez séparément les autorisations hors ligne. Lorsque le résultat indique une autorisation hors ligne, votre POS doit l’enregistrer distinctement des autorisations en ligne.

Critères de finalisation : quand avez-vous terminé ?

  • Tous les tests OBLIGATOIRES sont réussis. Ils sont bloquants pour la mise en production.
  • Les tests RECOMMANDÉS sont réussis, ou tout échec est documenté et accepté.
  • Les tests CONDITIONNELS sont réussis pour chaque fonctionnalité facultative incluse dans votre périmètre (préautorisation, DCC, pourboire, surcharge, S&F, etc.).
  • Votre campagne terminée (exportée depuis la suite de tests) est partagée avec votre contact Market Pay.

Besoin d’aide pour votre campagne ? Contactez votre interlocuteur chargé de l’intégration chez Market Pay ou envoyez une demande via Market Pay Assist.

Cet article vous a-t-il été utile ?

Utilisateurs qui ont trouvé cela utile : 0 sur 0