Liste de contrôle QA

Parcourez cette liste de contrôle dans l’environnement sandbox, puis effectuez les vérifications de production avant d’accepter des paiements réels. Elle couvre les résultats de paiement, la vérification, les nouvelles tentatives, la configuration et la sécurité. Cochez chaque point à mesure que vous le vérifiez.

1. Résultats de paiement

Paiement réussiPO-1Payez avec 4242 4242 4242 4242. La session récupérée a paymentStatus: successful et la commande est traitée une seule fois. Carte refuséePO-2Payez avec 4916 0184 7581 4056. La commande reste impayée, et une nouvelle tentative avec la carte de paiement réussi fonctionne tant que la session est ouverte. 3-D SecurePO-3Payez avec 4012 0018 0000 0016 et effectuez le challenge. Le traitement de la commande attend le statut récupéré. Erreur de traitementPO-4Utilisez une carte de test d’erreur de traitement pour la passerelle de test. La commande reste impayée même si le formulaire de carte a accepté la carte. États non gérésPO-5Votre code considère unpaid, failed, action_needed, cancelled et les valeurs inconnues comme non payés. Voir Statut du paiement.

2. Vérification et traitement de la commande

Vérification côté serveurVF-1Le traitement de la commande compare la référence de commande, le montant, la devise et le paymentStatus avec la commande enregistrée, et non avec la redirection. URL de succès sans paiementVF-2Ouvrez directement l’URL de succès sans payer. La commande reste impayée. Lien d’annulationVF-3Suivez le lien d’annulation du Checkout. La commande reste impayée, et votre code ne déduit pas un statut cancelled de la seule navigation. Retour répétéVF-4Après un paiement réussi, rechargez deux fois la page de retour. La commande est traitée une seule fois.

3. Nouvelles tentatives et interruptions

Utilisez une nouvelle commande de test et une nouvelle session pour chaque cas indépendant. Pour les tests de nouvelle tentative, réutilisez la commande d’origine, le corps de la requête et l’idempotency key.

Réponse de création perdueRI-1Ignorez la réponse de création dans votre banc de test et recommencez avec le même Idempotency-Key et le même corps. La session d’origine est rejouée et aucune deuxième session n’est créée. Corps modifiéRI-2Réutilisez une clé avec un corps différent. L’API renvoie HTTP 409 et votre code ne le traite pas comme une nouvelle session. Le client ne revient jamaisRI-3Payez, puis fermez l’onglet avant le retour. Votre tâche de rapprochement récupère la session stockée et enregistre le paiement une seule fois. Délai d’attente du statutRI-4Provoquez l’expiration du délai de récupération. Votre application conserve l’ID de session, laisse le résultat non résolu et ne crée pas de session de remplacement. Session remplacéeRI-6Créez une deuxième session pour la même commande impayée. La première URL indique expired et ne permet pas de payer. Une fois la commande payée, la création d’une autre session renvoie HTTP 409. Expiration de la sessionRI-5Attendez que expiresAt (30 minutes) soit dépassé et rouvrez l’URL. Aucun nouveau paiement ne peut démarrer et la commande reste impayée.

4. Paramètres du Checkout

Commerçant approuvéCS-1Chaque commerçant pour lequel vous acceptez des paiements figure dans le tableau Checkout merchants avec le statut Ready. Destinations de retourCS-2Les URL de succès et d’annulation par défaut sont définies pour l’identifiant que vous utilisez (valeurs par défaut de l’organisation pour la Secret key, paramètres du commerçant pour une clé de commerçant), utilisent HTTPS, et leurs origines exactes figurent dans les Allowed websites de cet identifiant. Remplacements par sessionCS-3Tout successUrl ou cancelUrl que vous envoyez correspond à une origine configurée. PortefeuillesCS-4Apple Pay et Google Pay sont activés ou désactivés comme prévu. Google Pay en production dispose d’un Google Pay merchant ID configuré. Portefeuilles intégrésCS-6Le total du portefeuille correspond à la commande côté serveur. Modifier la livraison ou les remises le met à jour. L’annulation dans le portefeuille laisse le checkout disponible, et les paiements en attente bloquent un autre débit. Image de marqueCS-5La couleur et le logo s’affichent correctement dans Checkout preview, en mise en page ordinateur comme mobile.

5. Sécurité

Clé sur le serveurSE-1Votre clé checkout de commerçant ou la Secret key de votre organisation se trouve uniquement dans la configuration du serveur, jamais dans le code du navigateur, les bundles d’applications ou le gestionnaire de versions. Totaux fixés par le serveurSE-2Le montant, la devise et l’ID de commande proviennent de votre commande enregistrée, jamais du navigateur. Endpoints des paiements intégrésSE-3Si vous utilisez les paiements intégrés, prepare et submit sont liés à un checkout authentifié ou à un cookie HTTP-only signé, et les origines des requêtes de modification sont validées. Content Security PolicySE-4Si vous utilisez les paiements intégrés, votre CSP autorise les origines de script et de frame de Tapaya, et les challenges 3-D Secure fonctionnent toujours avec elle.

6. Configuration de la sandbox

API de la sandboxPR-1TAPAYA_CHECKOUT_API_URL pointe vers https://api.sandbox.tapaya.com. Clé de la sandboxPR-2L’intégration utilise une clé checkout de commerçant ou une Secret key d’organisation de la sandbox, chargée depuis la configuration du serveur. Tâche de rapprochementPR-3La tâche qui récupère les sessions non résolues est planifiée dans votre environnement de test.

7. Préparation à la production

Préparation du commerçantLV-1Le commerçant en production a effectué l’onboarding avec les paiements en ligne, a obtenu l’approbation du processeur et dispose d’une passerelle de paiement configurée. Le commerçant est Ready dans les paramètres du Checkout. Identifiants de productionLV-2Le serveur utilise les identifiants de production et https://api.tapaya.com. Les intégrations via le SDK définissent TAPAYA_ENVIRONMENT=production. Les clés de la sandbox et les cartes de test ne sont pas utilisées pour les paiements réels. Portefeuilles en productionLV-3Les domaines de boutique Apple Pay sont actifs. Google Pay en production dispose d’un merchant ID configuré. Les portefeuilles pris en charge permettent de finaliser un paiement et fonctionnent de nouveau après une annulation. Rapprochement en productionLV-4Les URL de retour de production, la vérification côté serveur, le traitement de la commande et la tâche de rapprochement utilisent la configuration de production. Il manque quelque chose sur cette page ?Demandez une fonctionnalité. Nous joignons cette page pour que l’équipe ait le contexte.