# Liste de contrôle QA (/fr/online/getting-started/checklist)



Parcourez cette liste de contrôle dans l’[environnement sandbox](./testing), 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.

<ChecklistProgress />

## 1. Résultats de paiement [#1-payment-outcomes]

<ChecklistItem id="OP-PO-1" code="PO-1" title="Paiement réussi">
  Payez avec 

  `4242 4242 4242 4242`

  . La session récupérée a 

  `paymentStatus: successful`

   et la commande est traitée une seule fois.
</ChecklistItem>

<ChecklistItem id="OP-PO-2" code="PO-2" title="Carte refusée">
  Payez 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.
</ChecklistItem>

<ChecklistItem id="OP-PO-3" code="PO-3" title="3-D Secure">
  Payez avec 

  `4012 0018 0000 0016`

   et effectuez le challenge. Le traitement de la commande attend le statut récupéré.
</ChecklistItem>

<ChecklistItem id="OP-PO-4" code="PO-4" title="Erreur de traitement">
  Utilisez 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.
</ChecklistItem>

<ChecklistItem id="OP-PO-5" code="PO-5" title="États non gérés">
  Votre code considère 

  `unpaid`

  , 

  `failed`

  , 

  `action_needed`

  , 

  `cancelled`

   et les valeurs inconnues comme non payés. Voir 

  [Statut du paiement](/online/integration/api_integration#payment-status)

  .
</ChecklistItem>

## 2. Vérification et traitement de la commande [#2-verification-and-fulfillment]

<ChecklistItem id="OP-VF-1" code="VF-1" title="Vérification côté serveur">
  Le 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.
</ChecklistItem>

<ChecklistItem id="OP-VF-2" code="VF-2" title="URL de succès sans paiement">
  Ouvrez directement l’URL de succès sans payer. La commande reste impayée.
</ChecklistItem>

<ChecklistItem id="OP-VF-3" code="VF-3" title="Lien d’annulation">
  Suivez 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.
</ChecklistItem>

<ChecklistItem id="OP-VF-4" code="VF-4" title="Retour répété">
  Après un paiement réussi, rechargez deux fois la page de retour. La commande est traitée une seule fois.
</ChecklistItem>

## 3. Nouvelles tentatives et interruptions [#3-retries-and-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.

<ChecklistItem id="OP-RI-1" code="RI-1" title="Réponse de création perdue">
  Ignorez 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.
</ChecklistItem>

<ChecklistItem id="OP-RI-2" code="RI-2" title="Corps modifié">
  Réutilisez une clé avec un corps différent. L’API renvoie HTTP 409 et votre code ne le traite pas comme une nouvelle session.
</ChecklistItem>

<ChecklistItem id="OP-RI-3" code="RI-3" title="Le client ne revient jamais">
  Payez, 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.
</ChecklistItem>

<ChecklistItem id="OP-RI-4" code="RI-4" title="Délai d’attente du statut">
  Provoquez 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.
</ChecklistItem>

<ChecklistItem id="OP-RI-6" code="RI-6" title="Session remplacée">
  Cré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.
</ChecklistItem>

<ChecklistItem id="OP-RI-5" code="RI-5" title="Expiration de la session">
  Attendez que 

  `expiresAt`

   (30 minutes) soit dépassé et rouvrez l’URL. Aucun nouveau paiement ne peut démarrer et la commande reste impayée.
</ChecklistItem>

## 4. Paramètres du Checkout [#4-checkout-settings]

<ChecklistItem id="OP-CS-1" code="CS-1" title="Commerçant approuvé">
  Chaque commerçant pour lequel vous acceptez des paiements figure dans le tableau 

  **Checkout merchants**

   avec le statut 

  **Ready**

  .
</ChecklistItem>

<ChecklistItem id="OP-CS-2" code="CS-2" title="Destinations de retour">
  Les 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.
</ChecklistItem>

<ChecklistItem id="OP-CS-3" code="CS-3" title="Remplacements par session">
  Tout 

  `successUrl`

   ou 

  `cancelUrl`

   que vous envoyez correspond à une origine configurée.
</ChecklistItem>

<ChecklistItem id="OP-CS-4" code="CS-4" title="Portefeuilles">
  Apple 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é.
</ChecklistItem>

<ChecklistItem id="OP-CS-6" code="CS-6" title="Portefeuilles intégrés">
  Le 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.
</ChecklistItem>

<ChecklistItem id="OP-CS-5" code="CS-5" title="Image de marque">
  La couleur et le logo s’affichent correctement dans 

  **Checkout preview**

  , en mise en page ordinateur comme mobile.
</ChecklistItem>

## 5. Sécurité [#5-security]

<ChecklistItem id="OP-SE-1" code="SE-1" title="Clé sur le serveur">
  Votre 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.
</ChecklistItem>

<ChecklistItem id="OP-SE-2" code="SE-2" title="Totaux fixés par le serveur">
  Le montant, la devise et l’ID de commande proviennent de votre commande enregistrée, jamais du navigateur.
</ChecklistItem>

<ChecklistItem id="OP-SE-3" code="SE-3" title="Endpoints des paiements intégrés">
  Si 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.
</ChecklistItem>

<ChecklistItem id="OP-SE-4" code="SE-4" title="Content Security Policy">
  Si 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.
</ChecklistItem>

## 6. Configuration de la sandbox [#6-sandbox-configuration]

<ChecklistItem id="OP-PR-1" code="PR-1" title="API de la sandbox">
  `TAPAYA_CHECKOUT_API_URL`

   pointe vers 

  `https://api.sandbox.tapaya.com`

  .
</ChecklistItem>

<ChecklistItem id="OP-PR-2" code="PR-2" title="Clé de la sandbox">
  L’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.
</ChecklistItem>

<ChecklistItem id="OP-PR-3" code="PR-3" title="Tâche de rapprochement">
  La tâche qui récupère les sessions non résolues est planifiée dans votre environnement de test.
</ChecklistItem>

## 7. Préparation à la production [#7-production-readiness]

<ChecklistItem id="OP-LV-1" code="LV-1" title="Préparation du commerçant">
  Le 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.
</ChecklistItem>

<ChecklistItem id="OP-LV-2" code="LV-2" title="Identifiants de production">
  Le 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.
</ChecklistItem>

<ChecklistItem id="OP-LV-3" code="LV-3" title="Portefeuilles en production">
  Les 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.
</ChecklistItem>

<ChecklistItem id="OP-LV-4" code="LV-4" title="Rapprochement en production">
  Les 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.
</ChecklistItem>

<ChecklistProgress />

<Callout title="Validation finale" type="tip">
  Effectuez les tests en sandbox et les vérifications de préparation à la production. Utilisez **Reset** pour repartir d’une liste vierge, car les coches des séries de tests précédentes restent enregistrées dans ce navigateur.
</Callout>