Clés de paiement et clés de caisse
Cardflo utilise des clés de paiement et des clés de caisse pour offrir des options d'intégration sécurisées et flexibles aux commerçants.
Les clés de paiement gèrent l'initiation des sessions de paiement et la collecte des données clients, tandis que les clés de caisse facilitent le traitement des transactions côté serveur. Cette séparation garantit la conformité PCI et une sécurité robuste pour tous les flux de paiement.
- Catégorie
- Développeur
- Capacités
- 10
- Disponible sur
- Tous les plans
L'aperçu
La séparation des identifiants en clés de paiement et clés de caisse représente une architecture de sécurité fondamentale dans l'orchestration des paiements modernes.
Les clés de paiement sont des identifiants publics utilisés dans les environnements côté client, tels que les navigateurs web ou les applications mobiles, pour initialiser les composants de paiement et collecter les données sensibles des titulaires de carte.
Ces clés permettent à un commerçant de rendre une interface de paiement sans exposer les permissions sensibles du backend. Inversement, les clés de caisse sont des identifiants restreints côté serveur conçus pour une communication authentifiée entre un serveur marchand et la passerelle de paiement.
En bifurquant ces rôles, le système garantit qu'une compromission du code côté client ne donne pas à un attaquant la possibilité d'effectuer des actions administratives, telles que l'initiation de remboursements ou la capture de paiements autorisés.
Cette approche architecturale aide à maintenir la conformité PCI DSS en minimisant la portée des systèmes qui interagissent directement avec les identifiants de paiement bruts tout en permettant un contrôle programmable et granulaire sur les cycles de vie des transactions.
Comment ça marche
Initiation de session côté client
L'intégration commence par l'utilisation de la clé de paiement dans l'application frontend pour demander une session sécurisée.
Cette clé identifie l'identité du commerçant (MID) et autorise le rendu des éléments de paiement sécurisés, garantissant que les détails de la carte du client sont tokenisés avant d'atteindre l'infrastructure du commerçant.
Tokenisation sécurisée des données
Lorsque le client saisit ses détails de paiement, la clé de paiement facilite une connexion directe au coffre-fort. Les champs sensibles comme le PAN et le CVV sont convertis en jetons temporaires.
Ce processus garantit que l'environnement du commerçant reste en dehors du champ d'application principal des exigences PCI DSS.
Autorisation de serveur à serveur
Une fois qu'un jeton est généré, le serveur du commerçant utilise sa clé de caisse pour demander une autorisation formelle à l'acquéreur.
Cette clé privée confirme que la demande est légitime et permet à la passerelle de mapper le jeton temporaire aux données de paiement stockées pour traitement.
Gestion du cycle de vie des transactions
Les actions post-autorisation, y compris la capture, le règlement et les remboursements, sont exclusivement gérées via la clé de caisse.
Parce que ces actions impliquent le mouvement de fonds, elles nécessitent le niveau d'authentification plus élevé et l'accès restreint que la clé de caisse côté serveur fournit à l'administrateur du commerçant.
Pourquoi c'est important
Atténuation des risques et de la responsabilité
La division des identifiants réduit le rayon d'action d'une éventuelle violation de sécurité. Si une clé de paiement est interceptée à partir du code source d'un site web, l'attaquant ne peut pas l'utiliser pour retirer des fonds ou accéder aux enregistrements de transactions historiques.
La clé de caisse reste protégée sur un backend sécurisé, garantissant que seuls les environnements de serveur autorisés peuvent exécuter des mouvements financiers, ce qui est une défense critique contre les attaques par injection courantes.
Conformité PCI DSS simplifiée
En utilisant des clés de paiement pour gérer les données des titulaires de carte via des champs ou des composants hébergés, les commerçants se qualifient généralement pour une charge de conformité réduite, telle que SAQ A ou SAQ A-EP.
La clé de caisse garantit que les données sensibles sont traitées dans un format tokenisé sur le backend, éliminant le besoin pour le commerçant de stocker, traiter ou transmettre des informations de carte de crédit brutes sur ses propres serveurs.
Cas d'usage
Applications web e-commerce
Les commerçants utilisent des clés de paiement pour intégrer des formulaires de paiement sécurisés directement dans leurs sites web, tandis que la clé de caisse est stockée dans leur environnement backend pour finaliser la capture des fonds une fois la commande confirmée.
Applications mobiles natives
Les développeurs mobiles utilisent des clés de paiement dans les applications iOS ou Android pour collecter en toute sécurité les signatures de paiement, en s'appuyant sur les clés de caisse côté serveur pour gérer la logique complexe du règlement multidevises et de la facturation récurrente.
Abonnement et facturation récurrente
Après que la clé de paiement initiale ait collecté les détails de la carte, la clé de caisse est utilisée pour établir un cadre de transaction initiée par le commerçant (MIT), permettant des renouvellements automatisés sans autre intervention du client.
En chiffres
Les normes de l'industrie suggèrent que le déchargement de la capture de données vers des composants hébergés via des clés côté client peut réduire le nombre d'exigences PCI applicables de plus de 90 pour cent.
Les architectures standardisées basées sur des clés permettent généralement aux développeurs de mettre en œuvre un flux de paiement sécurisé de base en environ deux jours ouvrables de développement.
Les passerelles de paiement professionnelles exigent que 100 pour cent des requêtes côté serveur soient authentifiées via une clé privée pour garantir l'intégrité du cycle de vie des transactions.
Termes associés
Talk to our team about a live rollout on your acquiring stack.
Ce que vous obtenez avec Clés de paiement et clés de caisse
- Isoler les activités côté client des fonctions administratives sensibles du backend pour une sécurité améliorée
- Minimiser l'exposition PCI DSS en garantissant que les données brutes de la carte contournent les serveurs du commerçant
- Autoriser les composants de paiement frontend à l'aide de justificatifs d'identité de clé de paiement restreints et accessibles au public
- Exécuter des captures et des remboursements sécurisés côté serveur avec des requêtes de clé de caisse authentifiées
- Maintenir un contrôle d'accès granulaire sur des points d'API spécifiques et des opérations de transaction
- Prendre en charge un large éventail de frameworks frontend sans risquer l'exposition des identifiants backend
- Réduire la probabilité de transferts de fonds frauduleux via un code côté client compromis
- Faciliter la tokenisation sécurisée des détails du titulaire de carte au point d'entrée initial
- Permettre les transactions initiées par le commerçant pour les modèles d'abonnement à l'aide d'une authentification backend sécurisée
- Fournir des pistes d'audit claires pour les sessions côté client et les actions de gestion côté serveur
A short scoping call, then a written plan for your MIDs.
Questions à propos de Clés de paiement et clés de caisse
Quelle est la principale différence entre une clé de paiement et une clé secrète d'API ?
Une clé de paiement est conçue pour être utilisée dans des environnements publics où le code est visible, comme un navigateur. Elle a des permissions extrêmement limitées, ne pouvant généralement que créer un jeton de paiement.
Une clé secrète d'API, ou clé de caisse, est utilisée pour les opérations côté serveur et a le pouvoir de déplacer de l'argent, d'effectuer des remboursements et d'accéder aux données sensibles du commerçant.
La séparation de ces clés garantit que même si une clé publique est copiée, les fonctions financières principales du compte du commerçant restent protégées derrière l'authentification côté serveur.
Une clé de paiement peut-elle être utilisée pour effectuer un remboursement ou annuler une transaction ?
Non, les clés de paiement sont spécifiquement restreintes pour empêcher toute opération impliquant le mouvement de fonds depuis le compte du commerçant.
Les remboursements, les annulations et les captures nécessitent l'utilisation d'une clé de caisse, qui doit être gardée secrète et utilisée uniquement dans un environnement serveur sécurisé.
Cette protection est intentionnelle et empêche les acteurs malveillants de manipuler le code côté client pour déclencher des annulations financières non autorisées ou des exportations de données depuis la passerelle de paiement.
Pourquoi ce système à deux clés est-il nécessaire pour la conformité PCI DSS ?
La conformité PCI DSS se concentre sur la manière dont les données des titulaires de carte sont traitées.
En utilisant une clé de paiement pour faciliter la tokenisation des données de carte directement depuis le navigateur du client vers le processeur de paiement, le commerçant ne touche jamais les données brutes.
La clé de caisse permet ensuite au commerçant de travailler avec ce jeton. Cette séparation permet à un commerçant d'utiliser des questionnaires de conformité simplifiés, car ses systèmes ne sont jamais en possession d'informations sensibles comme les PAN en texte clair.
Comment les clés de caisse doivent-elles être stockées dans l'infrastructure d'un commerçant ?
Les clés de caisse doivent être traitées comme des identifiants hautement sensibles. Elles ne doivent jamais être codées en dur dans les fichiers sources ou stockées dans des systèmes de contrôle de version comme Git.
Au lieu de cela, elles doivent être gérées à l'aide de variables d'environnement ou d'un service de gestion de secrets dédié.
L'accès à ces clés doit être restreint aux instances de serveur spécifiques qui en ont besoin pour communiquer avec le processeur de paiement pour la finalisation et le reporting des transactions.
Que se passe-t-il si une clé de paiement est divulguée ou compromise ?
Si une clé de paiement est compromise, l'impact est généralement faible par rapport à une fuite de clé secrète.
Un attaquant pourrait potentiellement utiliser la clé pour soumettre des données indésirables ou tenter de créer des jetons via le MID du commerçant, mais il ne peut pas accéder aux données clients existantes ou aux fonds.
Cependant, il est toujours de pratique courante de faire pivoter la clé de paiement divulguée pour empêcher toute utilisation non autorisée des actifs frontend du commerçant et pour maintenir des journaux de transactions propres.
Les clés de caisse prennent-elles en charge différents niveaux d'autorisation en fonction de l'utilisateur ?
Bien que la clé de caisse elle-même représente un identifiant de serveur de haut niveau, les passerelles standard de l'industrie permettent souvent la création de plusieurs clés avec des portées variées.
Par exemple, une clé de caisse pourrait être restreinte à un accès en lecture seule pour le reporting, tandis qu'une autre pourrait avoir l'autorité de traiter les captures et les remboursements.
Cela suit le principe du moindre privilège, garantissant que chaque partie du système backend d'un commerçant n'a que les autorisations dont elle a besoin pour fonctionner.
Prêt à accélérer ?
Parlez-nous de votre activité. Nous vous mettrons en relation avec les bons partenaires acquéreurs et la bonne route, généralement en moins d'une semaine.