A merchant wants to remove primary account numbers from most of its cloud-hosted applications to shrink the scope of its payment card compliance assessment, while still being able to retrieve the real number when processing refunds. Which approach best fits?

Tokenization replaces a sensitive value, such as a primary account number, with a surrogate token that has no mathematical relationship to the original. The mapping between token and value is kept in a tightly controlled token vault, so applications that only handle tokens no longer store, process or transmit cardholder data, which can reduce the scope of a payment card assessment. When a refund requires the real number, an authorized process asks the vault to detokenize. Field-level encryption protects the number, but every application still stores the encrypted card number and typically has a path to decrypt it, so those systems generally remain in assessment scope. Salted hashing is one-way; applications cannot recover the original number from the digest, so the refund requirement cannot be met. Static masking that displays only the last four digits while the full number remains stored changes presentation, not storage, and the systems still hold cardholder data. Exam caveat: the token vault itself becomes a high-value, in-scope system that needs strong segmentation, access control and monitoring. Operational check: confirm that applications outside the vault hold only tokens and that detokenization is restricted to the refund workflow.