# 

## What is PCI-DSS

PCI-DSS is a set of security standards created by the PCI Security Standards Council (founded by Visa, Mastercard, American Express, Discover, and JCB). Any organization that stores, processes, or transmits cardholder data must comply.

The standard covers six goals:

| Goal | Requirements |
|  --- | --- |
| Build and maintain a secure network | Install and maintain a firewall; do not use vendor-supplied default passwords |
| Protect cardholder data | Protect stored data; encrypt transmission across open networks |
| Maintain a vulnerability management program | Use and regularly update anti-virus software; develop and maintain secure systems |
| Implement strong access control | Restrict access on a need-to-know basis; assign unique IDs; restrict physical access |
| Regularly monitor and test networks | Track and monitor all access; regularly test security systems and processes |
| Maintain an information security policy | Maintain a policy that addresses information security for all personnel |


## Compliance levels

PCI-DSS defines four merchant compliance levels based on annual transaction volume.

| Level | Annual card transactions | Validation requirements |
|  --- | --- | --- |
| 1 | Over 6 million | Annual on-site audit (QSA), quarterly network scan (ASV) |
| 2 | 1–6 million | Annual SAQ, quarterly ASV scan |
| 3 | 20,000–1 million (e-commerce) | Annual SAQ, quarterly ASV scan |
| 4 | Under 20,000 (e-commerce) or up to 1 million (other) | Annual SAQ, quarterly ASV scan (recommended) |


**Paradise Pay is PCI Level 1 certified** — the highest level of compliance, validated through an annual on-site audit by a Qualified Security Assessor (QSA).

## Your compliance responsibility

As an API integrator, your PCI scope depends on how you handle cardholder data.

![image](https://files.modern-mermaid.live/images/1776270576037-mermaid-diagram-1776270576237.png)

### Integration approaches and PCI impact

| Approach | Your PCI scope | How it works |
|  --- | --- | --- |
| **Direct API** (server-to-server) | SAQ D — highest scope | Your server collects the PAN and sends it toReefpay. You must meet all PCI-DSS requirements for systems that handle cardholder data. |
| **Tokenize then transact** | SAQ A-EP — reduced scope | Your front end sends card data directly toReefpay's tokenization endpoint. Your server receives only the token and never sees the PAN. |
| **Hosted fields / iFrame** | SAQ A — lowest scope | Reefpay renders the card input fields in an iFrame on your page. Your systems never touch cardholder data at all. |


Recommendation
Use tokenization to minimize PCI scope. Send raw card data directly from the client to `POST /v1/payment_tokens`, then use the returned token for all server-side operations. This keeps your servers out of PCI scope for cardholder data storage.

## WhatReefpay handles

As a PCI Level 1 service provider,Reefpay implements all PCI-DSS controls for data within its environment.

| Area | Control |
|  --- | --- |
| Data storage | Cardholder data encrypted at rest with AES-256 CBC |
| Data transmission | TLS 1.2+ for all API communication |
| Token vault | Sensitive data stored in isolated, encrypted vault |
| Access control | Role-based access, per-merchant data isolation |
| Monitoring | All access to cardholder data logged and auditable |
| Network security | Firewalls, intrusion detection, regular penetration testing |
| Key management | Encryption keys rotated on a defined schedule |


## What you must handle

Even with tokenization, integrators are responsible for securing their own environment.

### Always required

* **TLS for API calls** — all requests toReefpay must use HTTPS (TLS 1.2+).
* **API key security** — store API keys securely; never expose them in client-side code or logs.
* **Access control** — restrict who in your organization can access theReefpay dashboard and API keys.
* **Logging** — log transaction activity (using `correlation_id`, not raw card data) for audit and dispute resolution.


### Required for SAQ D (direct API with raw card data)

* Full PCI-DSS controls on servers that handle cardholder data
* Encryption key management for any locally stored sensitive data
* Regular vulnerability scans and penetration testing
* Network segmentation to isolate cardholder data environment


## SAQ types explained

| SAQ | Full name | Applies when |
|  --- | --- | --- |
| A | Card-not-present, fully outsourced | All cardholder data functions outsourced (hosted fields, redirect) |
| A-EP | Card-not-present, partial outsourced | Your website controls the payment page but card data goes directly to the gateway |
| D | All other merchants | Your server directly handles cardholder data |


## Compliance checklist for integrators

Use this checklist to assess your integration's PCI requirements.

* [ ] Identify your integration approach (direct API, tokenize-then-transact, hosted fields)
* [ ] Determine your SAQ type based on the approach
* [ ] Ensure all API communication uses TLS 1.2+
* [ ] Store API keys in a secure secrets manager — not in source code
* [ ] If handling raw card data (SAQ D), implement full PCI-DSS controls
* [ ] If using tokenization (SAQ A-EP), verify that your server never logs or stores raw card data
* [ ] Set up monitoring and alerting for API access
* [ ] Complete the appropriate SAQ annually
* [ ] Schedule quarterly ASV scans if required


## Further reading

* [About tokenization](/docs/concepts/tokenization/what-is-tokenization)
* [About data protection](/docs/concepts/security-compliance/data-protection)
* [About fraud prevention](/docs/concepts/security-compliance/fraud-protection)
* [PCI Security Standards Council](https://www.pcisecuritystandards.org/) (external)