Sigi Technologies
Hire Top Talent

GUIDE  ·  12-Minute Read

PCI Compliance for Ecommerce: What Founders Actually Need to Do

PCI compliance for ecommerce is the work of meeting the Payment Card Industry Data Security Standard (PCI DSS) on every system that stores, processes or transmits payment card data, then validating that each year to your acquiring bank. For most online stores the goal is not to pass a larger audit. It is to arrange the checkout so a card number never reaches a server you run, which puts you on the shortest self-assessment questionnaire. This guide covers the version in force, how the questionnaires differ, the payment page script rules that became mandatory in 2025, and how Sigi Technologies builds checkouts on Shopify and Stripe.

Book a consultationSee our work
Illustration of PCI scope shrinking, nested frames closing in on a single payment card

Recognized & reviewed on

The expensive mistake in a checkout build is letting a card number pass through code you wrote. The moment it does, your servers sit inside the cardholder data environment and yearly validation grows from a short questionnaire into most of the standard. The cheap path is deliberate: the card fields are served by the payment provider, your code only ever sees a token, and your remaining job is protecting the page around the payment form. Sigi Technologies builds checkouts that way, on Shopify for ZIVA and on Stripe for Busy Bean Coffee. Commercial scope for a store of that shape sits with Sigi’s e-commerce development practice.

What is PCI compliance for ecommerce?

PCI compliance for ecommerce is the continuing work of meeting PCI DSS on every system that stores, processes or transmits cardholder data, then reporting that annually to the acquirer or payment brand that asked for it. The standard is published by the PCI Security Standards Council, whose document library lists PCI DSS v4.0.1 as the current version. It is a contractual obligation imposed by the card brands through your acquirer, not a statute, which is why only your acquirer can settle your scope.

  • PCI DSS v4.0.1 is the version shown as current in the PCI Security Standards Council document library, and the version assessments are performed against today.
  • The 51 future-dated requirements introduced with PCI DSS v4 became mandatory on 31 March 2025, according to the PCI Security Standards Council.
  • Which self-assessment questionnaire you complete depends on how card data reaches your processor, not on how much you sell. Volume decides your merchant level, a separate question.
  • A checkout whose payment fields are served by the provider, with only a token in your database, keeps your servers outside the cardholder data environment.
  • A store embedding a provider’s payment form in an inline frame carries payment page script obligations that a store redirecting customers away does not, per the Council’s FAQ 1588 of 28 February 2025.
  • Scope is confirmed with your acquirer or a Qualified Security Assessor. Nothing here substitutes for that conversation.

Which version of PCI DSS applies now, and what changed in 2025?

PCI DSS v4.0 arrived with 64 new or updated requirements, most published as best practice with a later start date. The Council wrote in August 2024 that 51 of those requirements were future-dated and would take effect on 31 March 2025. That date has passed, so the grace period is gone and an assessor scores all of them. In a March 2025 briefing on e-commerce requirements effective after 31 March 2025, the Council singled out requirements 6.4.3 and 11.6.1 on payment page scripts. They apply to any entity processing card transactions through embedded inline frames, or through a web page that can affect the security of e-commerce payments.

Which self-assessment questionnaire will you have to complete?

A self-assessment questionnaire (SAQ) is the form a merchant fills in to report its own PCI DSS compliance, submitted with an attestation of compliance. The Council’s October 2024 bulletin on the SAQs for PCI DSS v4.0.1 calls them validation tools for SAQ-eligible merchants and service providers, tells merchants to confirm they meet all eligibility criteria before starting, and says entities should first contact the party the questionnaire will be submitted to. Nine questionnaires exist in the v4 set. Three of them decide the fate of an online store.

SAQ A: card capture is fully outsourced

SAQ A is the shortest path and the one worth designing toward. It is for card-not-present merchants who outsource all processing of account data to a compliant third-party provider, and whose own systems never receive a card number. A hosted checkout page, a redirect, or provider-delivered fields all point this way. Eligibility, not preference, decides it.

SAQ A-EP: your page controls the payment form

SAQ A-EP covers e-commerce merchants who outsource processing but whose own website delivers or controls the payment page. The classic trigger is a form you built that posts card details straight to the processor. Your server may never store the number, but your code decides how that page is assembled and where the data goes, so it is in scope. SAQ A-EP is far longer and pulls in most of the standard. Which side of the line you land on is an architecture decision, made once, early.

SAQ D: your systems touch the card number

If a card number reaches your application, your logs or your database, you are in the full standard. Stripe’s integration security guide puts the cost plainly: a business handling sensitive card data directly might have to meet more than 300 security controls, buy dedicated security software and hardware, and hire external auditors for the annual assessment.

How do you keep card data off your own servers?

A hosted payment field is an input rendered by the provider inside its own inline frame, so keystrokes go to the provider rather than your page. Stripe’s PCI compliance guide describes Checkout and Stripe Elements as using a hosted payment field for handling all payment card data, where the cardholder enters all sensitive payment information in a payment field that originates directly from Stripe’s PCI DSS-validated servers. It states the principle in one line: the simplest way for you to be PCI compliant is to never see, or have access to, card data. The Stripe Elements documentation says the library tokenizes sensitive payment details within an element without ever having them touch your server.

Tokenization is the substitution of a card number with a reference value that is useless to an attacker and meaningless outside the provider that issued it. Your database keeps the token. Stripe lists the card type, the last four digits and the expiration date as out-of-scope card data you can safely store. That is enough to render a saved-card list, retry a failed subscription charge and answer a support ticket. It is not enough to leak a card.

On a hosted platform the boundary moves further out. Shopify states it is certified Level 1 PCI DSS compliant, covering the store, its shopping cart and web hosting. Its February 2025 note on checkout compliance says PCI DSS v4 requirements are integrated in checkout with no additional merchant work required.

What did the 2025 payment page script rules change for embedded checkouts?

This is the part most PCI articles skip, and it bites founders who chose an embedded payment form. Requirement 6.4.3 says all payment page scripts loaded and executed in the consumer’s browser are managed so that each is confirmed as authorized, its integrity is assured, and an inventory of all scripts is maintained with written justification of why each is necessary. Requirement 11.6.1 says a change- and tamper-detection mechanism alerts personnel to unauthorized modification of the HTTP headers and the contents of payment pages as received by the consumer browser.

On 10 March 2025 the Council published an information supplement, Payment Page Security and Preventing E-Skimming, noting that scripts running in consumers’ browsers are now a significant target for attackers seeking to steal payment card data.

Then the Council changed how the shortest questionnaire handles this. On 30 January 2025 it announced updates to SAQ A that removed requirements 6.4.3 and 11.6.1, and the targeted risk analysis supporting 11.6.1. In their place came an eligibility criterion: the merchant has confirmed that their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce systems. That version took effect on 31 March 2025. It is easy to misread as a relaxation. It is not. FAQ 1588, published on 28 February 2025, sets out who it binds and how it is satisfied.

  • The criterion applies to e-commerce merchants whose web page includes a provider’s embedded payment page or form, such as an inline frame.
  • It does not apply to merchants who redirect the customer away to the provider, or who fully outsource payment functions. Choosing a redirect over an embedded frame removes this obligation.
  • An embedding merchant satisfies it either by deploying script protection of the kind described in requirements 6.4.3 and 11.6.1, or by obtaining confirmation from its compliant provider that the provider’s solution, correctly implemented, protects the payment page from script attacks.
  • The underlying requirements did not change. Only their treatment inside one questionnaire moved.

The engineering that follows is unglamorous and cheap if done early. Inventory every script on the page hosting the payment frame, write a reason for each, and delete the rest. Marketing tags are the usual offenders: an analytics pixel on a payment page is an authorized-script question you will have to answer.

Pin third-party scripts with subresource integrity and restrict origins with a content security policy matching the directives your provider publishes, which Stripe lists for Checkout, Stripe.js and Link. Then add tamper detection on the delivered page and its headers, with alerts going to somebody on call. If you are on a platform, ask for the written confirmation described in the Council’s FAQ guidance and keep it with your validation paperwork.

What card data can you store, and what must you never store?

The Council’s data storage guidance for merchants is unambiguous. Sensitive data on the magnetic stripe or chip must never be stored, and only the primary account number, expiration date, service code or cardholder name may be stored, with technical precautions for safe storage. It adds that requirement 3 of the standard applies only if cardholder data is stored, and that merchants who store none automatically provide stronger protection by eliminating a key target for data thieves. That last sentence is the whole strategy.

  • Never store the card verification value, the full magnetic stripe or chip data, or the PIN. These are sensitive authentication data and must not be retained after authorization.
  • Do not store the primary account number unless a documented business need survives challenge. Saved cards, subscriptions and refunds all work from a token.
  • Store the token, the card brand, the last four digits and the expiry, which Stripe classifies as out of scope for PCI compliance.
  • Keep card numbers out of logs, error reports, analytics payloads, support inboxes and call recordings. Log capture is the most common way a compliant checkout falls back into scope.

Do you need 3D Secure and strong customer authentication?

These are a separate regime from PCI DSS and are often confused with it. EMVCo describes EMV 3-D Secure as an e-commerce fraud prevention protocol enabling consumer authentication for card-not-present purchases without adding unnecessary friction to checkout, and lists v2.3.1.1 as the most recent published specification. In Europe it is how most merchants satisfy strong customer authentication. Commission Delegated Regulation (EU) 2018/389 requires authentication based on two or more elements categorized as knowledge, possession and inherence, applies from 14 September 2019, and adds dynamic linking so the authentication code is specific to the amount and payee, with any change to either invalidating it.

The regulation also grants exemptions that keep conversion up: low-value remote payments under EUR 30 in Article 16, transaction risk analysis in Article 18, trusted beneficiaries in Article 13, and secure corporate payment processes in Article 17. There is a price. Stripe’s guidance on strong customer authentication notes that payments authenticated through 3D Secure fall under the liability shift rule and a fraud dispute typically moves to the card issuer, but that when an exemption is applied and the payment is not authenticated, liability shift does not apply. Decide that trade explicitly. And note that authentication does nothing for PCI scope; it reduces fraud losses, not the cardholder data environment.

What does a compliant checkout cost to build?

Validation fees come from your acquirer, not the Council, so ask for its schedule rather than trusting a figure found online. The build is more predictable. As a planning estimate, a storefront with authentication, a provider-hosted checkout, subscription billing and a light admin sits in the $80k to $180k band. A multi-surface platform with connected accounts and split payouts sits in the $150k to $350k and above band. Both are consistent with Sigi’s guide to how much it costs to build a mobile app, and both are typical-scope figures, not a quote and not a number attached to a named client. Compliance work inside them is cheap if designed in, expensive if retrofitted.

In what order should you build a PCI-compliant checkout?

  1. Ask your acquirer which merchant level and questionnaire it expects, before choosing an integration. The Council tells merchants to confirm eligibility with the party the questionnaire goes to, and that answer changes the design.
  2. Pick the integration that keeps card fields out of your code: a provider-hosted page, a redirect, or provider-served fields in an inline frame. A redirect or hosted page also removes the script eligibility criterion.
  3. Store the token and the harmless descriptors only, and add a log scrubber so a card number cannot reach your logs by accident.
  4. Inventory the scripts on any page that can affect the payment page, justify each in writing, delete the rest, then add subresource integrity and a content security policy.
  5. Add change- and tamper-detection on the payment page and its HTTP headers with alerts going somewhere staffed, or get written confirmation that your provider covers it.
  6. Turn on 3D Secure where strong customer authentication applies, and test the authenticated, exempted and declined paths in an automated suite.
  7. Complete the questionnaire and attestation annually, and rerun the review whenever a payment method, tag manager or checkout surface is added.

Related reading

The platform decision underneath all of this is covered in Shopify vs custom e-commerce, and the two builds cited here are written up as the ZIVA Shopify fashion store case study and the Busy Bean Coffee platform case study. For multi-party money, see how Stripe Connect marketplace payouts work, the ServiPR services marketplace case study and how to build a multi-vendor marketplace. The wider product view of payments, licensing and onboarding is in how to build a fintech app, and the commercial pages are Sigi’s e-commerce industry practice and fintech industry practice. To scope a checkout, talk to Sigi.

Questions this guide answers

It reduces your obligations, it does not remove them. Stripe is certified annually as a PCI Level 1 service provider and Shopify states it is certified Level 1 PCI DSS compliant, covering the store, its shopping cart and web hosting. You still validate your own compliance each year to your acquirer, and you still answer for the page your checkout sits on.

SAQ A is for card-not-present merchants who outsource all processing of account data to a compliant provider and whose systems never receive card data. SAQ A-EP is for e-commerce merchants who outsource processing but whose own website delivers or controls the payment page. SAQ A-EP is far longer. Your acquirer confirms which one you are eligible for.

Yes, in effect. PCI SSC FAQ 1588, published 28 February 2025, says the SAQ A script eligibility criterion applies to merchants whose page embeds a provider payment form such as an inline frame, and not to merchants who redirect away or fully outsource. An embedding merchant either deploys the script controls itself or gets written confirmation from its provider.

You do not need to. Save the provider token instead, plus the card brand, last four digits and expiry, which Stripe classifies as out of scope for PCI compliance. The PCI Security Standards Council says sensitive data on the magnetic stripe or chip must never be stored, and that merchants storing no cardholder data eliminate a key target for data thieves.

PCI DSS is a card brand standard enforced through your contract with your acquiring bank, not a statute in most jurisdictions. That makes it no less binding: non-compliance is a contractual matter that can affect your ability to accept cards. Separate laws may also apply to the same data, so confirm your position with your acquirer or a Qualified Security Assessor.

Sigi Technologies builds checkouts that keep card data off the servers it writes, and holds no PCI certification or attestation of its own. On ZIVA, checkout runs on Shopify’s hosted flow. On Busy Bean Coffee, card data is tokenized by Stripe and never touches the client’s servers. On ServiPR, each provider connects its own Stripe account, so the marketplace never holds provider funds.