# 

## Defense in depth

Paradise Pay applies multiple layers of encryption and access control to protect payment data throughout its lifecycle.

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

## Encryption in transit

All communication withReefpay is encrypted using TLS (Transport Layer Security).

| Requirement | Details |
|  --- | --- |
| Protocol | TLS 1.2 or higher |
| Enforcement | HTTP requests are rejected; only HTTPS is accepted |
| Certificate | Issued by a trusted Certificate Authority (CA) |
| Cipher suites | Strong ciphers only; weak or deprecated ciphers are disabled |


### What this means for integrators

* Always use `https://` for all API requests to `api.sandbox.paradisegateway.net` (sandbox) and the production endpoint.
* Verify TLS certificates in your HTTP client — do not disable certificate validation.


## Encryption at rest

Sensitive payment data stored in the token vault is encrypted using AES-256 in CBC mode.

| Component | Encryption method |
|  --- | --- |
| Card PANs | AES-256 CBC |
| Bank account numbers | AES-256 CBC |
| Routing numbers | AES-256 CBC |
| CVV values | Not stored (used for authorization only, then discarded) |
| Encryption keys | Managed in a dedicated key management system, rotated on schedule |


### Key management

* Encryption keys are stored separately from the encrypted data.
* Keys are rotated on a defined schedule in compliance with PCI-DSS key management requirements.
* Key access is restricted to authorized processes only — no human access to production encryption keys.
* Key rotation is transparent to integrators and does not require any changes to your integration.


## Write-only sensitive fields

The API enforces a strict write-only policy for sensitive payment data. Fields like PAN, CVV, account number, and routing number are accepted in requests but are **never returned** in any API response.

| Field | Accepted in requests | Returned in responses |
|  --- | --- | --- |
| `pan` (card number) | Yes | No — `last_four` and `bin` returned instead |
| `cvv` | Yes | No — `cvv_result` code returned instead |
| `expiry.month` / `expiry.year` | Yes | No (for inline cards); Yes (for stored tokens) |
| `cardholder_name` | Yes | No |
| `account_number` | Yes | No — `last_four` returned instead |
| `routing_number` | Yes | No |


This design ensures that even if API response logs are compromised, no usable cardholder data is exposed.

## Data isolation

Paradise Pay operates a multi-tenant architecture with strict data isolation between merchants.

| Isolation layer | Implementation |
|  --- | --- |
| Token scoping | Tokens are bound to a specific merchant MID and cannot be used across merchants |
| Encryption key isolation | Per-merchant encryption keys prevent cross-tenant data access |
| API key scoping | API keys authenticate to a specific merchant or reseller account |
| Query filtering | All data queries are automatically scoped to the authenticated merchant |


## What data you should protect

Even thoughReefpay handles the most sensitive payment data, integrators are responsible for protecting data in their own environment.

### Data to protect

| Data | Protection |
|  --- | --- |
| API keys | Store in a secrets manager (not source code, config files, or client-side code) |
| Payment tokens | Store securely, but no PCI-level controls required |
| Transaction IDs | Log for reconciliation; no sensitivity concerns |
| `correlation_id` values | Log for debugging and support requests |
| Customer PII (name, email, address) | Protect per your privacy policy and applicable regulations |


### Data you should never store

| Data | Reason |
|  --- | --- |
| Full card numbers (PAN) | PCI-DSS violation if stored without full compliance |
| CVV / CVC / CID | PCI-DSS prohibits storage of CVV after authorization, even if encrypted |
| Raw bank account or routing numbers | Unnecessary risk — use tokens instead |
| API response bodies containing sensitive data | The API does not return sensitive data, but verify your logging does not capture request bodies containing PANs |


Log hygiene
Audit your application logs to confirm that request bodies containing raw card data are masked or excluded. Log the `correlation_id` and transaction ID instead.

## Security headers

Paradise Pay API responses include standard security headers.

| Header | Purpose |
|  --- | --- |
| `Strict-Transport-Security` | Enforces HTTPS for future requests |
| `X-Content-Type-Options` | Prevents MIME type sniffing |
| `X-Frame-Options` | Prevents clickjacking via iFrame embedding |


## Further reading

* [About PCI-DSS compliance](/docs/concepts/security-compliance/pci-dss-overview)
* [About fraud prevention](/docs/concepts/security-compliance/fraud-protection)
* [About tokenization](/docs/concepts/tokenization/what-is-tokenization)