Payments, and what you should never store yourself

A small business taking payments through its website should, in nearly every ordinary case, never see, handle or store a customer’s full card number, expiry date or security code directly. This is not merely good practice — it is the specific problem a payment gateway exists to solve, and building a form that captures raw card details itself defeats the entire point of using one.

Why cardholder data is a genuinely different category from other data

A name, an email address, an enquiry message — all of these are ordinary business data, handled under the general privacy obligations covered elsewhere on this site. Payment card details, also called cardholder data, sit under a separate, specific compliance framework: PCI DSS, the Payment Card Industry Data Security Standard. PCI DSS is imposed by the card networks themselves rather than by government regulation, and it applies to any business handling card data or cardholder data regardless of size. Meeting the PCI DSS standard directly is a significant, ongoing technical and administrative undertaking that essentially no small business genuinely needs to take on.

How a payment gateway avoids touching card details or credit card numbers at all

A payment gateway is the service that actually processes a credit card transaction, integrated into checkout — whether that is Stripe, Square, PayPal or a similar provider. It takes the credit card details directly from the customer’s browser to the gateway’s own secure systems, never routing them through the business’s own server or database at all. Done correctly, the business’s website never touches the raw card number or credit card number. That removes it from the scope of the PCI compliance burden almost entirely, because it was never holding the sensitive cardholder data in the first place.

The mistake that reintroduces the risk: transferring card data through your own server

Building a custom form that collects card details and submits them to the business’s own server, intending to forward them on to a processor from there, reintroduces exactly the exposure a proper gateway integration avoids. The business’s own server has now handled raw card data. It inherits the associated compliance obligation, along with the risk of that data being exposed if the server is ever compromised. This mistake is more common with a custom-built checkout than with an established platform’s own tested payment integration. That is one of the genuine, if rarely stated, advantages of using a well-established commerce platform’s built-in checkout rather than building one from scratch.

What a business can legitimately store instead of payment card numbers: tokenisation, not stored credit cards

An order record — what was purchased, the amount, the customer’s name and delivery details — without the underlying card number. Many gateways provide a token, a reference standing in for a stored card for the purpose of a future recurring charge, which is not the same as the card itself and is generally the correct and compliant way to support “save my card for next time” without the business ever holding the actual number.

What to check on an existing site

Whether the checkout process sends card data directly to the payment gateway from the customer’s browser, or routes it through the business’s own server at any point. If a developer cannot answer this clearly, it is worth having someone qualified confirm it directly — this specific point is where the entire risk profile is decided. Also worth checking: whether the platform or plugin used for payments is current and still receiving updates. A vulnerability in a badly maintained payment plugin is a more attractive target than almost anything else on a small-business site.

Why “we’ve always done it this way” is not a defence

A business that has run a custom payment form for years without incident has not necessarily avoided the risk described above. It may simply not have been targeted yet, which is a different claim from being secure. The absence of a past incident is not evidence of a sound architecture. It is worth reviewing an existing checkout specifically against this page’s question, regardless of how long it has run without a visible problem.

PCI DSS compliance levels, briefly

The specific compliance obligations under the Payment Card Industry Data Security Standard scale with transaction volume, and a small business processing payments entirely through a proper gateway integration — never touching raw card data — sits at the lightest end of that scale, generally satisfied by an annual self-assessment questionnaire rather than a full external audit. This is a further, concrete reason routing all payment data through a gateway matters: it is what keeps a small business in the lightest compliance tier rather than a heavier one.

What to ask a developer proposing a custom checkout

Whether the proposed build sends card data directly from the customer’s browser to the gateway, or whether it passes through the business’s own server at any point — and if the answer is unclear or evasive, that uncertainty is itself the signal to get independent technical confirmation before launch, not after.

Recurring payments and stored cards, briefly

Where customers can save a card for future purchases, confirming the platform uses the gateway’s own tokenisation rather than storing card details in the site’s own database is the same principle applied to a slightly different feature — the token stands in for the card, and the actual number never sits anywhere the business controls.

The one-sentence version of this entire page

If a developer ever proposes a way to make card payments work without a proper gateway integration, that is the moment to say no, regardless of how the workaround is framed.

Where to go from here

The wider ecommerce build decisions this connects to are covered on ecommerce website design. And the general software-maintenance discipline that keeps a payment integration itself current is the same one covered in software updates and website security.