Payment security in your webshop: PCI, card testing, and what your hoster does

If you accept online payments, you'll have to deal with the security rules of the card companies (PCI DSS), with criminals trying to steal card details, and with card testing: trying out stolen cards in your shop. This article explains what that means for a small web shop, what you do yourself, and what your host does and doesn't arrange for you.

The main rule: card details never enter your shop

A card number, the expiry date and the security code are entered by the customer at your payment provider, not in your own shop. Your shop only gets told whether or not the payment was made. This also means:

• never your own form field for card numbers, not even for a phone order;
• never accept card details by email, chat or phone and add them to a note on an order;
• no plugin that stores card details in your own database.

PCI DSS and SAQ A in plain language

PCI DSS (Payment Card Industry Data Security Standard) is the security standard set by the card companies; the current version is v4.0.1. A company that processes card details itself has to meet a hefty set of requirements. A small shop that fully outsources payment processing demonstrates compliance with a short questionnaire: the SAQ A (Self-Assessment Questionnaire A). Your payment provider sometimes asks for this.

Outsourcing can be done in two ways:

1. Redirect: after ordering, the customer goes to the provider's payment page and then returns.
2. An embedded payment field: the payment field sits on your checkout page, but is a piece of page (iframe) from the provider.

Since 31 March 2025, a new version of SAQ A applies. If you use an embedded payment field, you must confirm in it that your site isn't vulnerable to attacks with scripts that could affect the payment. If you use a redirect, that condition doesn't apply to you. Ask your payment provider which questionnaire matches your integration.

Protecting the checkout page

• Keep the checkout page bare. Any script on that page can in principle read along with what the customer types (e-skimming): chat widgets, tag managers, ad pixels. Only load what's needed for the payment there.
• Few plugins, and always kept up to date. Malicious scripts usually get in through a vulnerability in a plugin or a stolen admin password.
• https everywhere, with redirection from http to https and HSTS. See Forcing visitors to use https and HSTS and security headers for your website.

Recognising and limiting card testing

With card testing, criminals automatically place lots of small orders to see which stolen cards work. You'll recognise it by a large number of orders in a short time, often of the same cheap product, with varying names and many orders with the status Failed. It costs you transaction fees and chargebacks, and in the worst case your payment provider blocks your account.

• Rate limiting (a limit on the number of requests per time period). WooCommerce has this built in for the checkout blocks, but it's off by default. Turn it on under WooCommerce > Settings > Advanced > Features, option Rate limiting Checkout block and Store API.
• A captcha at checkout. Attackers often switch IP addresses; rate limiting and a captcha together work best.
• Your payment provider's fraud filters. Turn them on and see what they report.
• 3-D Secure, the extra confirmation in the banking app, makes misuse of stolen cards harder.

What your host does, and what it doesn't

Arranged by WebOké:

• A free Let's Encrypt certificate for https
• HSTS is enabled by default on most servers
• The Web Application Firewall is enabled by default and blocks known attacks
• Imunify360 checks new files for malware immediately and scans your package regularly
• A backup of your entire package every night, kept for 30 days, in a different data centre

Remains up to you (or your web builder):

• Updating WordPress, WooCommerce, theme and plugins (Installatron can do this automatically, see Updates and automatic updates)
• The integration and fraud settings with your payment provider
• Which scripts appear on your checkout page
• Strong passwords and two-factor authentication for administrators
• Rate limiting, captcha and reviewing suspicious orders

Software you install yourself, even via Installatron, is managed by you. If your site gets hacked anyway, follow the step-by-step plan My website has been hacked: step-by-step plan. If a breach affects customers' personal data, also read Is this a data breach and do I have to report it?

Further reading

• Free course Safe online, lesson 4.2 Your website: https, HSTS and security headers
• PCI Security Standards Council on SAQ A (English)
• WooCommerce on card testing and rate limiting (English)