Payment controls and records

Keep card data out of ordinary order notes and support messages

Make ordinary order notes, tickets, chats and inquiry forms off limits for collecting full card numbers, card images, verification codes and payment secrets. PCI SSC specifically prohibits sending unprotected card numbers through email, instant messaging, SMS or chat, and prohibits retaining a card verification code after authorization even when encrypted. If such material is already present, stop forwarding it, record its location without copying its contents, and involve the PCI or security owner for controlled containment and remediation. Do not blindly delete evidence or leave prohibited data in place under an indefinite evidence-preservation excuse.

For: Research-only store owners and support leads who need to correct everyday handling of card information and payment credentials.

Updated 2026-10-01

Know which rule applies to which information

A primary account number, or PAN, is the payment card number. PCI SSC FAQ 1085 says unprotected PANs must not be sent through email, instant messaging, SMS or chat. It cites PCI DSS Requirements 4.2.2 and 4.2.1. Calling a channel internal does not turn an ordinary support conversation into an appropriate place to send card numbers.

The card verification code is a different category. PCI SSC permits merchants to request it for a card-not-present authorization, but Requirement 3.3.1.2 prohibits storing it after authorization, even encrypted. A private note, an encrypted attachment or a request from the customer to save it does not change that post-authorization rule. This page's operating rule is to keep those values out of ordinary records altogether and use the business's authorized payment-entry flow.

A Stripe secret or restricted API key is a credential, not a card number. Stripe says those keys must not be shared through email, chat or other unencrypted channels. Route credential work to the authorized technical owner. The card-number rule and the key-handling rule have different sources; neither requires staff to copy a sensitive value into a cleanup spreadsheet.

Change the habits that create the copies

Review the places staff ask buyers for information: saved replies, order-note instructions, inquiry prompts and support handoff routines. Remove requests to send card photos, full numbers or verification codes in those channels. Ask for the store order reference and a description of the payment problem instead. Authentication codes and passwords also have no place in these records.

When a buyer sends sensitive material without being asked, do not quote it in the reply or forward it to another team to explain the problem. Direct the customer to the store's authorized payment flow when payment is appropriate; first reconcile any payment already attempted. Staff should not reconstruct a payment form inside a chat because the checkout failed.

Use a note that identifies the handling issue and the restricted location of the original message. Keep the details needed for the order separate from the card material. A card image can contain more than a number, so naming the item as a card image is sufficient for this worksheet; no screenshot is needed.

Handle existing exposure through a named owner

Treat discovery as a handling incident requiring triage, not a routine bulk deletion exercise. Record the system, the internal message or ticket reference, the date discovered, the type of material and the person responsible for the security response. Report those pointers through the established incident channel without attaching the sensitive material again. If the business has no named PCI or security owner, the owner of the business must assign the response and use its acquiring or payment-provider security guidance.

The responsible owner needs to determine who could access the material and where the system may have copied it. Include attachments, quoted replies, notification messages, exports and backup handling in that investigation where relevant. These are locations to check, not a claim that every support system creates every copy. Front-line staff should stop ordinary redistribution and request access containment through the owner.

Remediation must follow the actual incident and retention process. The owner should coordinate any necessary evidence handling with prompt removal of prohibited stored authentication data, and document what was done without retaining the value in the completion note. Do not improvise a new evidence archive full of card images or verification codes. Conversely, deleting the visible message without assessing exposure and other copies is not proof that the incident is resolved.

For an exposed secret or restricted key, deleting a chat does not establish that the credential is safe. Have the authorized technical or security owner assess the exposure and manage any required credential replacement through the provider's process, accounting for dependent integrations. This article does not supply a live key-rotation procedure.

Close each finding with a handling change

A cleanup item needs two outcomes: disposition of the existing material and correction of the route that collected it. Record who approved the remediation, its completion date and how that person checked the affected locations. Keep unresolved copies explicit. A completed ticket in the support application is not itself evidence that all relevant copies were addressed.

The worksheet below is an index to the work, not a repository for the exposed content. Store it with access appropriate to the incident. Use it to distinguish a full card number from a verification code or credential so the owner applies the correct rule instead of one vague instruction to delete sensitive data.

For a Prism checkout consultation, describe the workflow that is collecting the material and the change you want considered. Share no exposed values or customer messages through the public form. Confirm any review or implementation scope, responsibilities, fees and terms first; security remediation and PCI assessment require the appropriate authorized owner.

Sensitive-data cleanup sheet

For each applicable row, record only the system and internal record reference, discovery date, responsible owner and remediation status. Never paste the number, code, key, card image or original message. Mark unknown copy locations as unresolved until the response owner assesses them.

Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.

Sensitive-data cleanup sheet. The last column is for temporary notes.
FindingEvidence pointer to recordHandling decision to documentOwner and status
Full card number in an order noteStore and internal order-note reference; state that a full PAN is present without copying it.Stop ordinary redistribution. Have the PCI/security owner assess access, storage and any copies under the actual response process.
Support ticket containing a card photo or numberTicket and attachment references plus discovery date; no screenshot.Assign containment and disposition of the original, attachments and relevant downstream copies. Correct the support prompt that requested it.
Verification code retained after authorizationLocation reference and whether post-authorization retention is established; no code.Escalate for prompt controlled remediation: encryption does not permit post-authorization storage. Do not create another evidence copy in this sheet.
Secret or restricted API key in email or chatChannel, message reference and credential type; do not reproduce the key.Technical/security owner assesses exposure and manages required credential action through the provider's process.
Card details submitted through an inquiry formSubmission reference and the form field or prompt involved; no customer payload.Identify the form's actual storage and notification destinations; correct the collection route and assign cleanup.
Quoted replies, exports or backup copiesNames of confirmed copy locations and the owner of each system; mark unassessed locations.Record how each copy is handled under the incident/retention process. Do not mark complete merely because the original ticket disappeared.
Habit corrected and remediation closedChanged instruction or form, owner confirmation and date of affected-location checks.Keep unresolved exposure separate from completed prompt changes; retain a record of actions without retaining prohibited values.

These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.

Limits

  • The PCI sources distinguish unprotected PAN transmission from post-authorization verification-code storage. This is not a claim that all PAN storage is illegal.
  • This sheet is not a PCI compliance certification, an incident-response service commitment or a determination of notification duties.
  • Do not put card numbers, verification or authentication codes, keys, passwords or customer records in the worksheet or public consultation form.

Sources

  • PCI SSC FAQ 1085 — checked 2026-09-21. Unprotected PANs must not be sent through email, instant messaging, SMS or chat. The FAQ cites PCI DSS Requirements 4.2.2 and 4.2.1.
  • PCI SSC card-verification FAQ — checked 2026-09-21. Card verification codes can be requested for card-not-present authorization, but PCI DSS Requirement 3.3.1.2 prohibits retaining them after authorization, even encrypted.
  • Stripe API keys — checked 2026-09-21. Secret and restricted API keys are unsafe to expose and must not be shared through email, chat or other unencrypted channels.
  • Prism contact — checked 2026-09-21. The consultation form excludes payment card details, passwords and customer records; a request is not a purchase or processing application.

Get help with checkout

Is this happening on your own store?