Testez votre intégration

Testez votre intégration

Tester votre intégration ECR vous permet de confirmer que votre Point de Vente (POS) communique correctement avec le terminal de paiement Market Pay avant de passer en production. Une campagne de test structurée détecte les défauts d’intégration tant qu’ils sont encore peu coûteux à corriger — en pré-production, sans impact financier.

Cet article décrit ce qu’il faut tester, comment déclencher chaque scénario, et présente la Suite de Tests d’Intégration POS — un cahier de tests autonome que vous pouvez utiliser pour exécuter et suivre votre campagne.

Avant de commencer

Confirmez que les éléments suivants sont en place :

  • Un terminal en pré-production connecté à l’hôte d’acquisition test (Dummy) de Market Pay. Aucun fonds réel ne circule — refus et approbations sont simulés.
  • Votre méthode d’intégration est définie : API locale (HTTP ou Socket/TCP-IP), API Cloud, ou App2App (Android Intent). Les tests applicables en dépendent (voir Quels tests s’appliquent à mon intégration).
  • Votre client HTTP a un délai d’attente supérieur à 90 secondes pour les appels de paiement. Plusieurs scénarios de résilience retardent volontairement la réponse de l’hôte ; un délai plus court entraînerait un échec incorrect de ces tests.

Étapes clés des tests

  1. Validez le scénario idéal. Une vente sans contact standard et une vente standard puce + code PIN qui se terminent toutes deux par un résultat approuvé et un reçu correct.
  2. Examinez les cas limites. Refus, abandons, annulations, autorisation partielle, signature requise, et transactions spéciales (annulation, remboursement, pré-autorisation, etc.).
  3. Testez la résilience. Perte de réseau en cours de transaction, redémarrage du POS, délai d’attente de l’hôte, mode hors ligne, et comportement de sondage.
  4. Vérifiez la gestion des données. Que votre POS stocke les identifiants retournés par le terminal (POITransactionID) pour les annulations, remboursements et requêtes de statut, et que ServiceID est unique par transaction.
  5. Suivez et documentez les résultats. Enregistrez réussite/échec pour chaque test afin que la campagne soit auditable avant la mise en production.

La Suite de Tests d’Intégration POS

La Suite de Tests d’Intégration POS est un cahier de tests autonome qui vous guide à travers une campagne d’intégration complète et vous permet d’enregistrer vos résultats — aucun compte ni serveur requis. Tout est stocké localement dans votre navigateur.

Elle remplace la méthode manuelle de copier-coller pour les tests d’intégration par un outil unique qui :

  • Filtre les tests selon votre périmètre. Sélectionnez votre protocole (API Cloud, API locale HTTP ou TCP/IP, App2App) et activez les fonctionnalités optionnelles (pré-autorisation, DCC, pourboire, surcharge, S&F, etc.). Le cahier masque les tests non applicables — par exemple, la catégorie Session est automatiquement retirée pour l’API Cloud.
  • Couvre l’intégralité du cahier standard réparti en six catégories : Session, Transaction, Scénarios de refus, Abandon & Annulation, Résilience, Transactions spéciales.
  • Donne à chaque test un scénario, le montant exact à déclencher, les champs de réponse attendus, et un conseil pour développeur — plus des exemples de messages requête/réponse par protocole.
  • Enregistre réussite / échec / non exécuté par test et vous permet d’exporter un instantané JSON à partager avec votre contact Market Pay ou à archiver pour certification.
  • Est personnalisable. Ajoutez, modifiez ou supprimez des tests et des catégories entières lorsque votre intégration nécessite quelque chose au-delà du cahier standard.

Comment l’utiliser : ouvrez la suite de tests, complétez la courte visite guidée, définissez votre périmètre, puis parcourez chaque catégorie en notant les résultats au fur et à mesure. Utilisez Export à la fin pour produire votre rapport de campagne.

Note

Demandez à votre contact intégration Market Pay le lien actuel vers la Suite de Tests d’Intégration POS pour votre campagne.

Quels tests s’appliquent à mon intégration

Catégorie API locale (HTTP / Socket) API Cloud App2App
Session (Connexion / Déconnexion, vérification série, diagnostic) Oui Non applicable — authentification gérée au niveau API Oui
Transaction Oui Oui Oui
Scénarios de refus Oui Oui Oui
Abandon & Annulation Oui Oui Oui
Résilience Oui Oui — mécanisme de sondage / authentification peut différer Oui — plus résolution d’Intent
Transactions spéciales Oui — dépend des fonctionnalités Oui — dépend des fonctionnalités Oui — dépend des fonctionnalités

La suite de tests applique ce filtrage pour vous une fois que vous avez défini votre périmètre.

Quelles cartes tester

Émulateur de carte (recommandé)

L’outil principal pour la campagne est l’émulateur de carte Market Pay 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 selon le montant envoyé. Cela vous donne un contrôle déterministe et répétable sur les refus, erreurs, approbations partielles et flux spéciaux — sans avoir besoin de dizaines de cartes physiques.

Par exemple (tout montant non dans la liste de déclenchement renvoie un Approuvé par défaut) :

Montant Résultat déclenché
11.00 Do Not Honor — refus générique (BRC 100)
11.01 Carte expirée (BRC 101)
11.16 Fonds insuffisants (BRC 116)
11.17 Code PIN incorrect (BRC 117)
16.00 – 17.99 Autorisation partielle (autorisé = demandé − 1,00 €)
18.00 – 18.99 Signature requise sur le reçu
19.07 Émetteur inopérant — délai de réponse de 30 secondes (BRC 907)

La correspondance complète montant-BRC (y compris plages spécifiques aux cartes) est fournie dans la suite de tests, par test.

Utiliser vos propres cartes personnelles

Vous pouvez également utiliser vos propres cartes personnelles en pré-production. Comme l’environnement de pré-production est connecté à l’hôte d’acquisition Dummy, il n’y a aucun impact financier — aucune autorisation, capture ou règlement réel n’est effectué sur votre carte.

C’est un complément utile à l’émulateur lorsque vous souhaitez valider le comportement des cartes réelles : paiements sans contact, lectures réelles de puce, saisie réelle du PIN, et expérience du titulaire sur l’écran du terminal.

Attention

Transactions à contact (puce) uniquement : selon la carte, une transaction contact/puce peut être refusée. C’est attendu et c’est une caractéristique de la carte, non un défaut de votre intégration. Les paiements sans contact ne sont généralement pas affectés. Si vous avez besoin d’une approbation garantie ou d’un motif de refus spécifique, utilisez plutôt l’émulateur de carte avec le montant déclencheur correspondant.

Lire correctement le résultat

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

  • L’approbation/refus se trouve dans le message, pas seulement dans le code HTTP. Un HTTP 200 peut toujours contenir un paiement refusé. Vérifiez le champ résultat dans le message de réponse.
  • L’API locale HTTP utilise un schéma POST → sondage. POST renvoie 202 Accepted ; vous effectuez ensuite un GET-sondage. Un 206 signifie en cours — continuez à sonder ; un 200 est le résultat final. Ne clôturez jamais une transaction sur un 206.
  • Stockez le POITransactionID retourné par le terminal. Les annulations, remboursements et requêtes de statut s’y réfèrent — pas à votre propre référence de vente.
  • Gardez le ServiceID unique par transaction dans une session. Le réutiliser casse la protection contre les paiements en double.
  • Signalez séparément les approbations hors ligne. Quand le résultat indique une approbation hors ligne, votre POS doit l’enregistrer distinctement des approbations en ligne.

Critères de sortie — quand avez-vous terminé ?

  • Tous les tests OBLIGATOIRES sont réussis. Ceux-ci bloquent 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é optionnelle dans votre périmètre (pré-autorisation, DCC, pourboire, surcharge, S&F, etc.).
  • Votre campagne complétée (export depuis la suite de tests) est partagée avec votre contact Market Pay.

Besoin d’aide pour votre campagne ? Contactez votre interlocuteur intégration Market Pay ou créez une demande via Market Pay Assist.

 

 

Tester votre intégration ECR vous permettra de vérifier que votre intégration fonctionne comme prévu avant de passer en environnement de production.

Les étapes clés des tests comprennent :

  1. Valider le scénario idéal.
  2. Examiner les scénarios non idéaux, incluant les délais d’attente et problèmes de connexion, tout en confirmant le statut des transactions.
  3. Répliquer diverses réponses des acquéreurs pour évaluer votre gestion des transactions refusées.
  4. Effectuer des tests avec différentes méthodes de vérification du titulaire de carte (CVM).

Vous pouvez obtenir des cartes émulateurs pour l’environnement de test depuis :

Note. Pour les cartes physiques, vous devez vérifier auprès de votre acquéreur ou de votre contact Market Pay.

Pour tester les scénarios non idéaux, lors de l’utilisation de l’environnement de test Market Pay, il existe une règle pour retourner un code de réponse spécifique selon le montant reçu lorsqu’il correspond au format suivant : 9XXX, où

ex. : code de réponse attendu est 116 (Fonds insuffisants). Vous devez effectuer une transaction avec le montant 9116.

Pièces jointes