Payment security in PrestaShop: PCI compliance, 3D Secure and fraud prevention

Last updated: June 2026. This is general guidance, not legal or compliance advice, confirm your PCI scope and SCA obligations with your acquirer or payment service provider.

Here is the reframe that saves PrestaShop merchants the most money and worry on payment security: in almost every modern setup, you do not handle card data at all, and the entire job is to keep it that way. PCI DSS, 3D Secure and fraud screening sound like three separate compliance burdens. They are really one decision made well (never let a card number touch your server) plus two things that mostly happen for you once you've configured the gateway correctly. This guide is specifically about payment security at the moment money changes hands: keeping your PCI scope at its smallest, getting Strong Customer Authentication right so legitimate orders don't fail, and stopping the fraudulent ones before they cost you a chargeback. For the broader job of locking down the store itself, admin hardening, file permissions, malicious-module detection, that's a different post, linked at the end.

PCI DSS: the only decision that really matters

PCI DSS (the Payment Card Industry Data Security Standard) applies to every business that processes, stores or transmits cardholder data. There is no "too small to count" exemption. But the standard is scoped to what your systems touch. The less card data flows through your server, the smaller the self-assessment you have to complete and the smaller your liability if anything ever goes wrong. That is the entire game, and PrestaShop's architecture lets you win it cleanly.

The mechanism is how the payment module renders its form. There are two patterns, and which one your gateway uses decides everything:

So what? Choosing a hosted-field gateway is the difference between a 20-question annual checkbox exercise and a several-hundred-item audit with quarterly vulnerability scans and a duty to encrypt and segment card data you should never have been holding. For the overwhelming majority of PrestaShop stores there is no reason to take the harder path.

How to keep PrestaShop in SAQ A territory

The official PrestaShop payment modules are built around hosted fields precisely so you stay in the simple bucket. In practical terms:

• Stripe (the official PrestaShop module by Stripe) renders the card field through Stripe Elements, an iframe hosted by Stripe. Your server only ever receives a tokenised PaymentIntent reference, never the PAN. The module registers on the paymentOptions hook (and displayPaymentReturn) like every well-behaved gateway.
• PayPal (the official module) redirects to PayPal or uses its hosted card fields, the same zero-touch result.
• Mollie and Adyen Drop-in both keep entry on the provider's side.

The trap to avoid: an old or unofficial "direct" module that renders a raw card form on your own checkout page (a plain input in the payment step rather than the gateway's iframe). The moment a PAN is submitted to your domain, you have silently jumped from SAQ A to SAQ D, and most merchants who did this don't realise it until an acquirer asks. If you are not certain how your current module behaves, open your checkout, right-click the card field and inspect it: if it sits inside an iframe pointing at the gateway's domain, you're hosted and safe; if it's a normal input on your own URL, you have a scoping problem to fix.

SELECT h.name AS hook, m.name AS module
FROM ps_hook_module hm
JOIN ps_hook h ON h.id_hook = hm.id_hook
JOIN ps_module m ON m.id_module = hm.id_module
WHERE h.name IN ('paymentOptions', 'displayPaymentReturn')
ORDER BY h.name, m.name;

Payment security starts by knowing exactly which payment modules are active.

One more PrestaShop-specific point: do not enable cardholder data logging. If a custom module or override writes payment payloads into var/logs, or into PrestaShop's ps_log table, or into order messages for "debugging," you have just brought card data back into scope even though the gateway never exposed it. Card data in a log file is the classic way a SAQ-A store accidentally becomes a breach story.

3D Secure 2 and SCA: getting authentication right, not just on

3D Secure adds an issuer-side authentication step to a card payment. Since 14 September 2019, the EU's PSD2 directive has required Strong Customer Authentication (SCA) on most online card transactions in the European Economic Area, and 3DS2 is the mechanism that satisfies it. SCA is generally required for EEA electronic card payments where PSD2 applies, but the trigger is not simply "selling to EU customers." It depends mainly on whether an EEA-regulated PSP, acquirer and issuer are involved and on the transaction type, with documented exemptions and out-of-scope cases (such as one-leg transactions where one party sits outside the EEA). Your PSP or gateway is the one that determines which exemptions apply and what falls out of scope. Where SCA does apply, a card payment that should have been authenticated and wasn't will simply be declined by the issuer. So the real question is never "should I turn on 3DS?" but "is it configured so genuine customers sail through and only the risky ones get challenged?"

3DS2 has two flows, and the split between them is where your conversion lives:

• Frictionless flow, the issuer authenticates silently from device and transaction signals. The customer sees nothing; the order just completes. This is the goal, and it depends on your checkout passing rich data to the gateway (billing address, email, device data).
• Challenge flow, for higher-risk transactions the issuer shows an authentication step (banking-app approval, biometric, or an SMS one-time code). More friction, but it's the issuer's call, not yours.
• Liability shift, when a payment is authenticated via 3DS, chargeback liability for "I didn't authorise this" moves from you (the merchant) to the card issuer. This is the quiet financial benefit people forget: 3DS isn't only a compliance box, it's fraud-loss insurance you don't pay a premium for.

So what does this mean in your PrestaShop back office? With the official Stripe module, 3DS2 / SCA handling is built into the PaymentIntents flow. There is no separate switch to flip, but you should confirm your account is on the current API and the module is updated, because issuers tighten their rules over time. The practical levers that move transactions into the frictionless lane:

• Collect a complete, validated billing address. Sparse or mismatched address data pushes the issuer's risk engine toward a challenge. This is one more reason a clean checkout matters. See how Europe expects prices and totals to be displayed for the transparency side of the same checkout.
• Keep the module current. 3DS2 is versioned (the EMVCo spec moves), and acquirers periodically retire older protocol versions. An out-of-date payment module is the most common reason previously-fine payments start failing at authentication.
• Watch for "exemptions." Low-value and low-risk transactions can qualify for SCA exemptions that skip the challenge, but the gateway requests these, you don't hand-configure them per order. Leave it to the official module rather than a custom hack.

Fraud prevention: what you actually control in PrestaShop

3DS shifts liability on the cards it covers, but it doesn't stop every loss, friendly fraud, manual-review orders, and methods outside 3DS still reach you. Fraud screening is the layer where PrestaShop's own data and your gateway's tools work together. The useful framing: catch the obviously bad orders cheaply, flag the maybe-bad ones for a human, and let everything else through untouched.

Address Verification (AVS) and CVV

AVS compares the billing address the customer typed against what the issuer has on file; CVV verification confirms they're holding the card. Both are toggled in your gateway dashboard (Stripe, for example, lets you decline on AVS/CVV mismatch via its Radar rules), not inside PrestaShop. Turn them on, they reject a meaningful share of stolen-card attempts at near-zero cost. The one caution: a strict AVS decline can also reject legitimate customers whose bank has an old address, so decline on full mismatch, not on partial.

Velocity and pattern checks, and where PrestaShop already shows them

The classic fraud signals are patterns over time, and several are visible from your own back office before any third-party tool:

• Multiple failed payment attempts from one IP, card testing. Visible in your gateway logs and in repeated failed orders.
• Several orders to different shipping addresses on the same card, check Customers → Customers and Orders → Orders; PrestaShop links carts and addresses to the customer record.
• Billing and shipping countries that differ, or a brand-new customer placing an unusually large first order, both surface naturally in the order detail.
• A flood of new guest registrations or carts from datacentre IP ranges, often bots probing checkout rather than buyers.

PrestaShop's Stats and the customer's order history give you the raw material; the work is noticing it before you ship. For a store getting enough volume that manual review doesn't scale, this is where a monitoring layer earns its place. Our Security Revolution module watches the back-office and checkout activity PrestaShop doesn't surface on its own, flagging suspicious request patterns and bot-driven cart activity so a human looks at the orders worth looking at, and ignores the rest. The benefit: you spend review time on the handful of orders that are genuinely risky instead of eyeballing every order or, worse, finding out via a chargeback weeks later.

The Security Revolution blocked-attempts screen lists entries by type, reason, IP address and date, and reports no blocked attempts in the last 24 hours.

The Security Headers screen shows which response headers are present, which are missing, and one-click Basic, Standard and Strict presets to apply.

Device fingerprinting and dedicated fraud tools

For higher-risk catalogues (electronics, gift cards, anything resold easily), gateway-native screening goes further than address checks. When enabled in your Stripe account, Stripe Radar can evaluate and score every transaction, it's a Stripe-side payment-processing feature, not something the PrestaShop module ships or runs; PrestaShop only passes the payment through the module flow. Standalone services such as Signifyd or Riskified add device fingerprinting and, in some cases, a chargeback guarantee. The decision is volume-driven: below a certain order count, AVS/CVV plus 3DS plus a careful eye is enough; above it, the time saved by automated screening pays for the tool. Don't buy a fraud platform for a store doing twenty orders a day, and don't rely on manual review for one doing two thousand.

A decision framework: how much fraud defence do you need?

Notice the PCI column never changes: hosted fields and SAQ A are right for almost everyone. What scales with your risk is the fraud layer, not the compliance burden.

If something does go wrong: a short incident plan

Even a well-run store should know its first moves before it needs them, because the worst time to figure out who to call is during a live incident:

• Detect, gateway fraud alerts, a spike in failed payments or chargebacks, or a customer reporting an unauthorised charge.
• Contain and contact. Your payment processor first (they can freeze and investigate), then your hosting provider, then legal counsel if cardholder data may be involved. Because you stayed in SAQ A, a breach of your systems should not expose card numbers. Which is the whole point of never touching them.
• Notify, if personal data of EU customers is exposed, GDPR's 72-hour breach-notification clock starts. The data-protection side of that is its own topic, see GDPR for online stores.
• Preserve evidence, don't wipe logs or orders; your processor and any investigator will need them.

FAQ

How do I tell whether my store is in the easy PCI bucket (SAQ A)?

Open your checkout, right-click the card field and inspect it. If the card input sits inside an iframe pointing at the gateway's domain (Stripe, PayPal, Mollie, Adyen), the card number never touches your server and you're in SAQ A territory, roughly a 20-question annual self-assessment. If it's a plain input on your own URL, the PAN passes through your PHP and you've jumped to SAQ D (300+ requirements with quarterly scans). The official PrestaShop payment modules are built around hosted fields precisely so you stay in the simple bucket.

Do I need to turn 3D Secure on manually in PrestaShop?

With the official Stripe module, 3DS2 / SCA handling is built into the PaymentIntents flow, there's no separate switch to flip. What you should do is confirm your account is on the current API and keep the module updated, because issuers and acquirers tighten and retire protocol versions over time, and an out-of-date payment module is the most common reason previously-fine payments start failing at authentication.

Why do some legitimate orders get a 3D Secure challenge while others sail through?

The issuer decides, based on the data your checkout passes. Rich, validated data (a complete billing address, email, device signals) pushes more transactions into the silent frictionless flow; sparse or mismatched data pushes the issuer's risk engine toward the challenge flow. So the practical lever for conversion is collecting clean, complete billing data. Not disabling authentication, which (where SCA applies) just gets the order declined by the issuer instead.

What's the cheapest fraud protection I should turn on first?

AVS (address verification) and CVV checks, both toggled in your gateway dashboard rather than inside PrestaShop. They reject a meaningful share of stolen-card attempts at near-zero cost. One caution: decline on a full AVS mismatch, not a partial one, so you don't reject genuine customers whose bank has an old address on file. Add device fingerprinting or a dedicated fraud service only once your volume outgrows a careful human eye.

Could I accidentally bring card data back into PCI scope on PrestaShop?

Yes. The classic way is logging. If a custom module or override writes payment payloads into var/logs, the ps_log table, or order messages "for debugging," you've reintroduced card data even though the gateway never exposed it. Never enable cardholder-data logging; card data in a log file is how a SAQ-A store accidentally becomes a breach story.

The rest of your store still needs locking down

This post is deliberately scoped to the payment moment. The other half of security, renaming the admin directory, enforcing HTTPS site-wide, correct file permissions, two-factor admin login, vetting modules so a malicious one never gets installed. Lives in our plain-English guide to securing your PrestaShop store. And because payment security touches the same checkout your compliance copy does, it's worth reading alongside the EU e-commerce law overview and, for the invoicing trail that has to match every authorised payment, invoice customization and its legal requirements.

Payment security is an ongoing posture, not a one-time setup, but on PrestaShop it's a manageable one. Keep card data off your server (hosted fields, SAQ A), let the official module handle 3DS2 and SCA so genuine EU orders go through frictionless, turn on the cheap fraud checks your gateway already offers, and add a monitoring layer only when your volume outgrows a careful human eye. Do those four things and the scary-sounding standards mostly take care of themselves.