Why an Email Inbox Is the Wrong Place for Card Data
Email is convenient, and that is precisely the problem. A customer needs to pay an invoice, so they reply to your billing message with a friendly note and paste sixteen digits, an expiry date, and the three-digit code from the back of the card. It feels helpful. It feels efficient. In reality, that single message has just created a trail of sensitive payment data that you do not control and cannot fully delete.
Consider where a card number goes the moment it is sent. It exists on the sender’s device, on their mail provider’s servers, in their sent folder, on your mail provider’s servers, in your inbox, on your phone, in any desktop client that syncs the account, in server backups, and often in an archiving or spam-filtering tool that indexes message content for search. Every one of those locations is a copy. Forward the message to a colleague in accounts and you have doubled the copies. Take a screenshot for a shared drive and you have created another. Email was never designed as a secure transport channel for cardholder data, and no amount of careful filing changes that.
The compliance implications matter just as much as the technical ones. Under PCI DSS, any system that stores, processes, or transmits cardholder data falls within scope. A mailbox holding full card numbers, expiry dates, and security codes is a system holding cardholder data — even if nobody thought of it that way when the message arrived. That means your inbox, your backups, and your archiving tools may all need to be assessed, protected, and monitored accordingly. In practice, most merchants discover this only after a customer asks a pointed question or an auditor raises it during onboarding.
There is also a fraud dimension that is easy to overlook. Card-not-present transactions carry higher dispute risk by nature, and an email order gives a fraudster an easy channel: no card to inspect, no signature, no one to look them in the eye. Stolen card numbers are routinely tested through loosely controlled email ordering, and when a genuine cardholder later disputes the charge, a merchant working from a plain-text email has very little evidence to defend the transaction. Screening tools such as address verification and card security code checks only help if they were actually run at the time of the charge — and they usually are not when the number is simply recorded in a message thread and charged later.
The uncomfortable conclusion is that an email containing full card details should be treated as a security incident in progress, not as routine paperwork. The goal is never to store it more neatly. The goal is to get the data out of the message and into a controlled, encrypted, tokenized payment flow as quickly as possible — and then to stop it from arriving by email in the first place.
A Practical Workflow for Card Details That Arrive by Email
The first rule is the simplest and the hardest to enforce: never ask a customer to send card details by email. When a buyer offers, redirect them immediately to a safer route — a payment link, a hosted payment page, or a phone call where a staff member keys the number straight into a secure terminal while the customer is still on the line. A short line in your invoice templates and email signatures (“Please do not send card details by email; reply and we will send a secure payment link”) prevents more incidents than any cleanup process ever will.
When a card number does arrive anyway — and it will — the handling steps need to be reflexive. Do not forward the message. Do not print it. Do not copy the number into a spreadsheet, a CRM record, a notes app, or a chat thread. Do not take a screenshot or save an attachment. Instead, open a secure browser-based payment terminal on a trusted, up-to-date device and key the number directly into the payment form. Merchants often ask, Can I accept credit cards by phone or email securely? — the answer is yes, but only when the card data goes straight into a PCI-compliant terminal with encryption in transit and tokenization at rest, and never into an interim document where it can linger for months.
Once the payment screen is open, complete the safeguards in the same sitting. Run address verification and card security code checks so you have matched data to defend later, and use 3-D Secure where the issuer supports it to shift liability on eligible transactions. Tokenize the card rather than storing the number: if the customer will be charged again, save the token to a customer card vault and schedule charges from there, so the raw number is never retrievable by staff. Restrict who can key transactions, issue refunds, and void payments through role permissions, and rely on session timeouts so an unattended browser cannot become a data leak.
Then deal with the original message. Follow a written retention policy — ideally deleting or masking the card data as soon as the charge is confirmed, keeping only an order reference, the last four digits, and the authorization result. Log what was done and by whom so your audit trail is complete. If the message sat in a shared mailbox, confirm that every copy, including mobile syncs and forwarded duplicates, has been removed. Reviewing exportable audit logs monthly turns this from a one-off scramble into a controlled process, and it gives you evidence of diligence if a dispute or a compliance review ever lands on your desk.
Better Routes for the Same Order, and What They Look Like in Practice
The most durable fix is to remove the reason customers email card details in the first place. Most do it because it is the only option you have given them. A payment link sent by email or text solves this in seconds: the customer clicks a branded URL, enters their own card details on a secure hosted page, and receives an automatic receipt. Amounts can be locked, links can be set to expire or to single use, and job or invoice references travel with the payment so reconciliation stays clean. A hosted checkout or an invoice with its own payment page achieves the same result for larger or recurring billing, and neither requires a single digit to pass through your inbox.
Phone orders deserve their own workflow. In a typical B2B scenario, a wholesale buyer emails a purchase order and adds “card details below.” Rather than copying that block into an order system, a staff member calls the buyer, keys the number directly into a virtual terminal while capturing the PO number, and emails a receipt. If the order is part-paid, the same invoice reference tracks the balance so receivables clear line by line. For repeat trade customers, a saved card in a secure vault turns a monthly phone call into a scheduled charge with no card data changing hands at all.
Consumer-facing businesses see the same pattern with deposits and balances. A homeowner emails a deposit for a booked job, a customer emails card details to settle a final invoice, a sponsor emails payment for an event. In each case the safe path is identical: send a payment link, or key the card live and destroy the source message. Publishing a one-line payment policy on your invoices, your website contact page, and your email footer — and backing it with staff training that covers what to do when someone ignores it — is what turns a policy into a habit.
Finally, plan for the disputes that card-not-present orders inevitably produce. Keep transaction, authorization, and delivery detail together so evidence can be assembled quickly when a chargeback alert arrives, and track response deadlines rather than discovering them late. A processor that combines a secure virtual terminal with tokenization, role-based permissions, audit logging, fraud screening, and dispute support gives you one controlled environment for every keyed payment — which is exactly what an inbox full of card numbers can never be.
A Dublin cybersecurity lecturer relocated to Vancouver Island, Torin blends myth-shaded storytelling with zero-trust architecture guides. He camps in a converted school bus, bakes Guinness-chocolate bread, and swears the right folk ballad can debug any program.
