Objectif
L'objectif est de vérifier que le parcours de paiement, l'expérience client et les informations de transaction sont correctement implémentés.
Avant de commencer
Terminez d'abord la checklist Pay.POS : Bien démarrer & choisir la bonne intégration avant de valider l'intégration Inject.
Exigences minimales
Avant de commencer la validation, vérifiez que les exigences suivantes sont remplies.
Propriété de l'intégration
L'intégration doit contenir suffisamment d'informations pour identifier le propriétaire de l'application.
Obligatoire :
- ☐ stats.object est renseigné.
- ☐ La valeur identifie le propriétaire de l'application ou de l'intégration.
- ☐ La valeur est cohérente pour toutes les transactions.
Pourquoi cela est important
Avec la valeur de stats.object Pay. peut identifier l'intégration responsable à des fins de monitoring, de support et de résolution des problèmes.
Initier une transaction
Vérifiez que l'application marchande peut démarrer correctement un paiement Pay.POS.
Obligatoire :
- ☐ L'application marchande peut initier un paiement.
- ☐ Le montant de paiement correct est transmis.
- ☐ La devise correcte est transmise.
- ☐ Une référence de transaction unique est utilisée.
- ☐ L'URL de retour configurée est disponible.
- ☐ PAY.POS s'ouvre automatiquement une fois le paiement démarré.
Avec PAY.POS Inject, une application peut envoyer une transaction à Pay.POS, qui prend ensuite en charge le parcours de paiement.
Validation du parcours de paiement
Vérifiez l'intégralité du parcours de paiement du client.
Paiement réussi
- ☐ Le client peut effectuer un paiement sans contact.
- ☐ Le paiement est finalisé avec succès.
- ☐ L'application marchande reçoit le résultat du paiement réussi.
- ☐ Le statut de la transaction correspond au résultat affiché dans PAY.POS.
Paiement échoué
- ☐ Les paiements échoués renvoient le résultat correct.
- ☐ L'application marchande traite correctement les paiements échoués.
- ☐ Le client peut réessayer le paiement si nécessaire.
Paiement annulé
- ☐ Le client peut annuler le paiement.
- ☐ En cas d'annulation, le statut correct est renvoyé.
- ☐ Aucune transaction en double n'est créée.
Traitement du retour
Une fois le paiement terminé, PAY.POS renvoie le résultat à l'application d'origine via le flux de retour configuré.
Vérifiez :
- ☐ L'application marchande reçoit le retour.
- ☐ Le statut de transaction correct est traité.
- ☐ L'utilisateur est redirigé vers l'écran correct.
- ☐ L'application ne crée pas de paiements en double après réception d'un résultat.
Expérience client
Bien que Pay.POS prenne en charge l'écran de paiement, l'ensemble de l'expérience utilisateur doit être validé.
Obligatoire :
- ☐ Il est clair pour le client à quel moment présenter la carte de paiement ou l'appareil mobile.
- ☐ Le client reçoit un retour pendant le traitement du paiement.
- ☐ Le client reçoit un résultat clair en cas de paiement réussi ou échoué.
- ☐ Le caissier sait quelle action entreprendre après chaque résultat.
Scénarios liés à l'appareil et à la connectivité
Vérifiez :
- ☐ Le paiement fonctionne avec un appareil pris en charge.
- ☐ Le NFC est activé.
- ☐ Les interruptions temporaires de connexion sont correctement gérées.
- ☐ Le scénario dans lequel PAY.POS n'est pas disponible est correctement géré.
- ☐ Le scénario de redémarrage de l'application a été testé.
Reçus
La proposition d'un reçu après un paiement réussi est obligatoire. Assurez-vous que le parcours de reçu est correctement implémenté et testé avant la mise en production de l'intégration.
Obligatoire :
- ☐ Après un paiement réussi, une option de reçu est disponible.
- ☐ Les informations figurant sur le reçu sont correctes.
- ☐ Le client reçoit le reçu avec succès.
Remboursements
Si les remboursements sont activés :
- ☐ Les remboursements peuvent être initiés via le flux Inject.
- ☐ Le montant du remboursement est correct.
- ☐ Le résultat du remboursement est traité correctement.
- ☐ Le remboursement s'affiche correctement dans le Pay. Portal.
Configuration complémentaire
Validez la configuration optionnelle le cas échéant.
Point de vente alternatif
Si des paiements sont initiés pour un autre point de vente :
- ☐ Le bon point de vente est utilisé.
- ☐ Les identifiants/la configuration requis sont disponibles.
Paramètres de langue
Si une langue PAY.POS spécifique est requise :
- ☐ La langue configurée s'affiche correctement.
Validez le flux MAT :
- ☐ L'appareil peut finaliser une transaction MAT en l'absence de connexion internet active.
- ☐ L'application marchande reçoit le résultat de transaction correct.
- ☐ La transaction n'est pas marquée à tort comme échouée lorsqu'elle est mise en attente pour un traitement ultérieur.
- ☐ La transaction est traitée avec succès dès que la connexion est rétablie.
- ☐ Le statut définitif de la transaction s'affiche correctement dans le Pay. Portal.
Important
Les transactions MAT constituent un flux d'exception et doivent être testées séparément des paiements en ligne classiques. Assurez-vous que le marchand comprenne que le traitement définitif d'une transaction MAT peut avoir lieu après que le client a déjà quitté le point de vente.
Certification de l'application
Important
La certification de l'application par Pay. est obligatoire avant que l'intégration puisse être mise en production.
Le processus de certification permet de vérifier que l'intégration répond aux exigences de Pay. et que le traitement des transactions fonctionne correctement.
Preuves de test
Rassemblez les éléments de preuve suivants pendant la validation :
- ☐ Référence d'une transaction réussie.
- ☐ Référence d'une transaction échouée.
- ☐ Référence d'une transaction annulée.
- ☐ Valeur de stats.object.
- ☐ Informations sur l'appareil.
- ☐ Captures d'écran du parcours de paiement.
Checklist de mise en production
Avant d'activer l'intégration Inject :
- ☐ Initiation des transactions testée.
- ☐ Paiement réussi testé.
- ☐ Paiement échoué testé.
- ☐ Paiement annulé testé.
- ☐ Traitement du retour vérifié.
- ☐ Parcours de reçu vérifié.
- ☐ Certification finalisée.
- ☐ Configuration de production vérifiée.