Module 6 · 6.3

English ▾

Nederlands English Deutsch Français Español Italiano

Payment security: PCI and fraud

Module 6: Management and security · Reading time: 11 minutes

Learning objective: After this lesson you can explain why a shop never processes card data itself, what PCI DSS and SAQ A mean for a small shop, how to protect the checkout page, and how to recognise and limit fraud and card testing.

Key concepts: PCI DSS, card data, payment provider, redirecting to the payment page, embedded payment form (iframe), SAQ A, scripts on the checkout page, e-skimming, https, HSTS, card testing, rate limiting, captcha, 3-D Secure, chargeback, fraud risk

Card data does not belong in your shop

A credit card number, the expiry date and the security code are worth gold to criminals. Anyone who stores or passes them on falls under PCI DSS (Payment Card Industry Data Security Standard), the security standard of the card companies. The current version is v4.0.1. For a business that processes card data itself, that is a hefty set of requirements: network segmentation, logs, scans, testing by an approved party.

A small shop does not want to be in that position, and it does not have to be. The fixed rule: card data never enters your shop. The customer types it in at your payment provider (Mollie, Stripe, PayPal, WooPayments or another one, lesson 4.4). Your shop is then only told: paid or not, with a reference. No card number, no code. That also means:

never create your own form field for card numbers, not even "just for a telephone order";
never accept card data by email, chat or phone and put it in a note on the order;
do not use a plugin that stores card data in your own database.

Redirect or embedded: SAQ A

Small shops show that they comply with PCI DSS by completing an SAQ (Self-Assessment Questionnaire). Your payment provider sometimes asks for one. The lightest is SAQ A, for shops that fully outsource payment. There are two ways this works in a shop:

Redirect. After "place order", the customer goes to the provider's payment page and then back. Your shop never sees the card data, not even the page where it is typed in.
Embedded form. The payment field sits on your checkout page, but it is an iframe (a piece of page) from the provider. The card data goes straight from the browser to the provider.

Since 31 March 2025 a new version of SAQ A applies. It contains a condition that mainly affects the second method: if you use an embedded form, you must confirm that your site is not susceptible to attacks with scripts that could affect the payment system. The background is e-skimming: a malicious script on your checkout page that reads along with what the customer types, or lays a fake payment field over the real one. If you redirect to the provider's page, that condition does not apply to you. Ask your payment provider which SAQ applies to your integration; they know exactly.

What you do in any case:

Keep the checkout page bare. Every script on that page can in principle read along: chat widgets, tag managers, advertising pixels, A/B testing tools. Load only what the payment needs on the checkout page. A tag manager on the checkout page is a gateway through which anyone with access to that account can add scripts.
Few plugins, and kept up to date (lesson 6.2). Most e-skimming on WordPress gets in through a vulnerability in a plugin or a stolen administrator password.
A Content-Security-Policy (a header that states which domains scripts may come from) limits the damage if something does get in. That is work for someone who can test it; a wrong CSP breaks your payment button.

https and HSTS on the checkout page

That your whole shop runs over https goes without saying (WordPress course, lesson 3.1). For the checkout page, two things are added:

http must redirect straight to https, with a permanent redirect (301 or 308). A customer who ever types http://shop.example.com/afrekenen/ must not get an unencrypted page.
HSTS (HTTP Strict Transport Security) is a header that tells the browser to open your site only over https for a period of time. This prevents someone on open Wi-Fi from intercepting the first unencrypted request. A max-age of at least 180 days is a common minimum. Only switch HSTS on once everything, including any subdomains you include, works over https: a browser that has seen HSTS will refuse http afterwards. KB 6752 explains how to set it up.

Mixed content (a script or stylesheet loaded over http on an https page) on the checkout page is particularly dangerous: exactly that kind of file can be replaced in transit.

Card testing

With card testing, criminals use your shop to try out stolen card numbers. They automatically place hundreds of small orders. Every successful payment tells them a card works. You get a pile of failed orders, per-transaction fees, chargebacks and, in the worst case, a payment provider that blocks your account.

Recognising it: many orders in a short time, often for the same small product, with different names but the same or odd addresses, and lots of orders with the status Failed.

Limiting it:

Rate limiting (a limit on the number of requests per period of time). The WooCommerce Store API, used by the cart and checkout blocks, has rate limiting built in, but it is off by default. Under WooCommerce > Settings > Advanced > Features you can switch on "Rate limiting Checkout block and Store API" for placing orders. With code (a filter) you can set the limit yourself; the default is 25 requests per 10 seconds and only orders and other write actions count. If your shop sits behind a proxy or CDN, proxy support must be switched on, otherwise all visitors count as one.
A captcha or a similar hurdle at checkout. WooCommerce itself says rate limiting and a captcha work best together: attackers often switch IP address.
Your payment provider's settings. Providers have their own fraud filters and limits. Switch them on and see what they report.
3-D Secure (the extra confirmation in the banking app, part of strong customer authentication in the EU) makes things harder for criminals and, in a dispute, often shifts liability to the cardholder's bank.

Other fraud

Not all fraud is automated. Signals that, taken together, are a reason to hold off on shipping for a while:

billing and delivery address in different countries, or a delivery address at a parcel forwarding service;
a first order with only expensive, easy-to-resell products, with express shipping;
several attempts with different cards;
a customer who asks after payment for the order to be sent to a different address.

A chargeback is the reversal of a card payment by the customer's bank. You lose the amount, often with fees, and the product is gone. So keep proof of shipping and delivery. Until now, an iDEAL payment could not be reversed in this way; how this works with Wero, your payment provider will tell you (lesson 4.4).

Summary

Card data never enters your shop: not in forms, notes or emails. The payment provider processes it.
Redirecting to the payment page or using an embedded field from the provider keeps you on the lightest PCI questionnaire (SAQ A); with an embedded field, your checkout page must be protected against script attacks.
Keep the checkout page bare, served over https with a 301 from http and with HSTS of at least 180 days.
You limit card testing with rate limiting (off by default), a captcha and your provider's filters.
Watch for signs of fraud and keep proof of delivery to defend against chargebacks.

Quiz

1. A customer phones and wants to give you their card details for an order. What do you do? You write them in the note on the order
You email them to yourself for later
You do not accept them and send a payment link from your provider
You put them in a spreadsheet

Card data never enters your own systems; a payment link lets the customer pay at the provider themselves.

2. Why is a tag manager on the checkout page a risk? Scripts that read what the customer types can be added through it
It makes the page slower, nothing more
It switches off https
It stops the confirmation email being sent

Every script on the checkout page can in principle read along; e-skimming uses exactly that route.

3. In one night, 300 orders come in for a single € 2 product, most with the status Failed. What is probably happening? A successful promotion
A WooCommerce update
The cache is not working
Card testing: someone is trying stolen cards via your shop

Many small orders with many failed payments in a short time is the pattern of card testing.

4. Is Store API rate limiting switched on by default? Yes, always
No, you switch it on yourself, for example for checkout in the WooCommerce features
Only with iDEAL
Only if you have a captcha

Rate limiting is optional and off by default.

Exercise

Exercise A6.3: Is your checkout page secure? Enter the address of your shop and the address of your checkout page. The program checks the certificate and requests the checkout page over http (without following redirects) and over https (with an empty cart, nothing is ordered). Green if the certificate is valid, http redirects to https with a 301 or 308, the Strict-Transport-Security header has a max-age of at least 180 days, there is no mixed content and no more than five other domains load scripts on the page (the program lists them). Orange if HSTS is missing or too short, the redirect is temporary (302 or 307), there are more than five script domains or a tag manager, or there is a card number field in your own HTML instead of at the provider. Red if https or the certificate is not right, http does not redirect, or scripts or stylesheets load over http. Never store card data yourself. This check only sees what is on the page without a cart.

A question for yourself (not checked): does your payment plugin redirect to the provider, or is the payment field on your page? Which SAQ does your provider say applies?

A green tick means this check passes now, not that your shop is secure.

Exercise A6.3: Is your checkout page secure?

Address of your shop (for example shop.example.nl)

Checkout (path or address, for example /checkout/)

What you enter and what we find isn't stored. Your browser remembers your answers and whether you've passed the exercise. If you're signed in, we only save that you got the exercise (almost) right in My courses; you can delete that there too.

Cookies at WebOké

Cookie settings

Necessary

Marketing