Il buy now pay later pci è uno degli ambiti dove la catena di responsabilità PCI DSS è più complessa da mappare. I modelli BNPL come Klarna, Scalapay, Afterpay e i loro concorrenti europei coinvolgono più attori nella singola transazione: il merchant, il provider BNPL, il network della carta e in alcuni casi anche un acquirer separato. Capire chi gestisce i dati carta e chi risponde della compliance PCI DSS in questo ecosistema è fondamentale per ogni merchant che offre pagamenti dilazionati.
BNPL e PCI DSS: la catena di responsabilità
Nei modelli BNPL più diffusi, il provider (Klarna, Scalapay, ecc.) agisce come finanziatore: paga il merchant per intero al momento dell'acquisto e poi gestisce il rapporto di credito con il consumatore per le rate successive. Il consumatore può pagare le rate con carta di credito o debito, e in questo caso i dati carta transitano nella piattaforma del provider BNPL. Il merchant riceve solo il saldo dell'ordine, senza vedere i dati carta del consumatore per le rate.
Questo significa che per la componente BNPL pura, il merchant è fuori dal flusso dei dati carta: il perimetro PCI DSS per quella transazione appartiene al provider BNPL, non al merchant. Tuttavia, se il merchant accetta anche pagamenti carta tradizionali in parallelo (il che è quasi sempre il caso), il suo perimetro PCI rimane attivo per questi flussi. L'errore comune è assumere che integrare un BNPL elimini completamente gli obblighi PCI: li riduce solo per le transazioni elaborate tramite quel canale specifico.
Il merchant BNPL: quali dati carta tocca davvero
Esistono varianti del modello BNPL dove il merchant è più coinvolto nei dati carta. Nei modelli "merchant-financed BNPL" o nelle soluzioni white-label, il merchant può gestire direttamente la rateizzazione senza un provider BNPL esterno. In questi casi, il merchant deve archiviare o avere accesso ai dati carta per le rate successive, e il perimetro PCI si espande significativamente. La card-on-file tokenization diventa necessaria per gestire queste rate senza esporre i dati carta nei sistemi del merchant.
Anche nei modelli BNPL con provider esterno, esistono scenari dove il merchant tocca dati carta in modo indiretto: integrazioni custom che trasmettono dati al provider BNPL attraverso i server del merchant, piattaforme e-commerce che raccolgono i dati prima di inoltrarli al BNPL, o sistemi di analytics che loggano informazioni di pagamento. Qualsiasi di questi scenari può ampliare il perimetro PCI del merchant anche se il modello di business è BNPL.
Come la tokenizzazione semplifica il BNPL
Per i merchant che offrono BNPL interno o white-label, la tokenizzazione è la soluzione naturale per gestire le rate successive in modo conforme. Il dato carta viene raccolto una volta, tokenizzato, e il token viene usato per addebitare ogni rata. Il merchant non archivia mai un PAN in chiaro, il perimetro PCI si riduce al solo token, e le rate vengono elaborate tramite il vault che de-tokenizza e trasmette al PSP. Il modello è identico al recurring billing standard, con l'aggiunta della logica di rateizzazione nel sistema del merchant.
Per i merchant che usano provider BNPL esterni come Klarna o Scalapay, la tokenizzazione rimane utile per il canale carta tradizionale parallelo. Avere un unico vault che gestisce sia i token del canale carta sia le eventuali integrazioni BNPL interne semplifica l'architettura complessiva e riduce il numero di perimetri PCI da gestire. La merchant pci compliance si gestisce molto più facilmente con un unico punto di aggregazione dei dati carta.
Domande frequenti
Se uso Klarna o Scalapay ho ancora obblighi PCI DSS?
Dipende da come è costruita l'integrazione e da quali altri metodi di pagamento accetti. Se l'integrazione BNPL è "redirect" puro (il consumatore viene reindirizzato sulla piattaforma del provider per inserire i dati carta) e non accetti carte tradizionali, il tuo perimetro PCI è minimo. Se accetti anche carte tradizionali o se l'integrazione prevede che i dati transitino nei tuoi server, il perimetro PCI rimane attivo.
Il provider BNPL copre completamente la mia responsabilità PCI?
Il provider BNPL copre la propria parte dell'infrastruttura, non la tua. Se la tua integrazione tecnica fa transitare dati carta attraverso i tuoi sistemi prima di inviarli al provider, sei in scope PCI per quella parte. Leggi attentamente la documentazione tecnica dell'integrazione e verifica come vengono gestiti i dati carta nel flusso concreto.
Come funziona il reclamo carta in un pagamento BNPL tokenizzato?
In un modello BNPL tokenizzato, il chargeback viene gestito a livello del singolo addebito rateale. Il token usato per ogni rata viene de-tokenizzato dal vault, la transazione viene contestata presso il PSP con il PAN originale, e il processo di chargeback segue le regole normali del network della carta. Il vault mantiene il log completo di ogni de-tokenizzazione per supportare l'evidenza in caso di disputa.
Offri BNPL interno o white-label e vuoi gestire le rate in modo conforme PCI DSS senza archiviare dati carta? Scopri PCI Proxy EU.