Event Espresso and PCI Compliance

From time-to-time we will get the question, "Is Event Espresso PCI compliant?".  The short answer is that  Event Espresso does not store full credit card numbers or card security codes, so Event Espresso is great and helpful with PCI compliance. But installing Event Espresso does not make a website PCI compliant on its own. Compliance covers your whole payment setup — your website, your host, your payment gateway, and how you configure everything.

What is PCI compliance?

The Payment Card Industry Data Security Standard (PCI DSS) is a security checklist for any business that accepts credit or debit cards.

Think of it like food safety in a restaurant kitchen. The oven manufacturer builds safe equipment, but the restaurant is the one that gets inspected. Event Espresso, your gateway, and your host each supply safe equipment — you, the merchant, are the one responsible for the kitchen.

PCI DSS applies to every merchant, including very small ones. The current standard is PCI DSS v4.0.1. See the PCI Security Standards Council document library.

Can a plugin be "PCI compliant"?

Not really — and this is the most common misunderstanding.

PCI DSS is something a merchant validates, not something a plugin gets certified for. There is a separate program for payment software (the Software Security Framework, which replaced PA-DSS in 2022), but it only applies to software that actually stores, processes, or transmits card data.

Event Espresso's recommended payment methods never touch card data, so there is nothing for PA-DSS to validate. The card data goes from your customer's browser straight to the payment gateway.

Who is responsible for what?

What Event Espresso stores — and what it doesn't

Event Espresso records registrations, transaction amounts, payment status, and the gateway's transaction reference.

It is not designed to store full card numbers or security codes (CVV/CVC). Where a payment method does send card details to a gateway, Event Espresso strips the card number, security code, and expiry date out of its payment logs.

Important: PCI DSS forbids storing the card security code after a payment is authorized — by anyone, ever.

How your choice of payment method changes your obligations

This is the single biggest factor in how much PCI work you have to do.

Hosted / off-site checkout (lowest effort)

The customer is sent to the gateway's own website to pay, then returns to your site. Your website never sees the card number.

Examples: Stripe Checkout

Gateway-hosted fields or iframe (lowest effort)

The payment form looks like part of your site, but the card fields themselves are delivered by the gateway inside an iframe or hosted field. Card data goes directly to the gateway, not through your server.

Examples: Stripe, Square, and PayPal integrations.

Both of these usually qualify for the shortest self-assessment questionnaire, SAQ A — provided you meet every eligibility condition, not just the iframe part.

Direct / on-site card forms (highest effort — use with care)

A small number of older payment methods render the card fields on your own site and send them to the gateway from your server.

These put your website and server directly in scope for PCI DSS. That typically means a much longer questionnaire (SAQ D), significantly more security controls, and quarterly scans. If you have a modern alternative from the same provider, use it instead.

Offline payments (invoice, check, bank transfer)

No card data is involved, so PCI DSS doesn't apply to the Event Espresso side. But if your staff take card numbers over the phone or on paper and key them into a virtual terminal, that activity has its own PCI obligations — ask your processor which ones.

Using a gateway reduces your risk — it does not remove it

Even when card data goes straight to the gateway, a compromised WordPress site is still a serious problem. An attacker who gets into your site can rewrite your checkout page, redirect customers to a fake payment form, or overlay malicious code on top of the real payment fields. This kind of attack ("digital skimming") is exactly why the standard still holds you accountable for your website.

You also remain responsible for choosing compliant providers and understanding which parts of compliance they cover for you.

Your responsibilities as the website owner

1. Pick and verify your gateway. Use a PCI-compliant payment gateway, prefer its hosted or iframe option, and re-confirm its compliance status periodically.
2. Keep the site maintained. Update WordPress, Event Espresso, payment add-ons, themes, and all other plugins. Remove anything you don't use. Use reputable, security-conscious hosting.
3. Lock down access. Strong unique passwords, multi-factor authentication for admins, HTTPS across the entire site, and administrator access only for people who genuinely need it.
4. Watch your checkout pages. Review every third-party script you load there — analytics, ads, tag managers, live chat. Monitor for unauthorized changes and malware. Keep backups and an incident-response plan.
5. Never collect card details outside the payment form. Don't ask for card numbers or security codes in Event Espresso registration questions, contact forms, emails, support tickets, or admin notes. If a customer emails you their card number, delete it and ask them to pay through the proper form.

Which PCI questionnaire do I need?

Your payment processor, acquiring bank, or card brand decides this — not Event Espresso, and not us.

As a general guide, a fully hosted checkout or a correctly implemented gateway-hosted payment form may qualify for SAQ A, the shortest questionnaire. Other setups may require SAQ A-EP, SAQ D, or another form of validation. Using a redirect or an iframe does not automatically qualify you; every eligibility condition must be met.

One recent change worth knowing: the revised SAQ A published in January 2025 (effective 31 March 2025) removed several payment-page security requirements from the questionnaire itself and replaced them with an eligibility criterion — you must be able to confirm your site is not susceptible to script-based attacks. The underlying PCI DSS requirements still exist; only how SAQ A merchants report on them changed. See the PCI SSC announcements on the updated SAQ A and the script eligibility criteria FAQ.

What Event Espresso cannot do for you

• Secure your hosting account or server
• Maintain WordPress, your theme, or unrelated plugins
• Control custom code or third-party scripts on your checkout pages
• Confirm your business's compliance status
• Choose or complete your PCI questionnaire
• Protect card details typed into custom registration questions or other non-payment fields

For the payment options available to you, see Setting Up Payment Methods in Event Espresso.

In summary

Event Espresso helps keep sensitive card data with your payment gateway, which reduces how much of PCI DSS applies to you. It does not store full card numbers or security codes.

For most site owners, the path of least effort is:

1. Choose a reputable, PCI-compliant gateway.
2. Use its hosted checkout or hosted/iframe payment fields — avoid on-site card forms.
3. Keep the whole WordPress site secure, updated, and monitored.
4. Ask your processor or bank which PCI validation you must complete.
5. Review all of the above at least once a year, and any time you change your checkout.

Please note: This page is general educational information, not legal or compliance advice. Requirements vary by payment provider, payment flow, country, card brand, and merchant agreement. For guidance on your specific setup, consult your payment processor, your acquiring bank, or a Qualified Security Assessor (QSA).

Last reviewed: September 2026. Based on PCI DSS v4.0.1.