Payment security: hold less, lose less.

The principle that matters most

Almost every payment security discussion starts with tools. It should start with scope.

Data you do not hold cannot be stolen from you. A business that stores no card numbers, processes through a hosted checkout, and keeps tokens rather than card data has dramatically less exposure than one running the same volume through systems that touch raw card data, regardless of how good either one's firewall is.

Every decision below is downstream of that principle.

Tokenization and encryption

These two are frequently confused and do different jobs.

Encryption scrambles card data so it cannot be read in transit or at rest. Point-to-point encryption at the terminal means data is encrypted at the read head, before it reaches your network at all.

Tokenization replaces the card number entirely with a substitute value that has no mathematical relationship to the original. A token is useless outside your specific merchant account, so a stolen token cannot be used anywhere else. This is what makes stored customers and recurring billing safe: you store a token, not a card.

Used together, card data is unreadable in transit and absent from storage.

Practical controls for a small business

None of these require a security team.

What never to store

Some data is prohibited outright after authorization, and storing it is both a violation and a serious liability. Never retain the security code from the back of the card, the full magnetic stripe or chip data, or the PIN. There is no legitimate business reason to keep any of them once the transaction is authorized.

Beyond the prohibited list, apply a simple test to everything else: if you cannot name a specific operational reason you need it, delete it. Old spreadsheets of card numbers, email records with card details, and paper order forms in a drawer are pure liability with no offsetting value.

Staff and process

Most incidents at small businesses are not sophisticated. They are a phone call.

Train staff that nobody from your processor or your bank will ever call and ask for full card numbers, passwords, or remote access to a terminal. Establish that unexpected requests get verified on a known number, not the one the caller provides. Do not take card details by email or text, and if a customer sends them anyway, delete the message after processing rather than leaving it in the mailbox.

And decide in advance who to call if something looks wrong. An incident at 6pm on a Friday is not the moment to work out the escalation path.

If something happens

Contain first: disconnect the affected system rather than continuing to trade on it. Call your processor and your acquiring bank immediately, because they have obligations and procedures that start from the moment they are notified. Preserve evidence rather than wiping and reinstalling, which destroys the information needed to understand scope. And expect a forensic investigation if card data was genuinely exposed.

The cost of an incident scales almost directly with how much data was available to take, which brings this back to the first principle: the best position to be in is one where a breach of your systems yields nothing usable.

Common questions