Card Payment Security Basics: What PCI DSS Means for You

Almost every fintech product, and a great many that are not fintech at all, eventually takes a card payment. The moment you do, a set of industry rules comes into view. They are written by the card brands, administered through the PCI Security Standards Council, and they go by the name PCI DSS, the Payment Card Industry Data Security Standard.

For a small team this can sound alarming. It does not need to be. The most important idea fits in one sentence: the less card data you touch, the less you have to protect. This guide explains the standard in plain words, shows the usual ways to keep your scope small and describes what to say, and not say, on a launch page. It is general information, not a compliance audit.

What the standard is

The PCI Security Standards Council describes itself as the body behind a family of standards for protecting payment data. Its website lists many of them: the Data Security Standard for organisations that handle card data, standards for payment software, for devices that read cards and for encryption of card data in transit, among others. PCI DSS is the one most small businesses meet first.

In broad terms, it sets security requirements for any organisation that stores, processes or transmits cardholder data, or that could affect the security of that data. The requirements cover things such as secure networks, protecting stored data, managing vulnerabilities, controlling access, monitoring and testing and having a security policy.

You do not set the standard and you cannot negotiate it. It is a condition of accepting cards, usually enforced through your payment provider or acquiring bank.

How much applies to you depends on how you take payments

The big variable is how card data reaches the provider.

Option one: redirect to a hosted payment page

The customer clicks pay and is sent to a page that belongs to the payment provider. They enter their card there, and your site never sees the number. This usually puts you in the lightest category of assessment.

Option two: hosted fields embedded in your page

Your page looks like your own, but the card number fields are served from the provider and are isolated from your code. The number goes straight to the provider. Your scope is still small, though your page's security matters because a compromised page could in principle interfere with how the fields are loaded.

Option three: your own form that sends card data to the provider

Now card data passes through your servers, even briefly. Your scope grows sharply. You will need more controls, more evidence and a more demanding assessment.

Option four: storing card data yourself

This is the heaviest path and one most small products should avoid. If you do not strictly need to store card numbers, do not.

For most launching products the sensible choice is option one or two. You get a smooth experience for customers and a far lighter load for yourself.

Reduce scope on purpose

Treat scope as something you design, not something that happens to you.

• Never log card numbers. Check that your error logs, analytics tools and support tickets cannot capture them. A customer pasting a card number into a support message is a real risk. Tell staff what to do if it happens.
• Keep payment code separate. The fewer systems near the payment flow, the smaller the area to secure.
• Use tokens. Providers give you a token that stands in for a card. You store the token, not the number.
• Check third-party scripts on your payment page. Every extra script is one more thing that could be compromised. Remove what you do not need.
• Keep the page and its dependencies updated.

Responsibilities do not vanish

Using a certified provider reduces your obligations but does not erase them. You are still responsible for your own site's security, for the way you configure the integration and for answering the provider's questionnaires truthfully. Providers typically ask you to confirm each year, in a self-assessment, how you handle card data. Treat that as a real exercise, not a box-ticking one.

Think of your provider as a key supplier. The UK's National Cyber Security Centre publishes guidance on supply chain security, which stresses understanding what your suppliers do, what you depend on them for and how you will know if something goes wrong. That applies to payment providers as much as to any other.

What to tell customers

On your launch page you want people to feel safe paying, without making claims you cannot support. Good wording:

• "Card payments are processed by [provider], which is certified to the card industry's security standard. Your card details are entered on their secure fields and never reach our servers."

Avoid:

• "We are fully PCI compliant" unless you hold the evidence for your own scope and can say what it covers.
• "Your card is 100 per cent safe."
• Displaying card brand or security logos you are not entitled to use.

If you cannot say something specific and true, say less. A short honest sentence beats a long vague one. And remember that advertising rules in many places expect claims that readers will take as objective to be backed by evidence.

Alongside card data: personal data

PCI DSS is about card data. It is not the whole of your security or privacy duties. Customer names, addresses and account details fall under data protection law, such as the UK GDPR and the Data Protection Act. The Information Commissioner's Office publishes guidance for organisations on their obligations. Keep your privacy notice accurate, collect only what you need and have a plan for breaches.

A step-by-step approach for a launching product

1. Decide how you will take payments and choose the hosted option unless you have a strong reason not to.
2. Read your provider's integration guide, especially the security notes.
3. Map where card data could appear: forms, logs, emails, support tools, analytics. Close each leak.
4. Complete the provider's assessment honestly and keep a copy.
5. Write the customer-facing wording from facts you can evidence.
6. Review once a year, and whenever you change how payments work.

If your situation is more complicated, such as taking payments by phone or storing cards for repeat billing, get advice from your provider or a qualified assessor early.

Common mistakes

• Building a custom card form because it looks nicer, without realising it increases scope.
• Pasting card numbers into support tools or chat.
• Logging full request bodies that include card fields.
• Adding a marketing script to the payment page.
• Claiming compliance without knowing what your obligation is.
• Ignoring annual confirmations from the provider.

What about other payment methods

Cards are not the only way to pay. Bank transfers, wallets and open banking payments have their own security models and rules. Whatever you offer, apply the same principle: let the specialist handle the sensitive step, keep your own systems out of the money path where possible and describe the arrangement honestly.

On this site

The privacy and terms pages explain how data is handled here, and the launches page shows how products describe themselves. If you want to ask about listing a payments product, the contact page reaches a person, and the submit page starts an entry.

A worked example: a subscription app

Picture a small app that charges a monthly subscription. The founders first sketch a custom checkout form because it matches their design. Then they list what that means: card numbers would pass through their servers, so their logging, backups, staff access and hosting would all fall into the assessment. They switch to the provider's embedded fields instead. The page still looks like theirs, the number goes straight to the provider and what their database stores is a token and the last four digits for display.

Their yearly paperwork shrinks, their risk shrinks and their launch page can say something modest and true: "Payments are handled by our certified provider; we never see or store your full card number." Notice what is missing: any boast. The calm sentence does more for trust than any logo.

Questions to ask your provider

Before you choose, ask your payment provider a few direct questions. Which integration options do you offer, and which one keeps card data off my systems? What assessment will you ask me to complete each year? What happens if I change my checkout page? How do I report a suspected incident, and what do you expect me to do in the first hour? What data do you send back to me, and can I limit it?

Good providers answer these clearly and in writing. Keep the answers with your security evidence, and revisit them whenever you change how you take payments.

The short version

PCI DSS is the card industry's security standard for anyone who handles card data. Choose a hosted payment page or hosted fields so card numbers never touch your systems, keep logs and support tools clean, complete your provider's assessment honestly and describe your setup in specific, true words. The less card data you touch, the less you have to guard.