Accepting Card Payments on a Website: PCI DSS Basics

What PCI DSS is and who it applies to

PCI DSS is a security standard maintained by the PCI Security Standards Council (PCI SSC), founded by the major card brands. The Council's guidance for merchants says it is intended for all entities involved in payment processing, "including merchants, regardless of their size or transaction volume".

The Council writes the standard, but it does not enforce it. Each card brand runs its own compliance programme, and whether a small merchant has to validate compliance, and how, is set by the card brands. In practice you find out from your acquirer (the merchant bank) or your payment provider, which will usually ask you to confirm compliance once a year.

Three ways to take card payments

• Redirect (hosted payment page). The customer clicks "Pay" and is sent to a page run by the payment provider, then returned to your site. Your site never sees the card number.
• Embedded form (iframe). The card fields sit on your checkout page, but they are delivered inside an iframe by the payment provider. The customer stays on your page visually, but the card details go straight to the provider.
• Your own form (direct post or direct API). Your website builds the payment form itself and sends the card data to the provider, or your server receives the card data and passes it on.

The PCI SSC explains the key difference in its FAQ 1291: with a redirect or iframe "the third-party payment processor produces the webpage that accepts payment data", while in a direct post set-up "the merchant website produces some or all of the web page that is used to accept payment data".

Which self-assessment questionnaire fits

Smaller merchants usually confirm compliance with a Self-Assessment Questionnaire (SAQ). The Council describes several SAQs, each for a specific type of set-up with its own eligibility criteria. For websites, three matter most:

• SAQ A is for merchants whose card data functions are completely outsourced to PCI DSS validated and compliant third parties. FAQ 1291 sets the condition for e-commerce: all elements of the payment page delivered to the customer's browser come "only and directly" from a PCI DSS validated third-party service provider. Redirects and iframes from your provider are the usual route.
• SAQ A-EP is for e-commerce merchants whose website does not receive card data itself but produces some or all of the payment page, as in a direct post set-up. Each element of the payment page must come from either your website or a PCI DSS compliant service provider. It has more requirements than SAQ A, because your website now affects the security of the payment.
• SAQ D is the full questionnaire for merchants who do not fit a shorter SAQ, for example when card data passes through their own servers. Stripe's integration security guide warns that a business handling card data directly "might be required to meet more than 300 security controls in PCI DSS".

The choice of integration is therefore the biggest decision. Unless you have a strong reason to handle card data yourself, a redirect or a provider's embedded fields keep the scope, and the cost of compliance, as small as possible.

PCI DSS v4: what changed for websites

PCI DSS v4.0 was published in March 2022, and v3.2.1 was retired on 31 March 2024, as the Council explains in its post on the future-dated requirements of PCI DSS v4.x. The same post says 51 of the 64 new requirements were future-dated and became effective on 31 March 2025. PCI DSS v4.0.1, published in June 2024, was a limited revision with no added or deleted requirements, and it is the version featured in the Council's document library.

Two of the new requirements target online checkouts directly: 6.4.3, which covers managing the scripts on payment pages, and 11.6.1, which covers detecting unauthorised changes to payment pages. These answer a common type of attack where malicious code on a checkout page copies card details as they are typed.

For SAQ A merchants, the Council announced changes in January 2025: requirements 6.4.3 and 11.6.1 were removed from SAQ A, and a new eligibility criterion was added instead. The merchant must confirm "their site is not susceptible to attacks from scripts that could affect the merchant's e-commerce system(s)". The updated SAQ A took effect on 31 March 2025. In plain terms, even with a redirect or iframe, the page that sends customers to the payment form still needs protecting, because altering it can send them to a fake form.

What your payment provider covers, and what it does not

Payment providers carry most of the burden, but not all of it. Stripe's integration security guide is a clear example. It calls PCI compliance "a shared responsibility": Stripe is certified every year as a PCI Level 1 Service Provider, while "as a business accepting payments, you must do so in a PCI-compliant manner, and annually attest to this compliance".

What stays with you, whichever provider you use:

• keeping the website, its plugins and its hosting patched and secured, since the checkout page lives there;
• serving the whole site over HTTPS; Stripe's guide asks for TLS 1.2 or above;
• controlling who can change the site and the scripts it loads;
• never storing full card numbers or security codes in your own systems, emails or spreadsheets;
• completing the provider's yearly compliance confirmation.

Stripe also notes that non-sensitive details it returns, such as the card type, the last four digits and the expiry date, are not subject to PCI compliance and can be stored for receipts and customer service.

Strong Customer Authentication and 3-D Secure

In the European Economic Area, the PSD2 regulation adds Strong Customer Authentication (SCA). Stripe's SCA guide says the rule has been in effect since 14 September 2019, that card payments use 3D Secure to meet it, and that customers' banks might decline payments that do not follow it. In practice the customer may be asked to confirm a payment in their banking app or with a code. Some low-risk payments can be exempt, but the bank decides, so the checkout must handle the extra step when it is requested. Modern provider checkouts and payment forms handle this for you; older custom integrations may need updating.

A practical checklist

• Choose a hosted payment page or the provider's embedded fields unless you have a clear reason not to.
• Ask your provider or acquirer which SAQ applies to your integration, and complete it every year.
• Keep the site, theme, plugins and server updated, and remove scripts the checkout does not need.
• Use HTTPS everywhere and strong, unique logins with two-factor authentication for anyone who can change the site.
• Test payments end to end, including 3-D Secure, failed payments and refunds, using the provider's test mode before launch.
• Never ask customers to send card details by email or chat.

Choosing a platform first? Our comparison of Shopify and WooCommerce covers how each handles payments, and our guide to website security basics covers keeping the site itself safe. Before opening a shop, run through our e-commerce launch checklist.

Frequently asked questions

Does PCI DSS apply to a small online shop?

Yes. The PCI Security Standards Council says PCI DSS is intended for all entities involved in payment processing, including merchants of any size or transaction volume. How you validate compliance is set by the card brands, so ask your acquirer or payment provider.

What is the difference between SAQ A and SAQ A-EP?

SAQ A fits when every element of the payment page comes only and directly from a PCI DSS validated provider, as with a redirect or the provider's iframe. SAQ A-EP fits when your own website produces some or all of the payment page, as in a direct post set-up, and it has more requirements.

If I use Stripe, PayPal or another provider, am I automatically compliant?

No. The provider secures its own systems, but you must still accept payments in a compliant way, protect the website that leads to the checkout, and confirm compliance each year, usually with a self-assessment questionnaire.

Can I store customers' card numbers?

Avoid it. Let the payment provider store cards and give you a reusable token. Details such as the card type, last four digits and expiry date are not sensitive under PCI DSS and can be kept for receipts.

What is 3-D Secure?

It is the card authentication step, often a confirmation in the customer's banking app, that payment providers use to meet Strong Customer Authentication rules for customers in the European Economic Area. Banks may decline payments that need it and do not complete it.

Planning an online shop or a checkout? See how we approach website development and web application development, see all our services, or email info@creahive.com.