Pay.Parts

Hoe kan ik Pay.Parts technisch integreren?

De technische implementatie van Pay.Parts wordt behandeld op developer.pay.nl. Dit artikel richt zich uitsluitend op PCI DSS-compliance in combinatie met Pay.Parts.

Wat zijn de Compliance vereisten om Pay.Parts te gebruiken?

Compliance houdt in dat passende technische en organisatorische maatregelen worden geïmplementeerd, zoals:

• Het beveiligen van je netwerk.

• Het versleutelen van verzonden gegevens.

• Het beperken van toegang tot gevoelige informatie.

• Het regelmatig monitoren en testen van je systemen.

• Het onderhouden van een informatiebeveiligingsbeleid.

Afhankelijk van hoe je integratie is opgezet (bijv. directe kaartverwerking vs. gebruik van gehoste betaalpagina’s), kan het vereiste niveau van compliance en validatie variëren.

Heb ik een SAQ nodig als ik de Card Netwerk Payments diensten van Pay. gebruik?

Ja, in de meeste gevallen moet je nog steeds een PCI SAQ questionnaire invullen, maar het type en de scope zijn meestal veel beperkter.

Het gebruik van een component (zoals hosted fields, iFrames of een payment widget) van je payment provider vermindert je PCI DSS-verantwoordelijkheden aanzienlijk, omdat je niet direct ruwe kaartgegevens verwerkt. Je bent echter nog steeds onderdeel van de betaalflow, dus compliance verdwijnt niet volledig.

Wat dit doorgaans betekent:

Als de component volledig wordt gehost door de provider (bijv. iFrame of redirect), kom je waarschijnlijk in aanmerking voor een eenvoudigere SAQ verplichting zoals SAQ A. Als de component embedded is  (bijv. JavaScript-velden op je site), heb je mogelijk SAQ A-EP nodig, die strengere eisen stelt omdat je website nog steeds invloed kan hebben op de betaalbeveiliging.

Je blijft verantwoordelijk voor zaken zoals: Het beveiligen van je website (bijv. het voorkomen van scriptinjectie), het onderhouden van HTTPS, het beheren van toegangscontrole en ervoor zorgen dat je integratie correct is geïmplementeerd.

Dus hoewel het gebruik van een component van een provider je PCI-scope verkleint, elimineert het in de meeste scenario’s niet de noodzaak van een SAQ.

Als je kaartgegevens opslaat en via de API verwerkt, heb je een nog strengere SAQ D nodig.

Welke SAQ heb ik nodig voor Pay.Parts?

Met hosted fields die in je site embedded zijn, val je meestal onder SAQ A-EP, niet onder SAQ A.

Hoewel de kaartgegevensvelden worden gehost door de PSP (waardoor gevoelige gegevens direct naar hen worden gestuurd), wordt de pagina die deze velden laadt nog steeds door jouw website gehost. Dat betekent dat je site mogelijk gecompromitteerd kan worden (bijv. via kwaadaardige JavaScript) en de betaalflow kan beïnvloeden.

Daarom beschouwt de PCI jouw omgeving nog steeds als van invloed op de beveiliging van kaartgegevens.

Wat dit in de praktijk betekent:

✅ Je verwerkt geen ruwe kaartgegevens direct → verminderde PCI-scope
⚠️ Maar je moet SAQ A-EP invullen → strenger dan SAQ A

SAQ A-EP bevat vereisten zoals:

• Het beveiligen van je webserver en applicatie

• Regelmatige kwetsbaarheidsscans (ASV-scans)

• Sterke toegangscontrole en authenticatie

• Change management en logging

• bescherming tegen scriptinjectie (zeer belangrijk bij hosted fields).
  
  

Wanneer zou het SAQ A zijn?

Alleen als de volledige betaalpagina wordt gehost door de PSP (redirect of volledige iFrame), en je site geen enkele invloed heeft op de betaalpagina, zodat je kunt voldoen aan SAQ A.

Kan ik voldoen aan SAQ A met Pay.Parts?

Kort antwoord:
Nee, client-side encryptie (CSE) verandert meestal je SAQ-type niet.

Zelfs als je de kaartgegevens in de browser versleutelt voordat ze naar je PSP worden verzonden: De browser van de klant en jouw website maken nog steeds deel uit van het proces van het vastleggen van kaartgegevens. Je pagina kan nog steeds worden gemanipuleerd (bijv. via kwaadaardige JavaScript-injectie) voordat de encryptie plaatsvindt. PCI DSS beschouwt jouw omgeving daarom nog steeds als van invloed op de beveiliging van kaartgegevens.

In jouw geval (hosted fields + CSE): Hosted fields wijzen al op SAQ A-EP. Het toevoegen van client-side encryptie verlaagt dit niet naar SAQ A.

Waarom verlaagt PCI de scope hier niet?

PCI DSS richt zich op waar kaartgegevens blootgesteld kunnen worden, niet alleen op of ze versleuteld zijn: Als een aanvaller je pagina kan aanpassen, kunnen ze kaartgegevens onderscheppen vóór encryptie. Daarom moet je website nog steeds voldoen aan de strengere controles van A-EP.

Wanneer helpt CSE wel?

• Het voegt een extra beveiligingslaag toe.

• Het kan risico’s verminderen en helpen bij interne security reviews.

• Maar het verandert je formele PCI-validatiescope niet.

Kort samengevat:
Client-side encryptie verbetert de beveiliging, maar verandert je SAQ-type niet—je blijft in SAQ A-EP met hosted fields.

Welke SAQ heb ik nodig wanneer ik de card:payment API-integratie gebruik