Pay.Parts

Compliance requirements to use Pay.Parts

Compliance involves implementing appropriate technical and organizational measures, such as securing your network, encrypting transmitted data, restricting access to sensitive information, regularly monitoring and testing your systems, and maintaining an information security policy. Depending on how your integration is set up (e.g., direct card handling vs. using hosted payment pages), the level of compliance and validation required may vary.

Do i need a SAQ if i use the Card Netwerk Payments services of PAY?

Yes, in most cases you still need to complete an SAQ, but the type and scope are usually much lighter.

Using a component (like hosted fields, iFrames, or a payment widget) from your payment provider significantly reduces your PCI DSS responsibilities because you’re not directly handling raw card data. However, you are still involved in the payment flow, so compliance doesn’t disappear entirely.

What this typically means:
If the component is fully hosted by the provider (e.g. iFrame or redirect), you’ll likely qualify for a simpler SAQ such as SAQ A. If the component is embedded (e.g. JavaScript fields on your site), you may need SAQ A-EP, which has stricter requirements because your website could still impact payment security.

You are still responsible for things like: securing your website (e.g. preventing script injection), maintaining HTTPS, managing access controls, and ensuring your integration is implemented correctly.

So while using a provider’s component reduces your PCI scope, it does not eliminate the need for an SAQ in most scenarios.

If you store card data and process it via the API, you need an even stricter SAQ D. 

What SAQ do i need for the Pay.Parts?

With hosted fields embedded on your site, you typically fall under SAQ A-EP, not SAQ A.

Even though the card data fields are hosted by the PSP (so sensitive data is sent directly to them), the page that loads those fields is still served by your website. That means your site could potentially be compromised (e.g. via malicious JavaScript) and interfere with the payment flow.

Because of that, PCI considers your environment to still have an impact on card data security.

What this means in practice:
✅ You don’t directly handle raw card data → reduced PCI scope
⚠️ But you must complete SAQ A-EP → stricter than SAQ A

SAQ A-EP includes requirements like:
Securing your web server and application, regular vulnerability scanning (ASV scans), strong access control and authentication, change management and logging, and protection against script injection (very important for hosted fields).

When would it be SAQ A instead?
Only if: The entire payment page is hosted by the PSP (redirect or full iFrame), and your site does not influence the payment page at all, so you can comply with SAQ A.

Can I comply with SAQ A on Pay.Parts?
Short answer: no, client-side encryption (CSE) does not usually change your SAQ type.

Even if you encrypt the card data in the browser before it’s sent to your PSP: The customer’s browser and your website are still part of the card data capture process. Your page can still be tampered with (e.g. malicious JavaScript injection) before encryption happens. PCI DSS therefore still considers your environment as having an impact on card data security.

In your case (hosted fields + CSE): Hosted fields already point to SAQ A-EP. Adding client-side encryption does not reduce that to SAQ A.

Why PCI doesn’t “downgrade” scope here?
PCI DSS focuses on where card data could be exposed, not just whether it’s encrypted: If an attacker can modify your page, they could capture card data before encryption. So your website still needs to meet the stricter controls of A-EP.

When CSE does help?
It adds an extra security layer. It can reduce risk and may help with internal security reviews. But it doesn’t change your formal PCI validation scope.

Bottom line: Client-side encryption improves security, but it does not change your SAQ type—you’ll still be in SAQ A-EP with hosted fields.

What SAQ do i need when i use the card:payment API integration?

When you process card data via your server:

• Your server receives, processes, or transmits cardholder data.

• You are directly handling sensitive authentication data and/or PANs.

• Your environment is fully in scope for PCI DSS.

This is fundamentally different from hosted fields or redirects, where the PSP handles the sensitive data.

What SAQ D means in practice:
SAQ D is the most comprehensive and demanding self-assessment. It includes nearly all PCI DSS requirements, such as:

Secure network architecture (firewalls, segmentation), strong encryption for data in transit and at rest, strict access control and authentication, logging, monitoring, and intrusion detection, regular vulnerability scans and penetration testing, secure software development practices, and detailed security policies and procedures.

What SAQ do i need when use the Buttons of ApplePAY and GoogleWallet?

If you’re using Apple Pay and Google Pay (Google Wallet) via prebuilt buttons (i.e., through a payment service provider or gateway where you don’t handle card data yourself), the SAQ you need is almost always: SAQ A

Because you: 

• Do not handle or store cardholder data at all
• Use fully outsourced payment processing
• Embed hosted payment fields or buttons (like Apple Pay / Google Pay buttons from Stripe, Adyen, Pay.nl, etc.)
• The payment data goes directly from the customer’s device to the PSP

Apple Pay and Google Pay:

• Tokenize the card data on the device
• Send it directly to the payment processor
• You (the merchant) never see the raw card number