A customer pasted their card number into the chat. What now?

You cannot eliminate this completely. A customer who wants to resolve an issue quickly sends whatever they have at hand—a full card number, a photo of an identity document, an account password or details of a medical condition to support a refund request. They mean well and usually have no idea that they have just created a problem for you. Your job is not to persuade every customer to stop. Your job is to know what happens in the next minute.

This article is written for the business operating the chat, not for someone wondering whether to share a card number. It combines an incident procedure with prevention. We cover the foundations of data processing, data categories and retention separately in our article on live chat and GDPR—here, we assume those decisions have already been made or will be made independently.

We describe organizational practice, not your company's legal position. Some incidents may need to be assessed as a personal data breach and may require a separate decision on notification. Before setting your own procedure, carry out that assessment with a lawyer or data protection officer.

What customers paste most often—and why

These situations are worth separating because they only appear to form a single category of “sensitive data.” Each carries a different risk and calls for a different response. A card number creates an immediate danger and loses its value once the card is blocked. An ID scan can remain dangerous for years. Details of a medical condition are primarily a problem of processing scope rather than theft. An ID scan often lands in the chat because the customer wants to prove the order is theirs; simpler ways to confirm this are covered in our guide to verifying the customer before sharing order details.

↔ Scroll the table sideways to see all columns.

Treat attachments separately. You can assess a text message at a glance, but you must open a file to learn what it contains—and opening it is already processing. In Meetlead, files sent by customers go into scanned storage, but that scan protects against malicious content, not against an entire identity document being visible in a photo.

Before accepting documents in a support ticket, use the guide: Customer support attachments: ask for the right files.

The first minute: what to say and what not to do

The worst scenarios do not begin with bad intentions. They begin with hesitation. The agent does not know what to say, so they send a vague reply or remain silent for two minutes. The customer reads this as missing information and supplies even more data.

1. Respond immediately and name the situation.Silence is the worst response. A short sentence explaining that you do not need this data through chat stops the customer from adding more.
2. Do not ask them to repeat or complete it.Asking for the “last four digits” or a verification code creates a second record of the same data instead of resolving the issue.
3. Do not move the content to another channel.Pasting the conversation into an email or team messenger multiplies copies in places with different retention periods and access controls.
4. Point to a secure route.Tell the customer exactly where to finish the task—the customer portal, an official form or the helpline. A generic “please contact us” solves nothing.
5. Record the incident first, not last.An internal note made immediately after the conversation is worth more than reconstructing events from memory a week later.

What to do with the conversation record

This is where the real decision begins. A conversation record usually outlives the case itself, and a card number in a transcript does not stop being a card number just because the thread has been closed. On the other hand, mindlessly deleting anything inconvenient can erase evidence needed for a complaint or an incident assessment.

1. Establish exactly what entered the system.A message, an attachment, an email notification to the agent, perhaps an entry in the ticketing system. A copy may exist in every one of these places.
2. Decide whether the fragment is needed for the case.If it is not, there is no reason to retain it. If it is, reduce it to the minimum and record why it was kept.
3. Leave an internal note instead of the content.“Customer sent payment details, was advised accordingly, and the fragment was removed” carries the same operational information as the original with none of its risk.
4. Check who can access the history.If everyone on the team can see all archived correspondence, removing one fragment is only half a solution.
5. Check copies outside the tool.A CSV export, a screenshot in a team messenger and a pasted email sit beyond every retention setting in the chat system.
6. Assess the incident through the proper process.This is a formal decision, not an operational one. The person responsible for data protection makes it based on what the team recorded.

A workable response requires a structure that separates what the customer sees from what the team records about the case. In Meetlead, internal notes in tickets are separate from public messages, message retention is configurable, data is isolated by website, and exports are audited. We explain how to organize ticket-based work in our article on ticketing systems in customer service.

Prevention on the website and in the widget

You cannot reduce the number of these incidents to zero, but you can bring it down significantly—mostly through decisions you make once. Customers usually send sensitive data because no one told them not to, or because the secure route is less convenient than the chat window. A clear public statement of what you never ask for also helps customers who receive scam texts pretending to be your shop.

• One sentence beside the chat windowA brief note explaining what you will never ask for through chat works better than a paragraph in a privacy policy no one reads.
• A secure alternative close at handIf payment issues must go through the customer portal, the portal should be one click away from the conversation.
• An attachment policyDecide which files you will not accept at all and what to do when a photo of an identity document arrives anyway.
• Masking in recordings and heatmapsForm fields and selected elements can be masked or blocked so entered content is not preserved in a session recording.

The last point has a separate technical dimension. Meetlead session recording can mask fields and text and block or mask elements selected with a CSS selector, keeping entered data out of the recording. We cover configuration and the questions to ask before launch in our article on session recording and GDPR.

One point matters here: no chat tool removes the need for a procedure. Meetlead does not automatically detect or delete card numbers in conversation content. That is a job for team instructions and settings that limit the reach of the data. If a provider promises fully automatic filtering, ask exactly what it detects and how reliably.

For law firms and accounting practices, this prevention is part of the profession rather than an optional extra. We explain how to set the boundary of the text channel in our guide to enquiries at law firms and accounting practices.

The team: one sentence and an escalation path

A procedure no one remembers under stress does not exist. Reduce it to one sentence every agent can say without hesitation and one clear path that tells them who should receive the case.

• Who is the first point of contact when an agent is unsure whether something is an incident.
• How quickly that person must respond and what the agent should do if they do not.
• Where the incident is recorded so the note does not disappear into a private team conversation.
• Who decides whether to remove the fragment and how much to remove.
• Who assesses the incident against obligations to the person whose data is involved.
• What the customer is told if the case requires further action.

This sentence and escalation path should be part of onboarding, not knowledge passed on verbally after the fact. We set out a practical plan for an agent's first days in our guide to onboarding a new support agent. Save the response as a template too, so no one has to improvise under pressure.

Preparation checklist

• The team knows the one sentence to use when a customer pastes sensitive data into the chat.
• The sentence is saved as a response template, not merely discussed in a meeting.
• A brief notice beside the chat window states what you will never ask for in a conversation.
• A secure alternative—the portal, a form or a helpline—is identified clearly.
• You have decided which attachments you accept and what to do with a file outside that list.
• Message retention is set deliberately rather than left at its default value.
• Access to conversation history reflects what each team role genuinely needs.
• Internal notes are clearly separated from content visible to the customer.
• Field and selector masking in session recordings is configured and tested.
• Everyone knows who assesses a possible breach and how it should be reported.
• Incidents from recent months are reviewed to identify recurring patterns.

If you can check off most of these points, the next case will be a brief operational incident rather than a crisis. It is also a good test of overall support maturity: a company with a ready response to a pasted card number has usually brought the less dramatic parts of its work under control too.