Setting Up Credit Card Processing for a Hosted Implementation

This topic covers the steps used to convert from the traditional credit card model to the hosted credit card model:

  1. Define tokenization.

    For FSCM applications that provide online transmission, the system supports a tokenized credit card profile created by a third-party host.

  2. Convert credit card data.

    In this phase, you convert locally stored credit card data into profiles and transfer the profiles to a third-party credit card processor.

    For information about integrating with a third-party credit card processor, see the setup information in Enterprise Components: Setting Up Credit Card Integration for Integration Broker.

  3. Erase locally stored credit card data.

    A secure wipe program permanently erases all credit card information once a PeopleSoft Order to Cash system switches to the hosted credit card implementation.

PeopleSoft FSCM provides a framework in the Order to Cash modules (Order Management, Billing, eBill Payment, and Accounts Receivable) to facilitate the collection and processing of payment information by third-party credit card hosts. Businesses with an Order to Cash system can convert from a traditional credit card model (local storage of credit card data) to a hosted model, where a third party hosts or stores credit card data.

Note: If you choose to convert to a hosted model, data cannot be rolled back. Please ensure that this is the credit card payment model you really want.

In a traditional implementation, the following data are stored locally:

  • First and last name

  • Credit card number (encrypted)

  • Last four digits of the credit card number

  • Credit card type

  • Expiration month and year

  • Credit card address fields

  • Email address

  • Phone number

The PeopleSoft Order to Cash system maintains only these fields after conversion to the hosted implementation:

  • Credit card type

  • Last four digits of the credit card number

  • Payment processor

  • Profile ID

The profile ID provides a means for identifying the customer and payment in both the PeopleSoft system and the third-party processor.

Note: There may be a fee associated with converting the data of each credit card to a profile. The actual cost is determined by your chosen payment processor.

This diagram illustrates the steps for moving from a traditional to a hosted implementation:

Image: Flow of the conversion to the hosted credit card model

Flow of the conversion to the hosted credit card model

One-way conversion from a traditional credit card implementation to a hosted credit card implementation

Prerequisites

You must setup a third-party payment processor. Multiple processors can now be set up and assigned to a specific credit card type. See the information about setting up credit card interfaces in Enterprise Components: PeopleSoft Integration Interfaces.

You must create a default credit card group for a specific credit card type at the system level, and optionally at the business unit level. Refer to Setting Up Credit Card Options and Groups.

You must also map processor credit card types to PeopleSoft credit card types using processor-specific code in the following functions: Function GetPSCardType and Function GetVendorCardType. Sample code is provided in each function. You must reference your own processors in the code before running the conversion process.

On FUNCLIB_CREDCRD.CR_CARD_TYPE.FieldFormula, add processor specific-code to the following functions:

  • Function GetPSCardType - Maps processor credit card types to PeopleSoft-defined credit card types.

    Function GetPSCardType(&Vendor As string, &CardType As string, &PSCardType As string);
       rem ================================================================;
       rem Vendor Credit Card Types to PS Credit Card Types                ;
       rem ================================================================;
       /* Declare Function GetPSCardType PeopleCode FUNCLIB_CREDCRD.CR_CARD_TYPE FieldFormula; */
       /* Dev Note:  Modify codeline to support your processors */
  • Function GetVendorCardType - Maps PeopleSoft-defined credit card types to processor credit card types.

    Function GetVendorCardType(&PSCardType As string, &Vendor As string, &CardType As string);
       rem ================================================================;
       rem PS Credit Card Types to Vendor Credit Card Types                ;
       rem ================================================================;
       /* Declare Function GetVendorCardType PeopleCode FUNCLIB_CREDCRD.CR_CARD_TYPE FieldFormula; */
       /* Dev Note:  Modify codeline to support your processors */

Or, see the product documentation for PeopleSoft Financials/Supply Chain Management 8.9 to 9.2 Upgrade, PeopleSoft Financials/Supply Chain Management 9.0 to 9.2 Upgrade, or PeopleSoft Financials/Supply Chain Management 9.1 to 9.2 Upgrade.

Credit Card Conversion

In this phase, you convert your existing credit card data into profiles and transfer locally stored credit card data to the third-party credit card processor. This option is only available for Order to Cash systems in PeopleSoft FSCM. The only credit card data that are stored in PeopleSoft tables after conversion are the following: last four digits of the credit card number, profile ID, credit card type, and payment processor.

Before you run the conversion process:

  1. Evaluate all credit card transactions to determine the cut-off date for transactions.

  2. Evaluate your customer base. Do you have any inactive customers? If yes, you can choose to exclude their data in the conversion process.

Credit Card Wipe

After converting credit card data to profiles and transferring the data to your choice of third-party payment processor, you must purge all credit card data from records in your PeopleSoft system.

Note: The Remove Credit Card Data process permanently removes all credit card data from records in your PeopleSoft system. You cannot undo this process.

This component displays all records that contain fields CR_CARD_NBR and CR_CARD_CVNUM. The user can select the records that should be securely wiped and then run the process to erase them.

The Remove Credit Card Data process generates a random sequence of characters, writes it to the credit card fields, and saves it in the database by performing a database commit. The process overwrites the data between 8 and 30 times, depending on the value you enter in the Number of Overwrites field. The default value is 8.

PeopleSoft Billing invokes the Remove Credit Card Data process directly from PeopleCode to process a specific interface record, as discussed in the documentation for the Remove Credit Card Data page.

Page Name

Definition Name

Navigation

Usage

Convert Credit Card Data

FS_CCHOST_CNV

Set Up Financials/Supply Chain > Upgrade > Credit Card Hosting > Convert Credit Card Data > Convert Credit Card Data

Run the Credit Card Hosting Conversion process (FS_CCHOST_CV) to convert credit card data to hosted tokens (profiles).

Remove Credit Card Data

FS_CCWIPE

Set Up Financials/Supply Chain > Upgrade > Credit Card Hosting > Remove Credit Card Data > Remove Credit Card Data

Run a permanent purge of credit card data using the Remove Credit Card Data Application Engine process (FS_CCWIPE).

Credit Card Options

CR_CARD_OPT

Set Up Financials/Supply Chain > Common Definitions > Credit Cards > Credit Card Options > Credit Card Options

Specify a default credit card group at the system level.

Depending on the number of lines of data contained in the records to be wiped, the process can take a long time to complete. Oracle’s PeopleSoft recommends running several secure wipe processes in parallel. To run several processes in parallel, create multiple run control IDs and select a distinct set of records for each run control ID. If there is overlap of records in the run control IDs, one of the processes may skip this record, because the system avoids wiping the same record at the same time in multiple instances.

If for any reason the Remove Credit Card Data process abnormally terminates, you can return to the page to restart the process with the same run control ID. The system returns an error for the record that was being processed when the process terminated. You can select the record with the error along with other records and rerun the process.

Wipe Status and Process Status

A master credit card wipe record (FS_CCWIPE_MST) contains all the records that should be wiped. All run control IDs read data from this master record, and each execution of the process updates line (by record) statuses in the master record. The system updates the status directly in the master credit card wipe record. You may need to refresh the Remove Credit Card Data page to view the current status.

Field or Control

Definition

Wipe Status by Record

View the processing status for each record or line:

Available for Processing – The record in that line has not yet been wiped.

Processing – When the process begins to wipe a specific record, the status changes to Processing, and parallel processes skip this record. As soon as the wipe process of this record finishes the status is updated to Complete.

Complete – As soon as the wipe process finishes the wiping of a record, its status changes to Complete. Records with a Complete status can still be selected and reprocessed.

Error – Indicates the specific record where the process abnormally terminated. The record can be reselected, and processing treats this record the same as records with an Available for Processing status.

Process Status by Run Control ID

View the processing status in the header for the run control ID:

Available for Processing – When the header Wipe Status field shows Available for Processing, you can select lines and run the secure wipe process.

You also see the Available for Processing status when the process finishes, but unprocessed records still exist in the master credit card wipe record.

Processing – The status changes to Processing upon clicking the Run button. Create a different run control ID to select other lines or records and run processing.

All Records Wiped – When all the records in the master credit card wipe record are marked as Complete at the line level, all new and existing Remove Credit Card Data pages display All Records Wiped in the header.

After converting to a hosted credit card implementation, the Credit Card Data Page shows only the credit card data needed to create a token ID that matches up information between the PeopleSoft Order to Cash system and the profile now administered by the third-party processor. For more information, see Understanding Credit Card Processing.

Use the Convert Credit Card Data page (FS_CCHOST_CNV) to run the Credit Card Hosting Conversion process (FS_CCHOST_CV), which converts credit card data to profiles and transfers the data to a third-party payment processor.

Image: Convert Credit Card Data page

This example illustrates the fields and controls on the Convert Credit Card Data page. You can find definitions for the fields and controls later on this page.

Convert Credit Card Data page

Field or Control

Definition

Language Code

Select a language code.

Enable Profile Tokenization and Hosted Entry for Order to Cash

Automatically selected by the system when you run the Remove Credit Card Data Application Engine process (FS_CCWIPE). The FS_CCWIPE process also selects the setup field of the same name on the Credit Card Options Page to indicate that the system now uses the hosted credit card model.

Note: If you want to use traditional credit card implementation, never run this process, and this option will remain deselected.

Define when the system should create temporary credit card profiles:

  • Create Temporary Profiles Before Online Credit Card Transactions

  • Create Temporary Profiles After Online Credit Card Transactions

The option you select here also appears on the Credit Card Options page.

Convert Inactive Customers

Select this check box to include credit card data for inactive customers in the conversion.

Convert only customers having transactions after

Enter a calendar date cutoff to convert only credit card data for customers having transactions after the specified date.

Key Separator

Enter a key separator.

Use the Remove Credit Card Data page (FS_CCWIPE) to run the FS_CCWIPE Application Engine process, which clears existing database fields containing credit card data.

Image: Remove Credit Card Data page

This example illustrates the fields and controls on the Remove Credit Card Data page. You can find definitions for the fields and controls later on this page.

Remove Credit Card Data page

Field or Control

Definition

Process Status

Displays the processing status of the master record for the run control ID:

Available for Processing – When the header Wipe Status field shows Available for Processing, you can select lines and run the secure wipe process. You also see the Available for Processing status when the process finishes, but unprocessed records still exist in the master credit card wipe record.

Processing – The status changes to Processing upon clicking the Run button. Create a different run control ID to select other lines or records and run processing.

All Records Wiped – When all the records in the master credit card wipe record are marked as Complete at the line level, all new and existing Remove Credit Card Data pages display All Records Wiped in the header.

Number of Overwrites

Enter a value between 9 and 30, or accept the default of 8. The process overwrites the data between 8 and 30 times, depending on the value you enter in the Number of Overwrites field.

Action

Choose from these options:

  • Select All

  • De-Select All

The action you choose selects or deselects the records with the Wipe Status you specify, when you click the Go button. You can also manually select individual records or lines by clicking the Select check box for a record or line.

Wipe Status

Use this field to filter records with a specific Wipe Status, choose an action, and click the Go button to select or deselect sets of records with a specific Wipe Status.

Choose from these options:

  • Available for Processing – Filters for records that are available for first-time processing.

  • Complete – Filters for records that have already been wiped. However, you can select records with a Complete status and run the process again, if desired.

  • Error – Filters for records at which the secure wipe processing terminated abnormally. You can select this record and run the process again.

  • Processing – Filters for records that are currently being processed.

Go

Click this button to apply the Wipe Status filter and then select or deselect the records depending on your choice in the Action field. Use the Go button along with the Wipe Status filter and Action field to make a batch selection of records.

Conversion Status

Displays which records have been converted or not (only when this information is available). When you select a record not yet converted, the system issues a warning.

PeopleSoft Billing may receive credit card transactions from legacy third-party systems on a daily basis. After a PeopleSoft Billing system converts credit card data received from the interface into a hosted profile, the Remove Credit Card Process must clean a specific set of lines in INTFC_BI_HDR records. To use the secure wipe process in an ongoing scenario, PeopleSoft Billing system administrators working with the hosted model should call FS_CCWIPE Application Engine processes following certain requirements.

This table contains the directions for populating fields in the FS_CCWIPE record before invoking the FS_CCWIPE Application Engine process for PeopleSoft Billing.

Field

Required value for this field

Comments

OPRID

%operatorid

RUN_CNTL_ID

BI Publisher should create a new run control ID.

PROCESS _FREQUENCY

‘A’

CCWIPE_STATUS

‘N’

PROCESS_INSTANCE

0

CCWIPE_QTY

Enter a number between 8 and 30.

It is the number the CC fields will be overwritten

CCWIPE_INTERF

‘Y’

It identifies the groups coming from Billing

This table contains the directions needed to populate fields in the FS_CCWIPE_DTL record before invoking FS_CCWIPE Application Engine process for PeopleSoft Billing.

Field

Required value for this field

Comments

RUN_CNTL_ID

BI Publisher should create a new run control ID.

Populate with the same run control ID entered in FS_CCWIPE.

RECNAME

'INTFC_BI_HDRCMP'

If you need to clean another record, one more line can be added under the same RUN_CNTL_ID; update this field with the new RECNAME.

FIELDNAME1

'CR_CARD_NBR'

Typically 'CR_CARD_NBR', but in case you need to wipe another field (Char 44 only), simply add the name here.

FIELDNAME2

‘ ‘

Typically ‘ ‘ for this use, but if you need to clean a second field in the same record (Char 44 only), you can use this field.

FIELDNAME3

‘ ‘

Typically ‘ ‘ for this use, but if you need to clean a second field in the same record (Char 44 only), you can use this field.

CCWIPE_SEL

'Y'

SQL_STMT_254

<statement to determine which lines should be wiped>

Must start with 'WHERE’, otherwise the AE will ignore it and will not process anything.

For example,

'WHERE INTFC_ID = 41’

After the Remove Credit Card Data Application Engine process successfully cleans a record, the value for FS_CCWIPE. CCWIPE_STATUS is C (Complete). If processing terminates abnormally, the value for CCWIPE_STATUS is P (Processing), because the process will not have a way to update the field to something else. If the process sends a Where clause not started by WHERE, then the value for FS_CCWIPE. CCWIPE_STATUS changes to E (Error),

Tokenization is a data security model that replaces sensitive credit card data profiles in the applications and databases. The credit card data profile—which normally consists of the credit card type, credit card number, first name, last name, billing address, phone, and email address—is sent to a third-party host site, which stores and encrypts it. The third-party host creates a token from the profile, and sends the token back to the source PeopleSoft system, where it is saved.

Image: Payment Tokenization Process

In the process of payment tokenization, the credit card data profile—which normally consists of the credit card type, credit card number, first name, last name, billing address, phone, and email address—is sent to a third-party host site (secure storage provider), which stores and encrypts it. The third-party host creates a token from the profile, and sends the token back to the source PeopleSoft system, where it is saved.

Payment Tokenization Process

Note: The system does not support a combination of hosted and traditional implementations. Once the transition to the hosted model has been made, it is not possible to move back to the traditional model.

Use the Credit Card Options Page (CR_CARD_OPT) to set up tokenization and hosted entry. Not all fields will be available for editing. See Setting Up Credit Card Options and Groups for more information.

Profile tokenization and hosted entry are enabled automatically by the credit card data conversion process to indicate that the system supports only hosted entry and storage of credit cards in PeopleSoft Order to Cash applications. If this option is deselected, the system uses only the traditional credit card model; that is, it collects and stores credit card data in the PeopleSoft system.