Pour un développeur, intégrer une solution de paiement conforme PCI DSS peut sembler une tâche intimidante. Pourtant, avec une API de tokenisation bien conçue, il est possible de construire un système de paiement complet sans que le serveur applicatif ne touche jamais un PAN en clair. Voici ce que signifie concrètement une API conforme PCI et comment en tirer parti.
Qu'est-ce qu'une API conforme PCI DSS ?
Une API conforme PCI DSS est une interface de programmation dont l'infrastructure sous-jacente est certifiée conforme aux 12 exigences du standard PCI DSS. Cela implique que les serveurs hébergeant l'API sont dans un CDE (Cardholder Data Environment) sécurisé, que les données en transit sont chiffrées via TLS 1.2 minimum, que les accès sont journalisés et contrôlés, et que les serveurs font l'objet de scans de vulnérabilité réguliers.
Ce qui distingue une API de tokenisation PCI d'une API de paiement classique, c'est le flux de données : avec une API de tokenisation, le PAN ne transite jamais par les serveurs du marchand. Le numéro de carte est soumis directement au vault de l'opérateur de tokenisation via une interface côté client (JavaScript sécurisé ou SDK mobile), et seul le token résultant est transmis au backend du marchand. Le serveur du marchand ne voit jamais le PAN.
Le flux technique d'intégration avec PCI Proxy EU
L'intégration avec PCI Proxy EU suit un flux en trois étapes. Premièrement, votre interface utilisateur (page web ou application mobile) utilise le SDK JavaScript ou mobile de PCI Proxy EU pour collecter les données de carte. Le SDK chiffre les données directement dans le navigateur ou l'application et les envoie au vault PCI Proxy EU, sans que votre serveur ne soit impliqué dans ce flux.
Deuxièmement, le vault retourne un token de session temporaire à votre frontend. Ce token est ensuite transmis à votre backend via votre propre API. Troisièmement, votre backend utilise ce token de session, combiné à votre clé API secrète, pour appeler l'API PCI Proxy EU et effectuer l'opération souhaitée : conversion en token permanent, initiation d'un paiement auprès d'un PSP, stockage card-on-file, etc.
À aucun moment de ce flux votre serveur applicatif ne traite un PAN en clair. Votre infrastructure sort complètement du CDE, ce qui réduit votre périmètre PCI au minimum et simplifie drastiquement votre questionnaire d'auto-évaluation SAQ.
Authentification et sécurité des appels API
L'API PCI Proxy EU utilise une authentification par clé API (API key) transmise dans les en-têtes HTTP, combinée à une signature HMAC pour certaines opérations critiques. Cette approche garantit à la fois l'authentification du client (votre serveur) et l'intégrité de la requête. Les clés API sont spécifiques à chaque environnement (sandbox et production) et doivent être stockées de manière sécurisée, jamais dans le code source ou des dépôts publics.
Tous les appels API doivent être effectués via HTTPS avec TLS 1.2 minimum. PCI Proxy EU rejette automatiquement les connexions utilisant des protocoles obsolètes (SSLv3, TLS 1.0, TLS 1.1) conformément aux exigences PCI DSS 4.0. Les certificats TLS sont gérés et renouvelés automatiquement côté PCI Proxy EU, éliminant un risque opérationnel courant.
Gestion des tokens : cycle de vie et opérations
Un token PCI Proxy EU est une chaîne alphanumérique de 16 à 19 caractères qui ressemble structurellement à un numéro de carte bancaire (même longueur, passe la validation Luhn) mais ne contient aucune information de paiement réelle. Cette structure format-préservante permet une intégration transparente dans les systèmes existants qui attendent un format de numéro de carte standard.
Les opérations disponibles sur un token incluent : la récupération des 4 derniers chiffres et du réseau (Visa/Mastercard) pour l'affichage utilisateur, l'initiation d'un paiement auprès d'un PSP partenaire, la mise à jour des informations d'expiration, et la suppression du token. Chaque opération est tracée dans les logs de PCI Proxy EU, fournissant un audit trail complet conforme aux exigences PCI DSS 10.x.
Impact sur le périmètre PCI et le SAQ applicable
L'avantage principal d'une intégration via API de tokenisation est la réduction du périmètre PCI. Si votre implémentation suit correctement le flux décrit ci-dessus (collecte côté client via SDK, token uniquement côté serveur), vous pouvez généralement qualifier pour le SAQ A ou SAQ A-EP, selon que vous avez un script JavaScript tiers sur votre page de paiement ou un redirect complet.
Le SAQ A comporte environ 22 questions et peut être complété par votre équipe technique en quelques heures. Comparé au SAQ D (329 questions, qui s'applique si vous traitez des PANs dans vos systèmes), la différence est considérable. Pour une startup ou une PME, cette réduction du périmètre représente une économie de dizaines de milliers d'euros en coûts d'audit et de mise en conformité.
Bonnes pratiques de développement pour rester hors scope PCI
Quelques règles simples permettent de maintenir votre application hors du périmètre PCI DSS. Ne créez jamais de champ de formulaire HTML pour les données de carte en dehors du SDK PCI Proxy EU : les bots et les outils de scan PCI détectent ces champs et font entrer votre domaine dans le scope. N'interceptez jamais les données de carte en JavaScript personnalisé avant leur transmission au SDK. Ne loggez jamais les données reçues de l'API, même partiellement.
Côté infrastructure, ne stockez jamais les tokens dans des logs d'accès HTTP, car bien qu'ils ne soient pas des PANs, leur présence dans les logs augmente inutilement la surface d'audit. Implémentez une rotation régulière des clés API et utilisez des secrets managers (AWS Secrets Manager, HashiCorp Vault, Azure Key Vault) pour stocker vos clés d'API en production. Ces bonnes pratiques, simples à mettre en œuvre, garantissent que votre intégration reste conforme PCI DSS à long terme.
Intégrez la tokenisation PCI DSS en quelques jours grâce à notre API REST documentée et notre sandbox de test. Découvrir PCI Proxy EU.