Security & PCI Compliance

PCI compliance model

ElasticPay is PCI DSS compliant. When you use the hosted checkout or the widget, card data never touches your servers — it flows directly from the customer’s browser to the ElasticPay Cardholder Data Environment (CDE) and is tokenized there.

Your PCI scope is minimal: you receive a payment method token (pm_xxx), not raw card data.

CDE architecture

The ElasticPay architecture separates card data handling from business logic:

Component	Role	PCI scope
worker-pay (Cloudflare Worker)	Card tokenization, PSP integration	Managed by ElasticPay
client-pay (Cloudflare Worker)	Widget serving, hosted checkout	Managed by ElasticPay
Your backend	Business logic, payment initiation	Out of scope (when using widget or hosted checkout)

Your backend only ever sees pm_xxx tokens, which are not card data and are not PCI in-scope.

What you’re responsible for

• Secure your secret keys. Never expose sk_... keys in client-side code or source control.
• Use HTTPS. All pages that load the payment widget must be served over HTTPS.
• Verify webhook signatures. Authenticate incoming webhook events using the X-Webhook-Signature header. See Webhooks.
• Access control. Restrict dashboard access and API key visibility to only the people who need it.

What ElasticPay handles

• Card number tokenization via our PCI Token Vault
• Encryption of card data in transit and at rest
• PCI DSS Level 1 audit and certification
• Key rotation for cryptographic keys
• Fraud detection at the PSP layer

Direct API integration

If you send raw card numbers directly to the API (not via the widget), your server handles card data and your integration becomes in-scope for PCI DSS. You will need to complete your own PCI assessment.

Caution

Always prefer the widget or hosted checkout to keep your integration out of PCI scope. Only submit raw card data via the API if you have a specific need and the infrastructure to support PCI compliance.