A Customer Texted a Card Number to the Office. Do Not Forward the Message.

Governed image-library asset 069 by Jared James Mastroianni. The retained catalog does not state the production method. It is editorial context only—not evidence of a customer payment message, a real facility response, the fictional Westbridge Storage example, a deployment, or a result.

Consider this fictional situation: a customer texts the office phone, “Can you run this card for my rent?” The message includes a full card number, expiration date and security code.

The manager wants to help. The payment is due. The quickest response appears to be forwarding the text to a supervisor, copying the numbers into the payment screen or taking a screenshot before deleting the message.

Each shortcut spreads the information.

The frontline job is smaller and more disciplined: stop propagation, move the customer to the approved payment path, notify the responsible owner and follow the organization's governed process for securing or removing the data. Do not turn one unintended message into five new copies.

Recognize the incident without repeating the data

The first step is classification. The customer sent payment-card information through a channel the facility did not intend to use for card collection.

Do not read the numbers aloud. Do not write them on a note. Do not paste them into a work order, customer profile, shift log or team chat. Do not include them in the incident description.

The record usually needs metadata, not the card data itself:

• facility and approved incident identifier;
• date, local time and receiving channel;
• business device or account that received it;
• message or conversation identifier, if the approved process uses one;
• whether the message was opened, replied to, forwarded, copied, downloaded or screenshot;
• who was notified and when; and
• the current containment owner and next step.

The description can say, “Unsolicited payment-card information received by office text at 10:14 a.m.” That is enough to start the response. A masked fragment should be recorded only if current policy specifically requires it and the approved record is designed to hold it.

Do not reply inside the contaminated thread

The Payment Card Industry Security Standards Council addresses this exact situation in FAQ 1157. If cardholder data arrives through an unintended channel, personnel should avoid replying with the same message attached or quoted because that can further propagate the unsecured information. The Council says the data should be immediately removed or secured according to PCI DSS and the merchant's chosen cardholder-data environment.

That does not mean a manager should improvise a deletion method. The message may exist on a device, a synchronized account, a notification preview, a backup, an export or another connected system. The authorized privacy, security, payment or technology owner must determine the governed response for the actual channel.

It does mean the frontline employee should stop creating new copies:

• do not forward the message to a manager;
• do not reply while the sensitive message is quoted beneath the response;
• do not screenshot it for proof;
• do not copy it into a personal phone, email or note application;
• do not print it; and
• do not paste the numbers into a different system unless the organization's approved payment process expressly authorizes that workflow.

Escalation should point the owner to the affected account or message through the approved internal method without reproducing the contents.

Move the customer to the approved payment path

The customer still needs a clear answer. Use an alternate approved channel or a new message that does not quote the original sensitive content.

A practical response is:

We cannot accept payment-card information through text. Please use our approved payment method at [approved route] or contact the office through [approved channel]. For your protection, do not resend the card information in a message.

The exact wording and route must come from current company policy. Do not invent a portal, payment link, telephone process or customer identity check. Do not promise that the original message has already been deleted unless the authorized owner has verified that result.

PCI SSC FAQ 1085 states that unprotected primary account numbers must not be sent through email, instant messaging, SMS or chat. That source explains the payment-security boundary. It does not decide which system, link or phone workflow a particular storage operator has approved.

Keep payment status separate from message status

Receiving a card number does not mean the customer's balance was paid. Containing the message does not mean a payment was attempted. Directing the customer to the approved channel does not mean the transaction succeeded.

Keep the states separate:

1. Message received: sensitive information arrived through an unintended channel.
2. Propagation contained: staff stopped replies, forwarding, copying and screenshots.
3. Responsible owner notified: the designated owner accepted the issue.
4. Customer redirected: the customer received an approved payment route without the sensitive message being repeated.
5. Payment outcome: the approved payment system separately shows attempted, authorized, declined, posted or another governed status.
6. Data disposition verified: the responsible owner confirms the channel-specific securing or removal outcome.
7. Record closed: required review and follow-up are complete.

This separation prevents two common errors. The first is promising that the account is current because the customer sent information. The second is charging the card twice because one employee copied the numbers while the customer also used the approved channel.

Limit access while the response is open

The message should not become office conversation. Notify only the roles required by the incident process. If the receiving device or account must be restricted, the authorized owner makes that decision. A manager should not wipe a business phone, disable synchronization, change retention settings or remove audit records without direction.

The Federal Trade Commission's Protecting Personal Information guide advises businesses to keep only sensitive information they need, limit access and dispose of information securely when the business need ends. The guidance is general and does not determine an operator's legal duties, PCI scope or technical deletion procedure. Its operational lesson is direct: unnecessary copies create unnecessary exposure.

If the manager used an unapproved action before recognizing the problem—such as forwarding the text—record that fact honestly. Do not hide the copy or mark containment complete. Tell the responsible owner which additional person, device or system received it so the response can include the expanded scope.

A fictional next-shift example

The following facility, people, account, times and outcomes are fictional. No card number or real customer data appears in the example.

At fictional Westbridge Storage, an office text account receives a message at 10:14 a.m. containing payment-card information for fictional account WB-FIC-204. The manager opens the message but does not reply, forward, screenshot, print or copy its contents.

The manager opens incident PAY-FIC-017 in the approved restricted record and notes the channel, time, device account, message identifier and actions not taken. The description contains no card data. At 10:18 a.m., the designated payment-security owner accepts the handoff.

Using a new approved communication—not a reply that quotes the original message—the manager tells the fictional customer that card information cannot be accepted by text and provides the facility's fictional approved payment route. The incident record does not claim the payment succeeded.

The designated owner then follows the fictional company's channel-specific process and records the final disposition. The manager checks the approved payment system separately before changing the account status. The example claims no compliance determination, prevented loss, customer result or real deployment.

Use the unintended payment-data response card

Download the governed response registers

Download the blank unintended payment-data response CSV

Download the explicitly fictional Westbridge Storage example CSV

The companion Unintended Payment-Data Message Response Card gives the next shift one controlled record without copying the sensitive data. It covers:

• the receiving channel and time;
• propagation actions that did or did not occur;
• the responsible owner's acceptance;
• the approved customer redirect;
• payment status from the payment system—not from the message;
• channel-specific disposition evidence; and
• final review and closure.

Train the sequence before it happens. Staff should know where to record metadata, whom to notify and how to redirect a customer without quoting the message. The response should be simple enough to use under pressure and narrow enough to avoid creating another repository of card data.

The customer was trying to pay. Treat that intent with respect, but do not confuse helpfulness with uncontrolled handling. Stop the spread. Use the approved route. Keep the payment result separate. Close the incident only when the accountable owner verifies the data disposition and the account record tells the truth.

Sources and limits

• PCI Security Standards Council FAQ 1157: guidance for cardholder data accidentally received through an unintended channel, including avoiding replies that propagate the original content. Actual PCI DSS scope and response requirements depend on the merchant's environment and qualified assessment.
• PCI Security Standards Council FAQ 1085: states that unprotected primary account numbers must not be sent through end-user messaging technologies such as email, SMS and chat.
• FTC, Protecting Personal Information: A Guide for Business: general business guidance to collect and retain only needed sensitive information, limit access and dispose of it securely. It is not a self-storage payment procedure or a compliance determination.

Jared Mastroianni is Chief Operating Officer of modSTORAGE and CEO and Founder of Facily.ai.