PCI DSS

Introduction

When paying online with their credit cards, you want your customers to feel safe. Therefore, the secure transfer of their card data is one of the cornerstones of the online transaction business.

Acknowledging this, the major card schemes (i.e. Visa, MasterCard, American Express) and payment providers (i.e. Bancontact) enforce a worldwide standard set up to protect cardholder data and help businesses process card payments securely. The Payment Card Industry Data Security Standard (PCI DSS) is mandatory for all parties handling card data.

As a merchant, you have the responsibility as a minimum to fill out a self-assessment questionnaire on a yearly basis, proving that you comply to the standard. The length and rigor of the questions and the questionnaire itself depend largely on the way you process payments and choose to integrate our payment systems.

So how can you determine which questionnaire applies to you? The following chapter will help you further understand the impact of the PCI DSS on your business operations.

PCI compliancy type

Our API exposes various POST resources. These POST resources vary greatly in terms of sensitive data being exchanged or not. In some cases, a single resource might even be used with or without sensitive data (i.e. CreatePayment with either card or token property respectively).

However, your required PCI type for any POST request comes down to this question:

How did you process your customers' card number for their initial payment?

The answer to this question defines your required PCI type for any subsequent request linked to the initial transaction.

Have a look at these use cases to understand the impact of PCI compliancy on your everyday transaction processing business:

Use case 1: Process transactions via Server-to-server with card property

Operation	POST resource	Required PCI type
Initial payment via Server-to-server with card property	CreatePayment With sensitive data exchanged	SAQ D
Capture the payment	CapturePayment No sensitive data exchanged	SAQ D
Refund the payment	RefundPayment No sensitive data exchanged	SAQ D

Use case 2: Process transactions via Hosted Checkout Page

Operation	POST resource	Required PCI type
Initial payment via Hosted Checkout Page	CreateHostedCheckout No sensitive data exchanged	SAQ A
Capture the payment	CapturePayment No sensitive data exchanged	SAQ A
Refund the payment	RefundPayment No sensitive data exchanged	SAQ A

Although both uses cases target the same endpoints (CapturePayment / RefundPayment) for following-up on the initial transaction, the required PCI types differ. Hence, your PCI compliancy requirements for every POST resource are defined by the way you process initial transactions.

This definition of PCI compliancy is also applicable when targeting the same resource in a scenario like this:

Use case 3: Create token for Card On File payments

Operation	POST resource	Required PCI type
Initial payment and token creation via Server-to-server with card property	CreateHostedCheckout With sensitive data exchanged	SAQ D
Use the token for a Card On File payment	CreatePayment No sensitive data exchanged	SAQ D

The way you process initial payments is determined by your integration method. Consequentially, the integration method you choose defines your global PCI requirements.