Tapaya
Paiements en ligneSécurité du CheckoutSécurité du Checkout

Sécurité du Checkout

Les règles côté serveur qui assurent la sécurité d’une intégration du Checkout, de la gestion des clés à la vérification d’un paiement avant le traitement de la commande.

Tapaya héberge les champs de carte, la tokenisation, l’authentification de la carte et le débit, de sorte que vos systèmes ne manipulent jamais de données de carte brutes. Ce qui reste de votre ressort, c’est le serveur qui crée les paiements et décide quand une commande est payée. Ces règles s’appliquent à la fois au Hosted Checkout et à l’Embedded Checkout.

Pour savoir comment Tapaya traite les données du titulaire de la carte et les données personnelles, consultez Protection des données et confidentialité.

Conservez les clés sur le serveur

  • Stockez votre clé checkout de commerçant ou la Secret key de votre organisation uniquement dans la configuration côté serveur. Aucune des deux n’a sa place dans le code du navigateur, dans les bundles d’applications mobiles ni dans le gestionnaire de versions. Seuls la publishable key et le client secret d’un paiement parviennent au navigateur.
  • Appelez l’API Checkout du commerçant depuis votre environnement serveur. N’exécutez pas ces requêtes dans le navigateur du client.
  • Une clé checkout de commerçant ne donne accès qu’à son commerçant. Remettez cette clé au backend du commerçant lui-même, jamais la Secret key de votre organisation.
  • La Secret key de l’organisation dispose de privilèges sur toute l’organisation. En mode plateforme, envoyez-la avec X-Tapaya-Merchant-Token dans chaque requête ; l’API vérifie que le commerçant appartient à l’organisation de la clé. Voir Authentification du Checkout.
  • Les clés de commerçant ne s’affichent qu’une seule fois et ne sont stockées que sous forme de hash. Révoquez une clé que vous soupçonnez d’être exposée, après avoir créé sa remplaçante.

Gérez la commande sur votre serveur

  • Calculez le total de la commande sur votre serveur et enregistrez la commande avant de créer une session ou une tentative de paiement.
  • Lisez les montants, la devise et les ID de commande depuis l’instantané de votre commande enregistrée. N’acceptez pas de valeurs de remplacement envoyées par le navigateur.
  • Pour les paiements intégrés, liez vos endpoints prepare et submit à un checkout authentifié ou à un cookie HTTP-only signé, et validez l’origine des requêtes de modification.

Vérifiez avant de traiter la commande

Une redirection du navigateur, une visite de votre URL de succès, des paramètres de requête, des cookies de retour et des messages du navigateur sont des données de navigation. Aucun d’eux ne prouve le paiement.

  • Récupérez la session depuis votre serveur et comparez sa référence de commande, son montant, sa devise et son statut de paiement avec la commande enregistrée.
  • Ne traitez la commande que lorsque cette vérification confirme paymentStatus: successful. Une réponse HTTP 200 seule ne prouve pas le paiement.
  • Enregistrez le traitement de la commande de manière atomique, afin que des retours répétés ou des vérifications de statut ne puissent pas traiter deux fois la même commande.
  • Si la session est toujours unpaid ou si la récupération échoue, conservez l’ID de session et vérifiez à nouveau avec un nombre limité de nouvelles tentatives. Ne créez pas une autre session parce que le premier résultat est inconnu : une nouvelle session pour la commande remplace l’ancienne. Il n’existe pas encore de webhooks, effectuez donc le rapprochement par interrogation périodique (polling).

Relancez les requêtes en toute sécurité

  • Enregistrez une idempotency key unique avec la commande avant de créer une session. Si une requête expire ou si sa réponse est perdue, relancez-la avec la même clé et un corps inchangé.
  • Ne générez pas de nouvelle clé pour un résultat incertain. Consultez Idempotence et erreurs pour les règles de rejeu.

Restreignez les origines de redirection

  • Ajoutez uniquement les origines de vos propres boutiques à Allowed websites dans les paramètres du Checkout.
  • Utilisez HTTPS pour les boutiques déployées. Les remplacements de successUrl et cancelUrl par session doivent tout de même correspondre à une origine configurée.

Signaler un problème de sécurité

Si vous soupçonnez une vulnérabilité ou un incident de sécurité, contactez l’équipe sécurité comme indiqué dans Contacts.

Il manque quelque chose sur cette page ?Demandez une fonctionnalité. Nous joignons cette page pour que l’équipe ait le contexte.