Le Buy Now Pay Later (BNPL) a transformé le paysage des paiements en ligne. Mais derrière la simplicité apparente pour le consommateur se cache une architecture complexe qui soulève des questions critiques de conformité PCI DSS : qui stocke réellement les données de carte ? Qui est dans le scope PCI ? Et comment la chaîne de responsabilité est-elle organisée entre le marchand, le fournisseur BNPL et l'acquéreur ?
Comment fonctionne le BNPL d'un point de vue des données de carte
Dans un flux BNPL typique, le consommateur fournit ses données de carte directement au fournisseur BNPL (Klarna, Scalapay, Alma, etc.) lors de la première utilisation. Le fournisseur BNPL tokenise ces données, émet un crédit à court terme au consommateur, et règle le marchand. Les remboursements ultérieurs du consommateur utilisent les données de carte stockées chez le fournisseur BNPL.
Pour le marchand, cela signifie en théorie qu'il ne reçoit jamais les données de carte du client — c'est le fournisseur BNPL qui les gère. Le marchand est donc potentiellement hors scope PCI DSS pour ce flux spécifique, à condition que l'intégration soit correctement réalisée via un widget ou une API qui ne transmette jamais les données de carte vers les serveurs du marchand.
Quand le marchand entre-t-il dans le scope PCI DSS avec le BNPL ?
Malgré l'apparente simplification, plusieurs scénarios peuvent faire entrer le marchand dans le scope PCI DSS même avec un fournisseur BNPL :
- Intégration API côté serveur : si le formulaire de paiement est hébergé sur les serveurs du marchand et envoie les données de carte via son backend avant de les transmettre au BNPL
- Stockage intermédiaire : si les données de carte transitent par les systèmes du marchand, même temporairement
- Fallback carte bancaire : si le marchand maintient également une option de paiement par carte directe, les deux flux doivent être évalués séparément
- Webhooks avec données sensibles : si les notifications du BNPL contiennent des données de carte (ce qui ne devrait pas arriver mais peut survenir avec des intégrations mal configurées)
La chaîne de responsabilité PCI dans le BNPL
La responsabilité PCI DSS dans le BNPL suit une logique de flux de données. Le fournisseur BNPL, en tant que service provider qui stocke et traite des données de carte pour le compte de marchands, doit être certifié PCI DSS Level 1 (ou équivalent) et figurer sur la liste des prestataires de services conformes de Visa/Mastercard.
Le marchand qui utilise un fournisseur BNPL doit s'assurer que ce fournisseur est bien listé comme prestataire de services PCI DSS conforme. Cette vérification est obligatoire selon PCI DSS Requirement 12.8 : vous êtes responsable de vous assurer que vos prestataires tiers maintiennent leur conformité PCI DSS.
BNPL hybride : quand la carte de crédit coexiste avec le BNPL
De nombreux marchands utilisent le BNPL en complément d'une acceptation de carte traditionnelle. Dans ce cas, l'évaluation PCI DSS doit couvrir les deux flux. Même si le flux BNPL est hors scope, le flux carte peut maintenir le marchand dans le scope PCI DSS — potentiellement à un niveau plus élevé si le volume de transactions est important.
La solution optimale dans ce cas est d'utiliser une tokenisation centralisée pour les deux flux : les données de carte du flux de paiement direct sont tokenisées via PCI Proxy EU, et le fournisseur BNPL gère sa propre tokenisation. Les deux types de tokens peuvent coexister dans votre base de données sans que vous ne stockiez de PAN.
Comment la tokenisation simplifie la conformité BNPL
PCI Proxy EU peut agir comme couche intermédiaire dans un flux BNPL : les données de carte sont collectées via le formulaire sécurisé PCI Proxy EU (ou l'API PCI Proxy), tokenisées immédiatement, et le token est transmis au fournisseur BNPL pour initier le crédit. Le marchand ne voit jamais le PAN, et le fournisseur BNPL reçoit les données de carte directement depuis le vault PCI Proxy EU de manière sécurisée.
Cette approche présente l'avantage supplémentaire de permettre au marchand de changer de fournisseur BNPL sans que les données de carte des clients soient captives chez un fournisseur spécifique. Le token PCI Proxy EU est indépendant du fournisseur BNPL.
Points de vigilance pour les marchands BNPL en Europe
En Europe, les marchands utilisant le BNPL doivent également être attentifs aux évolutions réglementaires. La directive sur le crédit à la consommation (CCD) révisée, entrée en application progressive en 2024-2025, soumet désormais certains produits BNPL à des obligations de crédit, avec des exigences additionnelles en matière de vérification de solvabilité et d'information du consommateur.
Sur le plan RGPD, les données de carte utilisées dans un flux BNPL constituent des données personnelles soumises aux mêmes obligations que dans un paiement classique. Le marchand doit s'assurer que son DPA (Data Processing Agreement) avec le fournisseur BNPL couvre le traitement de ces données conformément au RGPD.
Simplifiez la conformité PCI DSS dans votre stack BNPL avec la tokenisation PCI Proxy EU. Découvrir PCI Proxy EU.