A transcript is a record, and records leak
Everything typed into a chat window becomes a stored record: readable by agents, included in exports, kept as long as your retention policy says. That is exactly what you want for a conversation about a delayed order, and exactly what you do not want for a card number. The question is never whether your chat is secure — it is whether a given piece of information should exist in a transcript at all. Encryption in transit protects data on the wire; it does nothing about a full card number sitting in a search index six months later.
The short list of things chat should never carry
Full payment card numbers, CVV codes, passwords, government ID numbers in full, and one-time authentication codes. These share a property: possessing the string is equivalent to being the person. Once such a value lands in a transcript, everyone who can read transcripts is holding the keys, and the customer has no idea. A visitor will sometimes paste a card number unprompted, cheerfully, because it feels like talking to a shop assistant. That is a moment to handle gracefully, not to punish.
Refusing without making it awkward
Agents need a rehearsed, warm way to decline. Something close to: I am not able to take card details over chat — it is not a secure place to store them. Here is the payment link, and I will stay right here while you use it. The structure matters more than the wording: name the limit, give the reason briefly, hand over the alternative immediately, and make clear you are not abandoning them. A refusal that ends with a next step reads as competence. A bare no reads as obstruction.
Verify identity without collecting secrets
Support agents often need to know who they are talking to before discussing an account. The instinct is to ask for something secret; the better pattern is to ask for something confirmable. Ask the visitor to confirm details you already hold rather than reveal new ones — the last four digits, the email on file, the date of the most recent order. You are checking a claim, not harvesting a credential. And treat the chat widget itself as what it is: a public channel that anyone can open, not an authentication system. If a request is genuinely sensitive, move it to a logged-in surface rather than trusting the chat window to prove identity.
Assume something will slip through, and plan for it
Someone will paste a card number eventually. Decide now what happens next: the agent asks them not to reuse it, the value gets redacted or the transcript deleted, and if payment data is genuinely in scope for you, the incident gets recorded. Pair that with a retention policy short enough that old transcripts are not an indefinite liability. Data you no longer hold cannot be exposed, and the cheapest way to protect a record is to have deleted it on schedule.
How MyLiveChat fits
MyLiveChat encrypts chat traffic in transit, keeps transcripts under your account rather than scattered across agent inboxes, and lets you delete conversations that should not have been recorded. Canned responses are a practical place to store the refusal wording above, so every agent declines a card number the same warm way instead of improvising under pressure. For organisations whose rules require that conversation data never leave their own infrastructure, MyLiveChat is also available as a self-hosted option, where the transcripts live on servers you control.
When it lands anyway: redaction after the fact
However well you brief people, a visitor will eventually paste a card number or a password into chat. Treat that as an expected event with a rehearsed response rather than an incident nobody knows how to handle.
The immediate reply matters. “I am going to stop you there — please do not send card details over chat. I will remove that from the conversation now, and here is the safe way to do this.” Say it plainly and without embarrassment; visitors take the cue from the agent's tone. Then deal with the record: remove or mask the value where you can, and where the transcript cannot be edited, note what happened and make sure the conversation is not exported into a spreadsheet, a ticket, or a CRM record where copies multiply.
Deal with the underlying credential too. A password sent in chat should be changed, not merely deleted from the log — deletion protects the record, not the account. Say so to the customer, because most people do not realise the exposure outlives the message.
Three drills that build the reflex
Policies are read once; reflexes are what agents actually use at four in the afternoon. Ten minutes in a team meeting, a few times a year, is enough.
- The pre-emptive paste. One person plays a visitor who opens with a full card number. Practise the interruption sentence until it sounds natural rather than accusatory.
- The plausible ask. A visitor asks the agent to email a copy of an invoice to a different address. Practise the redirect to a verified channel without implying the person is lying.
- The screenshot. A visitor uploads a screenshot with their address and reference number visible. Practise deciding whether it needs to be kept at all, since attachments follow different retention rules from message text in most setups.
What to measure
You cannot measure what you do not log, so start there: a one-line note whenever something sensitive turned up in a conversation, with no names and no blame. Over a quarter that note answers the questions that matter. How often does it happen? Which pages or flows precede it? Sensitive data arriving in chat is very often a symptom of a broken self-service path — if people keep pasting account numbers, the account page probably does not show them what they need. How quickly was it handled? Minutes, not days, and the gap tells you whether the reflex is real.
One structural check belongs on the same list: how long transcripts live. Data you no longer hold cannot leak, so a retention period that matches your actual need does more for this problem than any amount of agent training. Review it alongside the log, and be suspicious of “keep everything forever” as a default that was never actually decided.
The same care applies to the links you hand out afterwards, since a customer-facing ticket link is a credential in its own right — see giving a customer a link to their own tickets for how long each kind lives and who can reuse it.