A saved card does not tell you what payment data your store holds

Separate what the provider holds from what the store holds

A saved payment method is a relationship between a provider record and a reusable reference, not a statement about your store's database. In the documented WooCommerce Stripe integration, the saving workflow uses payment tokens instead of directly stored full card numbers or CVC. If your store runs that integration as documented, the sensitive credential lives with the provider, while your store holds the token or reference used to ask the provider to charge it again.

That distinction does not generalize by itself. It comes from one named integration's documentation, checked against your installed gateway name and version. A different extension, a customized checkout or an older version needs its own evidence. Record which integration and version you actually operate, and read its own documentation or your own configuration rather than assuming the token model applies.

Avoid the two common mistakes: telling a customer the store holds nothing because a saved card exists, and telling them the store holds their card because the checkout displays the last digits. Neither conclusion follows. The displayed digits and the stored credential are different data, held in different places, governed by different handling rules.

Inventory the store-side data categories one at a time

List each category separately: the provider-held credential, the token or payment-method reference your store stores, the display fields shown to the buyer or staff such as brand and last digits, and order records that connect a purchase to that reference. For each category, record where it lives, which system is authoritative and who can retrieve it. An authorized administrator can inspect gateway settings and an order's payment reference without viewing or requesting any full card number.

Then look for categories people forget. Copies can exist in support tickets where a buyer pasted details, in exported spreadsheets, in error logs, in database backups and in staff inboxes. The documented token behavior of the gateway does not audit these places. A backup that predates a cleanup, for example, can still contain data the live store no longer shows. Mark each such location as checked, found clean, found containing payment material, or not yet assessed.

Where you find card numbers or verification codes in ordinary notes or messages, treat that as a separate handling problem with its own containment process. The custody map should point to the affected system and record reference, never reproduce the contents.

Answer the customer from the map, not from habit

A customer's question usually mixes several distinct questions: can I see or remove my saved card, do you store my card number, and who else has my details. Use the custody map to answer each part with the record that settles it. The store can describe its saved-method display and removal options from the documented gateway behavior and the actual account state. The provider's own retention and access questions belong to the provider.

Do not ask the customer to send card numbers, security codes or screenshots to locate their record, and do not email them anything your map shows is provider-held. Where the map has an unresolved row, say that part is being verified rather than filling the gap with a reassuring guess.

If the customer is asking for deletion or access as a legal matter, route the request to whoever owns privacy requests for the business and have qualified advice determine the applicable duties. The custody map supplies facts about where data sits; it does not decide what a given law requires you to do about it.

Keep storage assurances inside the verified rows

Only publish a statement about payment-data storage that names the verified setup: for example, that saved payment methods in the current integration are handled through the provider's token system, if that is what your records confirm. An assurance that covers all systems, all history and all connected services needs evidence for all of them, including backups, logs and support channels.

Assign an owner to recheck the map when the gateway, its version or a connected process changes. A statement written for one integration stays accurate only while that integration and the surrounding habits stay the same. For a scoped Prism website review of a storage assurance on your public pages, bring the URLs and a non-sensitive description of the integration; scope, responsibilities, fees and terms are confirmed before work begins.

Payment-data custody map

Complete one map for the store as it operates today, naming the holder and location of each data category from actual configuration and documentation. Leave the final cell blank where a location is unverified rather than guessing. Never enter card numbers, security codes, full tokens or customer identities.

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.

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.