Masking Credit Card Numbers by Using Tokens

Credit Card Tokenization

Credit card tokenization is a secure method of storing credit and debit card data. It replaces credit and debit card numbers with random identifiers called tokens. Tokens are typically the same length as the credit or debit card numbers and include the last four digits of the card numbers.

Note:

BRM does not tokenize PINless debit card numbers.

By default, credit card tokenization is enabled. When tokenization is enabled, BRM receives tokens from Paymentech and stores only the tokens in the BRM database. The tokens are then used for any BRM-initiated payments instead of the actual card numbers. The actual card numbers and their mapping to the tokens are stored securely in Paymentech. Tokens are valid only between the sales system and the credit card processor. Therefore, the tokens can be transmitted safely without the risk of exposing the card data.

Credit card tokenization occurs at the following times:

During account creation
When credit cards are used for one-time payments
When customers change their credit or debit card number
When customers change to the credit card payment method

If credit card validation fails, tokenization does not occur. In this case, a string value (asterisks (******) followed by the last four digits of the card number) is stored in the /event/billing/validate/cc object. The string value can be used to authenticate a credit or debit card but cannot be used for any transaction.

If you processed credit cards before enabling tokenization, your BRM database includes untokenized card numbers. Do the following to tokenize existing card numbers stored in the BRM database:

Replace existing untokenized card numbers in the BRM database with tokens. See "Replacing Credit Card Numbers with Tokens".
Purge the database of old untokenized card numbers. See "Purging Old Credit Card Event and Audit Trail Objects".

Replacing Credit Card Numbers with Tokens

Note:

If you are migrating legacy credit card data into the BRM database, migrate the data before replacing numbers with tokens.

If you have already processed credit cards before enabling tokenization, the BRM database stores untokenized credit card numbers. You need to replace those numbers with tokenized numbers.

Before replacing numbers with tokens:

If you are migrating from an external database, migrate the data. See "Understanding Conversion Manager" in BRM Migrating Accounts to the BRM Database.
Enable credit card tokenization in BRM. See "Credit Card Tokenization".

To replace credit card numbers with tokens, run the pin_cc_migrate utility.

To replace all credit card numbers with tokens, run the following command:
```
pin_cc_migrate -vendor paymentProcessorName
```
where paymentProcessorName is the credit card processor or ACH to use for validating credit and debit cards.

For example:
```
pin_cc_migrate -vendor fusa
```
To replace only a specified number of credit card numbers in /payinfo/cc objects, run the following command:
```
pin_cc_migrate -vendor paymentProcessorName -num number  
```
where number is the number of /payinfo/cc objects to be selected for tokenization.

For example:
```
pin_cc_migrate -vendor fusa -num 10
```
To replace the credit card numbers for only a specified account, run the following command:
```
pin_cc_migrate -vendor paymentProcessorName -account accountPOID
```
where accountPOID is the Portal object ID (POID) of the account to select for tokenization.

For example:
```
pin_cc_migrate -vendor fusa -account 3421343
```
To specify the time range for selecting credit card numbers for tokenization, run the following command:
```
pin_cc_migrate -vendor paymentProcessorName -start_date mm/dd/yy -end_date mm/dd/yy 
```
For example:
```
pin_cc_migrate -vendor fusa -start_date 01/01/11 -end date 10/30/11
```
The start and end dates specify the time range for selecting /payinfo/cc objects for tokenization.

See "pin_cc_migrate" for information about the utility's syntax and parameters.

Purging Old Credit Card Event and Audit Trail Objects

When you run the pin_cc_migrate utility, only the credit and debit card numbers stored in /payinfo/cc objects are replaced with tokens. The credit and debit card numbers stored in the following objects are not replaced:

Event objects created for credit card validation and credit card charges (such as /event/billing/charge/cc objects)
Audit trail objects created for tracking credit card payments (such as /event/audit/customer/payinfo/cc objects)

Oracle recommends that you purge these event and audit trail objects immediately after you run the pin_cc_migrate utility. You can purge the old event and audit trail objects by using BRM utilities or purging scripts:

To purge event objects, see "About Purging BRM Event Objects" in BRM System Administrator's Guide.
To purge audit trail objects, see "Purging Archived Audit Data" in BRM Developer's Guide.

Note:

If you purge /event/billing/charge/cc objects, you cannot refund payments to the same credit card accounts that were used for one-time payments made before running pin_cc_migrate.