Buy now pay later PCI is one of the areas where the PCI DSS chain of responsibility is most complex to map. BNPL models like Klarna, Scalapay, Afterpay and their European competitors involve multiple actors in a single transaction: the merchant, the BNPL provider, the card network and in some cases a separate acquirer. Understanding who handles card data and who is responsible for PCI DSS compliance in this ecosystem is essential for every merchant offering deferred payments.
BNPL and PCI DSS: the chain of responsibility
In the most common BNPL models, the provider (Klarna, Scalapay, etc.) acts as the financier: it pays the merchant in full at the time of purchase and then manages the credit relationship with the consumer for subsequent instalments. The consumer may pay the instalments with a credit or debit card, in which case card data passes through the BNPL provider's platform. The merchant receives only the order balance, without seeing the consumer's card data for the instalments.
This means that for the pure BNPL component, the merchant is outside the card data flow: the PCI DSS perimeter for that transaction belongs to the BNPL provider, not the merchant. However, if the merchant also accepts traditional card payments in parallel (which is almost always the case), their PCI perimeter remains active for these flows. The common mistake is assuming that integrating a BNPL provider completely eliminates PCI obligations: it only reduces them for transactions processed through that specific channel.
The BNPL merchant: what card data it actually touches
There are BNPL model variants where the merchant is more involved in card data. In "merchant-financed BNPL" or white-label solutions, the merchant may directly manage the instalment plan without an external BNPL provider. In these cases, the merchant must store or have access to card data for subsequent instalments, and the PCI perimeter expands significantly. Card-on-file tokenization becomes necessary to manage these instalments without exposing card data in the merchant's systems.
Even in BNPL models with an external provider, there are scenarios where the merchant indirectly touches card data: custom integrations that transmit data to the BNPL provider through the merchant's servers, e-commerce platforms that collect data before forwarding it to the BNPL provider, or analytics systems that log payment information. Any of these scenarios can expand the merchant's PCI perimeter even if the business model is BNPL.
How tokenization simplifies BNPL
For merchants offering internal or white-label BNPL, tokenization is the natural solution for managing subsequent instalments in a compliant manner. The card data is collected once, tokenised, and the token is used to charge each instalment. The merchant never stores a plain PAN, the PCI perimeter is reduced to the token alone, and instalments are processed through the vault which detokenises and transmits to the PSP. The model is identical to standard recurring billing, with the addition of instalment logic in the merchant's system.
For merchants using external BNPL providers like Klarna or Scalapay, tokenization remains useful for the parallel traditional card channel. Having a single vault managing both the card channel tokens and any internal BNPL integrations simplifies the overall architecture and reduces the number of PCI perimeters to manage. Merchant PCI compliance is much more easily managed with a single point of card data aggregation.
Frequently asked questions
If I use Klarna or Scalapay do I still have PCI DSS obligations?
It depends on how the integration is built and what other payment methods you accept. If the BNPL integration is a pure "redirect" (the consumer is redirected to the provider's platform to enter card data) and you do not accept traditional cards, your PCI perimeter is minimal. If you also accept traditional cards or if the integration involves data passing through your servers, the PCI perimeter remains active.
Does the BNPL provider fully cover my PCI responsibility?
The BNPL provider covers its own part of the infrastructure, not yours. If your technical integration routes card data through your systems before sending it to the provider, you are in PCI scope for that part. Read the integration's technical documentation carefully and verify how card data is handled in the actual flow.
How does a chargeback work in a tokenised BNPL payment?
In a tokenised BNPL model, chargebacks are handled at the level of each individual instalment charge. The token used for each instalment is detokenised by the vault, the transaction is disputed with the PSP using the original PAN, and the chargeback process follows the normal rules of the card network. The vault maintains a complete log of every detokenisation to support evidence in the event of a dispute.
Offering internal or white-label BNPL and want to manage instalments in a PCI DSS compliant way without storing card data? Discover PCI Proxy EU.