Les intégrations de paiement n'utilisent pas toujours, au sens strict, une seule clé API. Certains prestataires utilisent des identifiants client, des secrets, des certificats ou OAuth. Le principe de sécurité reste le même : seules les applications et les personnes concernées bénéficient de l'accès strictement nécessaire.
Ne placez pas les clés de production dans le JavaScript du navigateur, les paquets d'applications mobiles, les dépôts publics ou les documents largement diffusés. Tout ce qui est fourni côté client peut en principe être lu.
Utilisez un gestionnaire de secrets côté serveur ou une configuration d'environnement sécurisée à accès restreint.
Un environnement de test et un environnement de production doivent utiliser des identifiants et des points de terminaison différents. Les données de test ne doivent pas figurer dans les rapports de production et une clé de test ne doit pas permettre d'effectuer un remboursement ou un paiement réel.
Rendez l'environnement visuellement reconnaissable afin de limiter les erreurs pendant le développement.
Vous hésitez entre un plugin et une API ? Découvrez alors comment choisir la bonne solution choisissez un plugin ou une API.
N'attribuez à une intégration que les périmètres dont elle a besoin. Une application qui consulte les statuts de paiement n'a peut-être pas besoin d'être autorisée à effectuer des remboursements ou des modifications de compte. Limitez, dans la mesure du possible, les adresses IP, les domaines ou les commerçants autorisés.
Utilisez des identifiants distincts pour chaque application ou fournisseur afin de pouvoir révoquer l'accès de manière ciblée.
Lors d'un couplage, il est important que vous Connectez-vous en toute sécurité à votre terminal de paiement ou à votre API de paiement est associé.
Mettez à jour les identifiants conformément à la politique du fournisseur et immédiatement en cas de suspicion de fuite, de changement de personnel ou de fin de contrat avec un fournisseur. Testez la rotation sans temps d'arrêt prolongé en faisant en sorte que les anciens et les nouveaux identifiants se chevauchent de manière contrôlée pendant une période temporaire, lorsque le fournisseur prend en charge cette fonctionnalité.
Enregistrez le nom du propriétaire, la date de création, les droits et la date d'expiration prévue sans inscrire la valeur elle-même dans le registre.
Les journaux peuvent contenir des références, des horodatages et des codes d'erreur, mais ne doivent pas contenir de code PIN, de données complètes relatives aux cartes ou de secrets. Masquez les jetons et les en-têtes sensibles. Limitez la durée de conservation et l'accès.
Surveillez les utilisations inhabituelles, les authentifications infructueuses répétées et les tentatives de remboursement inattendues.
La sécurité des API n'est pas une configuration ponctuelle. Elle nécessite un inventaire, des droits d'accès minimaux, un stockage sécurisé, une surveillance ainsi qu'un plan de rotation et de gestion des incidents.
En savoir plus sur la sécurité API de paiement et intégration à la caisse Vous trouverez plus d'informations à ce sujet dans notre guide sur les intégrations.
OmEs pay coordonne la configuration du prestataire avec votre développeur. Le développeur reste responsable de la sécurité du stockage et du code de l'application ; ensemble, nous testons le flux de paiement convenu.
