Ecommerce Payment Security Best Practices
Your checkout is the highest-stakes security environment in your entire store. It is where your customers trust you most completely - entering their card details, sharing their billing address, completing a financial transaction. It is also where attackers focus most of their effort. Card skimming scripts sit silently on checkout pages. Payment flows are probed for injection vulnerabilities. Misconfigured payment integrations leak data through insecure connections.
Payment security ecommerce best practices are the controls that protect this environment - and they matter both practically (preventing actual fraud and data exposure) and contractually (PCI DSS compliance is a requirement of accepting card payments, not an optional enhancement). This guide explains what you actually need to do, why it matters, and how to verify that your store meets the standard.
Note: This guide provides practical guidance for ecommerce store owners. It does not constitute legal or compliance advice. For your specific PCI DSS compliance obligations, consult a Qualified Security Assessor or your payment processor.
See it in action
Want to automate this for your store?
VortexIQ's AI agents can audit, fix, and monitor your ecommerce store automatically.
Payment security is one piece of the full security framework - see the Ecommerce Security & Compliance Complete Guide for the complete picture.
In This Guide
Why Payment Security Has Two Distinct Dimensions
Understanding payment security means understanding that it operates across two distinct frameworks that overlap but are not the same.
Contractual compliance (PCI DSS): The Payment Card Industry Data Security Standard is a contractual requirement set by card networks. Meeting it is not optional if you accept card payments - it is a condition of your merchant agreement. Non-compliance does not trigger regulatory fines automatically, but it creates liability: if a breach occurs and you were non-compliant, your payment processor can impose fines, require expensive forensic audits, and potentially suspend your card acceptance privileges.
Practical security: The actual controls that prevent card data from being stolen, checkout pages from being compromised, and payment flows from being exploited. PCI DSS compliance and practical security overlap significantly, but not completely - you can meet the PCI SAQ requirements for your merchant tier while still having a checkout page that loads a compromised third-party script, for example.
Both dimensions require attention. The goal is not just to tick the compliance box but to actually protect your customers' payment data.
PCI DSS for Ecommerce: What It Actually Requires of You
PCI DSS is a detailed technical standard covering twelve requirement areas: network security, default credential management, cardholder data protection, data transmission security, malware protection, secure systems, access restriction, authentication, physical security, monitoring, security testing, and information security policy.
The full standard is written for organisations that handle card data directly at scale. Most ecommerce stores do not handle card data directly - they use payment gateways and hosted payment solutions that do. The PCI framework accounts for this through the Self-Assessment Questionnaire (SAQ) system.
Which SAQ Applies to Your Store
The SAQ you need to complete depends on how your store handles card data:
SAQ A: For stores where card data entry is entirely handled by a third-party payment processor and never touches the merchant's systems. This applies to most stores using hosted payment pages from Shopify Payments, Stripe Checkout, or PayPal. SAQ A has the smallest number of requirements and is the most common for small to mid-sized ecommerce stores.
SAQ A-EP: For stores that use a payment page hosted by a third party but also have custom JavaScript or iFrames on the payment page that could affect the payment data flow. More requirements than SAQ A.
SAQ D: For merchants that store, process, or transmit card data directly. This is the most comprehensive SAQ and applies to stores that handle card data without fully delegating it to a hosted payment provider. Very few ecommerce stores should be in this category.
SAQ Type Applies When Scope Typical Store Setup SAQ A Card entry entirely handled by third-party processor; never touches merchant systems Most limited Shopify Payments, Stripe Checkout, PayPal hosted checkout SAQ A-EP Third-party hosted payment page, but merchant has custom JS or iFrames on payment page Moderate Custom checkout modifications with embedded hosted fields SAQ D Merchant stores, processes, or transmits card data directly Most comprehensive Custom payment integrations handling raw card data
If you are uncertain which SAQ applies to your setup, contact your acquiring bank or payment processor directly - they can confirm your merchant tier and applicable SAQ based on your payment integration.
Completing the SAQ
The SAQ is an annual self-assessment - a questionnaire where you confirm your compliance with each applicable requirement. For SAQ A, the requirements are relatively limited: confirm that you do not store card data, that your connection to the payment processor is secure, and that you have basic security practices in place. Your payment processor typically provides the SAQ through their merchant portal. The PCI Security Standards Council maintains the complete SAQ documentation and self-assessment resources.
Completing the SAQ is not optional if you accept card payments. Many small stores do not know they are required to complete it because payment processors do not always actively enforce SAQ submission from small merchants. Non-completion increases your liability exposure in the event of a breach.
The Single Most Effective Payment Security Decision
Use a hosted payment solution from a PCI DSS Level 1 certified provider and keep card data off your systems entirely.
When a customer enters their card details into a checkout form powered by Shopify Payments, Stripe Elements, or PayPal's hosted checkout, the card data is encrypted and transmitted directly to the payment processor's PCI-certified environment. It never passes through your server. It is never stored in your database. It is never accessible to your code.
This architecture - called a hosted payment page or embedded hosted fields - limits your PCI scope dramatically. Your obligation is to maintain the security of the environment surrounding the checkout, not the checkout itself. You are SAQ A, not SAQ D.
The practical implication: if anyone in your organisation is discussing building a custom payment form that touches card numbers directly, or using a payment integration that requires card data to pass through your server before being forwarded to a processor, the answer should be no. The incremental control you gain is not worth the compliance liability and security risk you take on.
Secure Checkout Best Practices
HTTPS Everywhere - Including Staging
HTTPS encrypts the connection between the customer's browser and your server, protecting data in transit from interception. All pages of your store should use HTTPS - not just the checkout, but your homepage, product pages, account pages, and any other page a customer session might touch.
Where stores commonly have gaps: custom subdomains configured without HTTPS, staging or preview environments running on HTTP, and pages that serve mixed content (HTTPS page loading HTTP resources). A mixed content warning in the browser signals to customers that the connection is not fully secure - and it is a genuine security gap.
Check every environment: your production store, any staging environments, admin subdomains, and any subdomain used for custom apps or integrations.
Content Security Policy on Your Checkout Page
A Content Security Policy (CSP) header instructs the browser to only execute scripts from sources you have explicitly authorised. On your checkout page, this means an attacker who manages to inject a malicious script - through a compromised third-party tag or a code injection vulnerability - cannot execute it if it originates from a domain you have not whitelisted.
Implementing a strict CSP on your checkout page is one of the most effective defences against Magecart-style card skimming attacks. It requires careful configuration - an overly restrictive CSP will break legitimate checkout functionality - but the investment is worth it for any store running a self-hosted or significantly customised checkout.
Shopify and BigCommerce manage their hosted checkout pages' security headers; the risk area for stores on these platforms is custom third-party scripts loaded on the checkout page through tag management systems or custom code blocks.
Third-Party Script Audit
Every third-party script that loads on your checkout page has the theoretical capability to read form fields - including card number entry fields - and transmit data to external servers. Magecart attacks exploit this by injecting malicious scripts that do exactly this.
Run a regular audit of what scripts load on your checkout:
- Open your checkout page in a browser with developer tools
- Check the Network tab for every external resource that loads
- Verify the source and legitimacy of each script
- Remove any script that does not have a clear business justification for being on your checkout page
- Document the approved script list and review it whenever you add or remove any third-party tool
This audit should be on your regular security review schedule - at minimum quarterly, and immediately before and after any changes to your tag management or checkout configuration.
3D Secure Implementation
3D Secure (3DS2 is the current version) is the additional authentication step at checkout - typically a one-time code sent to the customer's phone or a biometric confirmation through their banking app - that verifies the cardholder's identity during the transaction.
For merchants, 3DS has a direct financial benefit: transactions authenticated via 3DS shift chargeback liability from the merchant to the card issuer in most cases. If a fraudulent transaction completes with 3DS authentication, the liability for the chargeback is the issuer's problem, not yours.
The practical trade-off is checkout friction: 3DS adds a step to the payment process that some customers abandon. The optimal configuration is risk-based 3DS - enabling it selectively for high-risk transactions (high-value orders, new customers with no purchase history, orders with mismatched billing and shipping addresses, international orders to high-risk destinations) rather than for every transaction.
Most payment processors and checkout platforms support risk-based 3DS configuration. Review your payment processor's documentation for the specific implementation in your platform.
No Card Data Storage, Anywhere
This bears repeating because violations are common and costly. No card data - not the full card number, not the CVV, not the full expiry date - should ever be stored anywhere in your systems. Not in your database, not in a log file, not in a customer support ticket, not in a spreadsheet.
The only exception is a truncated card number (typically the last four digits), which is not subject to PCI storage restrictions and is useful for customer service purposes (confirming which card was used for an order).
If your current systems or processes involve storing card data in any form, this needs to be addressed as a priority before your next PCI SAQ completion.
Testing Payment Security Before Going Live
One of the most overlooked payment security practices is proper testing before deploying changes to production.
Changes that should always be tested before production deployment:
- Platform or theme updates that touch checkout functionality
- Changes to payment gateway integration settings
- New third-party scripts or tag manager changes that affect the checkout page
- Security patch deployments to self-hosted platforms
- Changes to fraud detection rules or payment velocity settings
Testing payment security in a staging environment means verifying that:
- The checkout still functions correctly end-to-end
- No card data is inadvertently captured or logged by the changed code
- 3DS is still triggering correctly for the configured risk rules
- Third-party scripts are loading from their expected sources
- No new external resources have been introduced by the changes
Vortex Staging (for Shopify) and StagingPro (for BigCommerce) provide the staging environment for this workflow. Security patches and payment integration changes should be validated in staging before production deployment - discovering a checkout-breaking issue in production during peak trading is significantly more damaging than catching it in a staging test.
What Happens When Payment Security Fails
Understanding the cost of payment security failure helps calibrate how much investment the controls justify.
Direct fraud liability: For card-not-present fraud on transactions without 3DS authentication, the merchant typically bears the chargeback cost: the transaction value reversed plus the chargeback fee (£15-£25 per dispute in the UK, higher for international transactions). At sustained fraud rates, this is a direct revenue impact.
PCI non-compliance fines: If a breach occurs and forensic investigation reveals you were non-compliant with PCI DSS requirements, your acquiring bank can impose fines ranging from $5,000 to $100,000 per month. These are contractual penalties, not regulatory fines. The fine level depends on the duration and severity of non-compliance.
Forensic investigation costs: A confirmed payment data breach typically triggers a mandatory PCI Forensic Investigation (PFI) - an independent forensic audit of your systems. PFI costs range from $10,000 to $100,000+ depending on the scope of the investigation.
Card brand fines: Visa and Mastercard can impose direct fines on acquiring banks, which are typically passed through to the merchant. These can reach $500,000 for significant breaches.
Reputational damage and customer attrition: The less quantifiable but often most significant cost. A payment breach disclosed publicly loses customers who may never return - the trust destroyed by a payment data incident is difficult to rebuild.
The cost-benefit analysis for payment security investment is straightforward: the controls described in this guide cost significantly less than any of these consequences.
Frequently Asked Questions
Do I need to be PCI compliant if I use a payment processor like Stripe or Shopify Payments?
Yes - all merchants that accept card payments are required to be PCI DSS compliant. However, using a hosted payment solution (Stripe, Shopify Payments, PayPal hosted checkout) significantly reduces your compliance scope. When card data never touches your systems, most of the PCI DSS technical requirements apply to the payment processor rather than you. Your obligation is typically completing SAQ A annually and maintaining the security of your store environment.
What is the difference between PCI DSS and GDPR for payment data?
PCI DSS governs how payment card data specifically is stored, processed, and transmitted - it is a contractual standard set by card networks (Visa, Mastercard). GDPR governs how all personal data (including but not limited to payment data) from EU/UK customers is collected, processed, stored, and shared - it is a legal regulation. Payment card data is subject to both: PCI DSS for the payment-specific requirements, and GDPR for the broader personal data obligations. Compliance with one does not guarantee compliance with the other.
How often should I audit the scripts on my checkout page?
Quarterly at minimum, and immediately following: any change to your tag management system, any update to a third-party app that runs scripts on your store, any theme update, or any change to your payment integration. The checkout script audit is one of the highest-value security practices for ecommerce stores on self-hosted platforms. For stores on Shopify or BigCommerce, the platform's own checkout page is managed by the platform - but any custom scripts you have added to your checkout template still need regular review.
What is 3D Secure and do I have to use it?
3D Secure is the additional authentication step at checkout that verifies the cardholder's identity (typically via a one-time code or biometric confirmation through their banking app). It is not mandatory in all regions, but it is strongly encouraged and in some markets required under regulations like PSD2 in the EU. The primary reason to implement it is liability shift: authenticated 3DS transactions move chargeback liability from the merchant to the card issuer. For high-value orders, international orders, and orders from new customers, 3DS is a practical fraud liability reduction tool.
What should I do if I think my checkout page has been compromised?
Take the checkout page offline immediately if possible - direct customers to a different payment method or temporarily suspend checkout - to limit additional card data exposure. Preserve logs and evidence. Contact your payment processor and acquiring bank immediately. Begin the process of identifying how the compromise occurred (review third-party scripts, recent code changes, access logs for the checkout configuration). Notify affected customers and your data protection authority (within 72 hours under GDPR) if card data has been exposed. Engage a PCI forensic investigator if required by your payment processor.
Related Articles
- Ecommerce Security & Compliance: Complete Guide
- Ecommerce Security 101: Threats Every Store Faces
- Fraud Prevention for Ecommerce: AI-Powered Detection
- GDPR Compliance for Ecommerce: What You Must Know
- Ecommerce Staging & Testing: Complete Guide
- Ecommerce Data Breach Response Plan
Ready to take action?
Run a Free AI Audit on Your Store
VortexIQ scans your ecommerce store across 85+ checks — SEO, performance, analytics, ads — and gives you a prioritised fix plan in under 30 seconds.