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.
Find our PCI certificate here.
What is PCI DSS Compliance?
PCI DSS is a security standard designed to protect cardholder data. Compliance prevents fraud, maintains customer trust, and avoids penalties.
To become PCI DSS compliant, merchants must follow specific steps to ensure their payment data security and adherence to standards:
- Understand PCI DSS Requirements: Familiarize yourself with the PCI DSS standards that protect cardholder data and ensure secure payment transactions.
- Consultation and Training: Utilize Worldline services to gain insights into the criteria you need to meet.
- Use PCI DSS Validated Solutions: Implement validated third-party solutions for payment data processing.
- Implement Security Standards: Process card data in accordance with security standards and ensure your equipment and systems meet these requirements.
- Identify the Relevant SAQ: Complete the appropriate Self-Assessment Questionnaire (SAQ) based on your card payment processing methodology (see SAQ types on the first slide).
- Compliance Reporting: Depending on your merchant level (from 1 to 4), regularly submit compliance reports through the respective methods like audits, ASV scans, or SAQs.
- Use Worldline Portals: Leverage the Worldline's web-based, self-service portal that offers tools to validate PCI DSS compliance and provides the needed resources for a comprehensive compliance journey.
- Contractual Obligations: Remember that compliance obligations are part of the general conditions for merchants using Worldline services.
By following these steps, merchants can ensure they meet PCI DSS requirements, thereby securing payment data and complying with regulatory standards.
Maintaining Compliance
Regularly update your security measures, review policies, and keep staff informed on best practices. We are here to assist with expert guidance. Contact us for more information.
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 |
With sensitive data exchanged |
SAQ D |
Capture the payment |
No sensitive data exchanged |
SAQ D |
Refund the payment |
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 |
No sensitive data exchanged |
SAQ A |
Capture the payment |
No sensitive data exchanged |
SAQ A |
Refund the payment |
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 |
With sensitive data exchanged |
SAQ D |
Use the token for a Card On File payment |
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.