Choosing an encryption and decryption strategy

There are multiple deployment options when choosing an encryption strategy.

The most typical options are:
  • No encryption or decryption
  • External tokenization
  • Both encryption and decryption
  • No decryption
Note: It is recommended that you use external tokenization as your encryption strategy.

Use the following explanation to guide your decision-making process:

Using no encryption and no decryption

Do not save clear text credit cards numbers in the database. However, you may configure encryption in , if:

  • Your business does not accept, process, or store credit card numbers or other sensitive information.
  • All encryption and decryption is handled externally. The application passes the externally encrypted credit card numbers to other systems. If you enable encryption, strings that are encrypted would be encrypted again.
Note: Storing encrypted PANs, even if encryption and decryption is not implemented, may put the application into PCI DSS and PA-DSS auditing scope.

Using both encryption and decryption

The application encrypts and decrypts credit card numbers automatically as required. However, this strategy is not the recommended encryption strategy.

Using encryption but no decryption

If your business requires to store credit card numbers, but you never want to automatically decrypt them under any circumstances, you may want to enable only the encrypt function and disable the decrypt function.

This way, encrypts the credit card numbers passed in as clear text but never converts them back. Once encrypts the information, all your custom extensions are passed as encrypted credit card numbers and must handle decryption externally. It is important to note that a few user exits in (for example, YFSbeforeCreateOrderUE) are invoked before the credit card number is encrypted, so it still has access to the clear text number.