PCI DSS Compliance

Felloh is PCI DSS Level 1 compliant — the highest certification level in the payment card industry. This guide explains what that means for your business, how our architecture minimises your compliance burden, and what you need to do to stay compliant.

What is PCI DSS?

The Payment Card Industry Data Security Standard (PCI DSS) is a set of security requirements designed to protect cardholder data. Any business that accepts, processes, stores, or transmits card data must comply.

PCI DSS has four compliance levels based on transaction volume:

Felloh is certified at Level 1 — meaning our infrastructure, processes, and controls have been audited and validated to the highest standard.

How Felloh handles PCI compliance

Felloh achieves PCI DSS Level 1 compliance through a partnership with Basis Theory, a certified PCI Level 1 Service Provider. This architecture means:

1. Card data never enters Felloh's servers — when a customer enters their card details via a Felloh payment link, ecommerce session, or the JavaScript SDK, the data is collected and vaulted directly by Basis Theory
2. Card data never enters your servers — your integration only handles opaque tokens and transaction references, never raw card numbers or CVVs
3. Felloh operates on tokens — all internal processing uses tokenised references, not raw card data

Customer's browser → Felloh payment form → Basis Theory vault
                                              ↓
                                         Token returned
                                              ↓
                        Felloh API ← processes payment using token
                                              ↓
                        Your server ← receives transaction result (no card data)

Your PCI compliance obligations

Even though Felloh handles cardholder data, your business still has PCI obligations. The good news: by using Felloh's hosted payment forms, your obligations are minimal.

SAQ A — The simplest path

If you use one of these integration methods, you qualify for SAQ A (Self-Assessment Questionnaire A) — the lightest PCI compliance requirement:

SAQ A requires you to confirm approximately 20 security controls — mostly around secure website configuration and access control. No penetration testing or network scanning is required.

What SAQ A requires

Even with SAQ A, you must:

• Serve your website over HTTPS — all pages, not just the checkout
• Keep software up to date — apply security patches to your web server, frameworks, and dependencies
• Restrict access to systems — only authorised personnel should access your payment configuration
• Maintain a security policy — document your approach to information security
• Not store cardholder data — never log, cache, or store card numbers or CVVs

When you need more than SAQ A

If you build a custom form that directly collects card numbers (bypassing Felloh's SDK and payment forms), your PCI scope increases significantly. You would need to complete SAQ A-EP or a full SAQ D, which involves meeting over 300 security controls.

What you can and cannot store

Safe to store (outside PCI scope)

The following data returned by the Felloh API is non-sensitive and can be stored in your systems:

• Card brand (e.g. Visa, Mastercard, Amex)
• Last four digits of the card number
• Expiry month and year
• Cardholder name
• Transaction IDs and references
• Payment amounts and statuses
• Booking references

Never store

You must never store the following data — and with Felloh's integration approach, you will never receive it:

• Full card number (PAN)
• CVV / CVC / security code
• PIN or PIN block
• Full magnetic stripe data
• Card verification values from the chip

PCI compliance for travel businesses

Travel businesses have specific PCI considerations:

Tokenised cards for scheduled payments

When a customer pays a deposit, Felloh automatically tokenises their card for future use. You can then create scheduled payments using the token — charging the balance before departure without the customer re-entering their card details.

This is fully PCI compliant because:

• You never handle the card data — it was tokenised at the point of the initial payment
• You only reference a token ID when creating the scheduled payment
• Felloh and Basis Theory handle the secure storage and processing

MOTO (Mail Order / Telephone Order)

If your travel agency takes card details over the phone, do not enter them into your own system. Instead, send the customer a payment link so they can enter their details directly into Felloh's secure payment form. This keeps your PCI scope at SAQ A.

Agent-assisted bookings

When a travel agent creates a booking on behalf of a customer, use payment links to collect payment. The agent creates the booking and payment link via the Felloh API or Dashboard, then sends the link to the customer. The agent never handles card data.

Compliance checklist

Use this checklist to confirm your integration meets PCI DSS requirements:

• Payment collection uses Felloh-hosted forms — payment links, JavaScript SDK, or mobile SDKs
• Your website is served over HTTPS with TLS 1.2 or later
• HSTS is enabled on your domain
• API keys are stored securely in environment variables or a secrets manager, not in source code
• Private keys are never exposed in client-side code or public repositories
• No cardholder data is logged or cached in your application logs, databases, or error tracking systems
• Access to payment systems is restricted to authorised personnel only
• Webhook signatures are verified using HMAC-SHA256 before processing
• Dependencies are kept up to date with known vulnerabilities patched promptly
• You have completed the appropriate SAQ (SAQ A for most Felloh integrations)

Further reading

• Security at Felloh — Our security certifications, infrastructure, and practices
• Integration Security Guide — Best practices for building a secure integration
• Strong Customer Authentication (SCA) — 3DS and SCA requirements for travel payments
• Basis Theory — Our PCI Level 1 tokenisation partner
• PCI Security Standards Council — Official PCI DSS documentation