- PCI DSS v4.0.1 has been the only active version of the standard since PCI DSS v4.0 was retired on 31 December 2024.
- The cheapest way to comply is to keep raw card data out of your own systems with tokenised payments, hosted payment fields or P2PE terminals.
- Stripe notes that handling card data directly can mean meeting more than 300 PCI DSS security controls.
- Your POS can safely store non-sensitive details such as card brand, last four digits and expiry date returned by the provider.
- Every business that accepts cards still has PCI duties, including an annual attestation; your payment provider tells you which form applies.
How does PCI DSS apply to a custom POS or checkout?
Any system that accepts payment cards falls under PCI DSS, but a well-designed custom POS or checkout keeps raw card data out of your own code, servers and database, so most of the standard's controls never apply to you. Your developer achieves this with the payment provider's certified terminals, point-to-point encryption, hosted payment fields and tokens. Your system only ever sees a payment result and a reference. That design decision, made early, saves far more effort than any amount of security work later.
This guide explains the main ideas in plain terms. It is not legal or compliance advice: your bank, payment provider or a qualified assessor confirms what your business needs.
What is PCI DSS, and which version applies now?
The Payment Card Industry Data Security Standard is a set of security requirements for anyone who stores, processes or transmits cardholder data. It is managed by the PCI Security Standards Council. According to the PCI SSC's announcement of v4.0.1, PCI DSS v4.0 was retired on 31 December 2024, leaving v4.0.1 as the only active version, and the new requirements introduced in version 4 took effect on 31 March 2025.
Why is scope the most important idea?
PCI DSS applies to the systems that touch card data, plus anything connected to them. That set of systems is called your scope. The more systems in scope, the more controls you must meet, test and document. Stripe's integration security guide notes that a business handling sensitive card data directly might be required to meet more than 300 security controls. Keeping card data out of your systems shrinks that work dramatically.
How do you keep card data out of an in-store POS?
- Use your payment provider's certified terminals. The customer taps or inserts the card on the terminal, and the card data goes to the provider, not through your POS software.
- Prefer point-to-point encryption. The PCI SSC P2PE page explains that a P2PE solution encrypts card data from the moment it is captured until it reaches the provider's secure decryption environment, and that merchants using PCI-listed P2PE solutions have fewer PCI DSS requirements to meet.
- Integrate with the terminal through the provider's API or SDK. Your POS sends an amount and receives an approved or declined result with a reference.
- Never key card numbers into your own screens, for example for phone orders. Use the provider's virtual terminal or payment links instead.
How do you keep card data out of an online checkout?
For online payments, use the provider's hosted checkout page or hosted payment fields, which load card inputs from the provider inside your page. The card details go straight from the customer's browser to the provider, and your server receives a token. Avoid building your own card number form that posts to your server: that puts your whole application in scope. Our ecommerce development team builds checkouts this way by default.
What can your POS safely store?
Stripe's guide states that non-sensitive card details returned by the provider, namely the card type, the last four digits and the expiry date, are not subject to PCI compliance and can be stored in your database. That is enough to show customers which card they used, handle refunds through the provider and match transactions in reports. Full card numbers, security codes and magnetic stripe or chip data must never be stored by your system.
| Data | Store in your POS? |
|---|---|
| Payment reference or token from the provider | Yes |
| Card brand, last four digits, expiry date | Yes |
| Full card number | No: leave it with the provider |
| Security code (CVC) | Never |
| Chip or magnetic stripe data, PIN | Never |
What must your developer handle?
- Choose the integration that keeps scope smallest: certified terminals, P2PE where available, hosted checkout or hosted fields online.
- Use TLS everywhere. Stripe's guide asks for TLS 1.2 or above on payment pages and HTTPS for all calls to its API.
- Verify webhook signatures, so payment notifications are known to come from the provider.
- Keep secret API keys on the server, restricted and rotated, never in the POS front end or app.
- Limit and log access to admin areas, refunds and reports.
- Control third-party scripts on payment pages, because each one could change what customers see.
- Keep software and dependencies updated, and document how payments flow for your compliance paperwork.
What is still your responsibility as the business?
Even with a low-risk integration, compliance remains a shared responsibility. Stripe states that businesses accepting payments must do so in a PCI-compliant manner and attest to compliance every year. Your payment provider or acquiring bank tells you which validation form applies, often a self-assessment questionnaire for smaller merchants. You also control the human side: who can issue refunds, how devices are secured, and how staff are trained to spot tampered terminals. Our maintenance and security plans keep the technical side current.
What about older POS software?
Older systems sometimes captured card data through the POS computer itself, using card readers plugged into the till. If your current system does this, your whole shop network may be in scope. The PCI Security Standards Council has retired its older Payment Application Data Security Standard (PA-DSS), so it is worth reviewing older software that relied on it. Moving to provider-integrated terminals is often the biggest compliance win available when replacing an older POS.
How should you plan payments in a new POS project?
Choose the payment provider early, check which terminals and countries it supports, and design the POS around its integration. Then confirm with the provider which validation your business will need. If you are still comparing developers, our list of questions to ask a POS development company covers payments alongside offline mode, hardware and ownership. If you are building a new system, our POS system development team designs the payment flow with scope reduction as a requirement from day one.
Frequently asked questions
Is my business PCI compliant if I use Stripe or another payment provider?
Using a compliant provider helps a lot, but it does not remove your duties. Stripe describes compliance as a shared responsibility: the provider is certified, and your business must accept payments in a compliant way and attest to it every year. A good integration keeps your part small, but you still complete the paperwork your provider or bank asks for.
Can my POS store card numbers for repeat customers?
Not the full card number in your own database. Use your payment provider's tokens or saved payment methods instead: the provider stores the card and gives you a reference you can charge later. Your system can keep non-sensitive details, such as card brand and last four digits, to help customers recognise their saved card.
What is a QSA and do I need one?
A Qualified Security Assessor is an independent assessor approved by the PCI Security Standards Council to evaluate compliance. Large merchants and service providers often need a formal assessment by a QSA, while many smaller merchants complete a self-assessment questionnaire instead. Your bank or payment provider tells you which applies to your business.
Does PCI DSS apply to phone and email orders?
Yes. Card details taken over the phone or by email are still card data. Avoid writing card numbers down or receiving them by email. Take phone payments through your provider's virtual terminal or a payment link, so the details go straight to the provider rather than into your own notes or systems.
Is PCI DSS a law?
PCI DSS is an industry standard created by the major card brands and managed by the PCI Security Standards Council, not a government law. It is enforced through your agreement with your bank and payment provider, which can include fines or losing the ability to take cards. Separate data protection laws may also apply to a breach.
Last updated