1. Définir le parcours de paiement
Précisez les méthodes, devises, marchés et types de transactions à lancer. Identifiez les responsables de l’application, du cashier, de la configuration PaymentIQ et du compte prestataire. Cette répartition aide à orienter les problèmes vers la bonne équipe.
- Confirmez l’environnement de test ou de production et les droits nécessaires.
- Identifiez l’approche cashier ou Hosted Fields et les versions prises en charge dans la documentation actuelle.
- Décrivez les parcours de dépôt, retrait et annulation applicables au projet.
2. Suivre l’identité et la session
Consultez la documentation officielle pour les contrats d’API exacts. Suivez la création et la transmission du contexte utilisateur et de session, ainsi que le traitement des sessions invalides ou expirées. Testez depuis l’application marchande réelle.
- Vérifiez la configuration du marchand et de l’environnement dans chaque composant.
- Testez une session expirée, une action répétée et une redirection interrompue.
- Documentez le système responsable du résultat présenté à l’utilisateur.
Si un test n’atteint pas le résultat attendu, consultez le guide d’analyse des paiements échoués.
3. Vérifier méthodes, prestataires et routage
Confirmez que les méthodes attendues sont disponibles pour le client de test et que la configuration du prestataire correspond au périmètre convenu. Comparez les conditions de routage et de repli aux parcours souhaités.
- Vérifiez la disponibilité selon le marché, la devise et le scénario client.
- Confirmez les prérequis du prestataire, l’authentification et la configuration 3DS pertinente.
- Comparez le parcours attendu avec celui observé dans la transaction.
4. Tester le résultat complet
Ne vous arrêtez pas à un message de succès dans le navigateur. Suivez la transaction jusqu’à son état dans les systèmes utilisés par les opérations. Pour les résultats asynchrones, définissez le suivi des transactions en attente.
- Couvrez les succès, refus, délais dépassés, abandons et attentes lorsque ces scénarios sont pris en charge.
- Vérifiez que les actions répétées et interruptions ne créent pas d’opérations involontaires en double.
- Conservez les preuves de test, les problèmes ouverts, les responsabilités de lancement et les critères de retour arrière.
Références officielles d’intégration
Cette checklist est une méthode de revue indépendante, pas une spécification d’API. Utilisez les instructions actuelles de l’éditeur pour les endpoints, champs, identifiants et comportements propres à chaque version.
Questions fréquentes
La checklist remplace-t-elle la documentation API ?
Non. Elle structure une revue. Les endpoints, champs et comportements propres aux versions doivent être vérifiés dans la documentation actuelle de l’éditeur.
Que livre une revue d’intégration ?
Selon le périmètre : constats de configuration, scénarios de test et liste documentée des problèmes. Le parcours et les livrables sont définis avant le début du travail.
Conseil indépendant
Besoin d’un second regard avant le lancement ?
Partons d’un prestataire ou d’un parcours. Nous pouvons définir une revue de configuration, un plan de test et une liste documentée des points à résoudre.
Discuter d’une revue d’intégrationVoir les services de conseil et les livrablesLiens vérifiés le 11 septembre 2026