Checklist de validation de l'intégration E-commerce

Objectif

L'objectif est de vérifier que l'intégration prend correctement en charge l'intégralité du cycle de vie des paiements (payment lifecycle) Pay. :

Configurer → Créer la commande → Traiter le paiement → Recevoir le statut → Mettre à jour la commande marchande

Le statut de la commande au sein de la plateforme marchande doit toujours correspondre au statut de paiement réel dans Pay.

Remarque : cette checklist est destinée à servir d'outil de validation et de certification. En cas de questions techniques liées à l'implémentation, la Developer Documentation fait toujours foi.

1. Avant de commencer

Vérifiez les points suivants avant de démarrer la certification :

☐ Un Sales location de test avec des identifiants API valides est disponible.
☐ L'intégration peut communiquer avec succès avec l'API Pay.
☐ Au moins une méthode de paiement est active et disponible pour les tests.
☐ Les transactions et les commandes marchandes peuvent être vérifiées pendant les tests.

2. Configuration de l'intégrationAuthentification & Sales location

☐ L'authentification API fonctionne correctement et les identifiants sont stockés en toute sécurité et ne sont pas exposés au shopper/navigateur.
☐ Le Sales location est configurable et le code SL est utilisé lors de la création des commandes.
☐ La configuration de test et de production peuvent être séparées, de sorte que les marchands puissent basculer en toute sécurité entre environnements/identifiants sans modification de code.

Identification de l'intégration

☐ L'intégration s'identifie correctement via stats.object, en indiquant le cas échéant le nom et la version de l'intégration/application.

Pourquoi est-ce important ?

Une identification correcte permet à Pay. de reconnaître quelle intégration a créé une transaction et facilite le monitoring, le support et le dépannage.

3. Configuration du checkout

Complétez cette section lorsque l'intégration compose elle-même la sélection des méthodes de paiement ou du checkout.

Méthodes de paiement

☐ Les méthodes de paiement disponibles sont basées sur le Sales location configuré et ne sont pas codées en dur de façon permanente.

Les modifications apportées aux méthodes de paiement activées doivent pouvoir être appliquées sans qu'une nouvelle version de l'intégration soit nécessaire.

☐ Les options de checkout individuelles et groupées sont traitées correctement, y compris la méthode de paiement ou l'option de checkout sélectionnée par le shopper.
☐ Les noms et les icônes/logos Pay. disponibles des méthodes de paiement sont affichés correctement.

Configuration des méthodes de paiement

☐ Les limites de montant des méthodes de paiement sont respectées, y compris le montant minimum et maximum renvoyé.

Une méthode de paiement incapable de traiter le montant de la commande ne devrait pas être proposée comme option valide, ou le shopper doit recevoir un retour clair à ce sujet.

☐ Les champs obligatoires d'une option de checkout sont collectés et transmis correctement lors du démarrage du paiement.
☐ Les options spécifiques à une méthode de paiement sont traitées le cas échéant, sur la base de la configuration renvoyée par Pay.

Affichage du checkout

☐ L'ordre de checkout défini par Pay. est respecté le cas échéant, y compris les ordres primaire/secondaire et les ordres spécifiques par pays.
☐ Les traductions sont appliquées correctement lorsque l'intégration prend en charge plusieurs langues de checkout.

4. Création de la commande

☐ Une commande peut être créée avec succès via l'API Pay. avec le Sales location configuré.
☐ Le montant et la devise correspondent à la commande marchande et le montant est envoyé dans le format API attendu.
☐ La bonne méthode de paiement ou option de checkout est transmise lorsque le shopper a fait un choix au préalable.
☐ Le shopper est redirigé via l'URL payment/checkout renvoyée par Pay.

Informations de la commande marchande

☐ Chaque commande Pay. contient une référence marchande claire permettant de relier la transaction à la commande correspondante dans la plateforme marchande.
☐ Une description de commande claire est transmise.
☐ Les informations client et commande pertinentes sont transmises lorsqu'elles sont disponibles, telles que les coordonnées du client, l'adresse de facturation/livraison et les informations du panier.

Dans la mesure du possible, l'intégration doit utiliser des données marchandes réelles plutôt que des informations statiques de type placeholder.

5. Paiement & traitement du statut

Le statut de paiement Pay. doit être déterminant pour le statut de la commande marchande.

Le simple retour du shopper vers la boutique en ligne ne doit jamais être considéré comme une preuve de paiement réussi.

Traitement du statut

Vérifiez que l'intégration traite correctement les statuts pertinents pour les méthodes de paiement prises en charge :

☐ Les paiements réussis entraînent le statut payé/traité correct de la commande marchande.
☐ Les paiements en attente (pending) restent en attente et ne déclenchent aucun traitement de la commande tant qu'un statut définitif de réussite n'a pas été reçu.
☐ Les paiements annulés, expirés, refusés et échoués n'entraînent pas de commande marchande payée.
☐ Les paiements autorisés sont traités séparément des paiements payés/capturés lorsque l'autorisation et la capture sont prises en charge.
☐ Les statuts de vérification et autres statuts intermédiaires n'entraînent pas à tort une commande marchande payée.
☐ Les changements de statut ultérieurs sont traités correctement, de sorte qu'une commande puisse passer d'un statut intermédiaire au statut définitif.

Retour du shopper

☐ Le shopper est correctement redirigé vers l'environnement marchand après avoir finalisé ou quitté le paiement.
☐ Le shopper reçoit un retour approprié en cas de paiement réussi, en attente, annulé ou échoué.
☐ Une nouvelle tentative de paiement peut être démarrée en toute sécurité si nécessaire sans créer à tort une commande marchande en double.

6. Traitement des Exchange

Les appels Exchange garantissent que les changements de statut de paiement parviennent à la plateforme marchande, indépendamment du navigateur du shopper.

Point de terminaison Exchange

☐ Une URL Exchange valide et publiquement accessible est configurée.
☐ Les appels Exchange peuvent être traités sans session shopper active.
☐ La commande Pay. peut être associée à la bonne commande marchande et le statut reçu met à jour correctement cette commande.
☐ Le point de terminaison renvoie une réponse de succès une fois l'Exchange traité.

Fiabilité

☐ Le traitement des Exchange est idempotent.

Le fait de recevoir plusieurs fois le même Exchange ne doit pas entraîner de commandes en double, de traitement en double ou d'actions financières en double.

☐ L'intégration ne dépend pas du retour du shopper vers la boutique en ligne.

La fermeture du navigateur après le paiement ne doit pas empêcher la commande marchande de recevoir finalement le statut correct.

☐ Les erreurs temporaires lors du traitement d'un Exchange peuvent être correctement récupérées lorsque l'Exchange est proposé à nouveau.

7. Gestion des transactions

Complétez uniquement les sections prises en charge par l'intégration.

Remboursements

☐ Les remboursements complets peuvent être effectués correctement et sont liés à la bonne transaction Pay.
☐ Les remboursements partiels sont traités correctement lorsqu'ils sont pris en charge, y compris plusieurs remboursements partiels sans dépasser le montant remboursable disponible.
☐ Le statut du remboursement est traité correctement dans la plateforme marchande.

Autorisation & capture

Le cas échéant :

☐ Les transactions autorisées peuvent être capturées correctement.
☐ La capture partielle fonctionne correctement lorsqu'elle est prise en charge.
☐ Une autorisation peut être correctement annulée (void) lorsque cela est pris en charge.

8. Gestion des erreurs & supportabilité

☐ Les erreurs API sont correctement gérées sans que la commande marchande ne soit à tort considérée comme finalisée.
☐ Le fait de réessayer une requête de paiement échouée ou incertaine ne provoque pas inutilement de commandes marchandes ou de paiements en double.
☐ Les erreurs de paiement et d'Exchange sont suffisamment consignées pour permettre le dépannage.
☐ Une transaction peut être retrouvée à la fois via l'ID de commande Pay. et la référence marchande.
☐ Les identifiants API et autres secrets ne sont pas enregistrés dans les journaux.

9. Scénarios de test pour la certification

Démontrez, lors de la certification, au minimum les scénarios applicables à l'intégration :

☐ Paiement réussi
☐ Paiement annulé
☐ Paiement échoué
☐ Statut en attente → paiement réussi
☐ Le shopper ferme le navigateur avant de retourner chez le marchand
☐ Deuxième tentative de paiement après annulation/échec
☐ Double livraison d'Exchange
☐ Erreur temporaire d'API ou d'Exchange
☐ Montant minimum/maximum d'une méthode de paiement, le cas échéant
☐ Remboursement complet, si pris en charge
☐ Remboursement partiel, si pris en charge
☐ Autorisation/capture/void, si pris en charge

Les méthodes de paiement présentant des parcours de paiement sensiblement différents doivent être testées séparément.

10. Preuves pour la certification

Transmettez les éléments suivants à votre Integration Manager.

☐ Nom et version de l'intégration/application
☐ Valeur de stats.object
☐ ID du Sales location de test
☐ ID de commande Pay. et référence marchande d'un paiement réussi
☐ ID de commande Pay. d'un paiement annulé/échoué
☐ Exemple d'un paiement en attente, le cas échéant
☐ Preuve qu'un Exchange met à jour correctement la commande marchande
☐ Transaction de remboursement lorsque les remboursements sont pris en charge
☐ Aperçu des méthodes de paiement prises en charge et des fonctionnalités de gestion des transactions
☐ Éventuelles limitations connues ou fonctionnalités volontairement non prises en charge

Certification terminée

L'intégration est prête pour approbation lorsque toutes les exigences applicables ont été validées et que les scénarios de test requis ont été démontrés avec succès.

Les éléments identifiés comme non applicables doivent correspondre aux fonctionnalités que l'intégration ne propose pas.