What customers should never send you in a chat, and what to do when they do
Never ask a customer to type a full card number, a password or a one-time code, a copy of an ID or passport, or detailed medical information into a website chat, and have a ready reply for when they send it anyway. A chat is a written record that several people on your team can read, so collect in it only what you need to answer the question, and send anything sensitive through the channel built for it. Here is a short policy your team can adopt, the wording to use, and the steps when something slips through.
The never list
| Never ask for in chat | Why | Use instead |
|---|---|---|
| Full card number, expiry, security code | Anyone who reads the chat could use it | Your payment page or payment link |
| Passwords and one-time codes | Nobody legitimate needs them | Tell the customer you will never ask |
| ID, passport or licence numbers and copies | Kept longer and seen by more people than needed | Your booking or document process, or in person |
| Detailed medical history or symptoms | Sensitive health data belongs in medical records | A call or appointment with the clinic |
| Bank account login details | Same as passwords | Never needed |
Some of this is a matter of law, and rules differ by country and emirate; check what applies to your business. Much of it is simply good sense: the less sensitive data sits in chats, the less can go wrong.
What you may ask for
Ask for what the question needs, and no more:
- A name, so you can address them and find a booking.
- An order or booking number.
- A phone number or e-mail, with a reason the customer cares about ("to send the confirmation"); collecting a lead without being pushy has the wording.
- The last four digits of a card, if your payment system shows them and you need to match a payment.
- Dates, areas and preferences for a booking or delivery.
Wording for the moment it happens
Customers often send sensitive data with good intentions, to speed things up. Reply kindly and quickly:
- Card details: "Thank you, but please don't send card details in the chat. For your safety, use the payment link I'll send you. Could you delete that message on your side as well?"
- ID number: "Thanks. We don't need your ID details for this. Your booking number is enough."
- Medical detail: "Thank you for telling us. So the doctor can advise you properly, let's book a short appointment. Which day suits you?"
- A code: "Please never share a code with anyone, including us. We will never ask for it."
Add a line to your welcome message for clinics or any business that handles payments: "Please don't share card or medical details in chat."
What your team does next
- Do not repeat the data in your reply or in an internal note.
- Do not copy it anywhere, such as a spreadsheet or a personal phone.
- Tell the customer what to use instead, using the wording above.
- Tell the person responsible in your business, so they can decide what to do with the record under your own policy.
- If it was a card number, suggest the customer contacts their bank if they are worried.
How StayReplied helps you keep chats safe
A few things in StayReplied support this policy. Roles have explicit permissions, so not everyone on the team must see everything (which role for whom). Exports, configuration changes, knowledge publication, sends and consent are recorded in an audit trail, and admins can delete a customer's data with the action audited, as the security page describes. Workspace data is stored in the EU (Milan), as the about page states, and the site says workspace data is not sold, used for advertising or used to train AI models. The web chat widget has a field for your privacy policy link, so visitors can read how you handle their data.
Conversation history is kept for at least the period your plan shows on the pricing page: 90 days on Starter, 180 on Team, 365 on Business.
If you use AI replies, its safety rails matter too: tools are allowlisted and permission-scoped, and text in messages, images or web pages cannot authorise actions, so a customer cannot talk the AI into doing something it is not allowed to do.
A one-page policy for your team
- We never ask for full card numbers, passwords, codes, ID copies or medical history in chat.
- We ask only for what the question needs.
- If a customer sends sensitive data, we do not repeat or copy it, we point them to the right channel, and we tell the person responsible.
- We never move a chat to a personal phone to "handle it privately".
- When in doubt, we ask the manager in an internal note.
Keep it in an Internal knowledge base and read it with every new colleague (the one-hour training plan); the unified inbox keeps notes visibly separate from customer messages.
When this is not for you
If your business must collect identity documents or health records by law or by the nature of your work, a website chat is not the tool for that collection; use a secure process designed for it, and keep chat for questions and bookings. And if your sector's rules set specific requirements for a chat provider, read the security page against them before you start; who StayReplied is for covers the teams it fits today.
Questions and answers
Is it safe for customers to send card details in a chat?
No. Ask customers never to type card numbers, expiry dates or security codes in chat, and send them a payment page or link instead.
What should I do if a customer sends their ID in chat?
Thank them, explain you do not need it for this question, do not copy it anywhere, and tell the person responsible in your business.
Where is StayReplied workspace data stored?
In the EU (Milan), as the about page states. Workspace data is not sold, used for advertising or used to train AI models.
How long does StayReplied keep conversations?
At least 90 days on Starter, 180 on Team and 365 on Business, as the pricing page shows. Admins can delete a customer's data sooner, and the action is recorded.
Set up a chat your team can run safely.
start your free trial, 14 days, no card needed.