Paymentech Configuration Options

3 Paymentech Configuration Options

Learn how to configure how Paymentech processes credit card and direct debit data in Oracle Communications Billing and Revenue Management (BRM).

BRM includes an integration with the Paymentech payment card processor.

Note:

The initials FUSA are sometimes used to represent Paymentech in BRM file names. For example, the Paymentech Data Manager (DM) is named dm_fusa.

Topics in this document:

Adding Soft Descriptor Information to Customer Statements

You can use soft descriptors to add information to customers' credit-card or checking-account statements. You can add to these statements:

Your "doing business as" (DBA) name
Charge offer name
A customer service phone number (instead of your headquarters city)

Visa gives a discount, the Visa PS2000 Direct Marketing interchange rate, to companies that provide a customer service number in this manner.

Use this format for DBA name, charge offer name, and phone entries:

- dm_fusa     sd_merchant_dba          DBA
- dm_fusa     sd_merchant_pdt          ChargeOfferName
- dm_fusa     sd_merchant_phone        800-XXXXXXX

On the customer's statement, an asterisk is used to separate the DBA name and charge offer name. If the entry is longer than 22 characters (including spaces), it is truncated on the statement. In this 22-character-maximum line, the asterisk delimiter can appear in position 4, 8, or 13.

For example, if the merchant name is psi, the DBA name is BRM, the pdt (charge offer) is InternetSVC, and customer service number is 800-555-1234, use the following entries:

- dm_fusa   sd_psi_dba     BRM
- dm_fusa   sd_psi_pdt     InternetSVC
- dm_fusa   sd_psi_phone   800-555-1234

To add soft descriptor information:

Open the Paymentech DM configuration file (BRM_home/sys/dm_fusa/pin.conf).
Turn on soft descriptors by changing the descriptor flag value to 1:
```
- dm_fusa   sd_descriptor_flag     1
```
Change the other related entries according to the instructions in the file.
Save and close the file.
Stop and restart the Paymentech DM.

To create multiple DBA names, charge offer names, and phone number entries, you must customize the PCM_OP_PYMT_POL_PRE_COLLECT policy opcode. See "Customizing the Minimum Amount to Charge" in BRM Opcode Guide.

Changing How BRM Handles Paymentech Authorization Return Codes

The Paymentech authorization codes used by BRM are listed in BRM_home/sys/dm_fusa/fusa_codes. This file maps Paymentech authorization codes to BRM result codes.

The fusa_codes file is not a complete list, but it includes the most common codes returned by Paymentech. If a Paymentech code is not included in the list, it is mapped to a hard decline.

You can change the mappings or add new mappings by editing the fusa_codes file.

Note:

You can map a Paymentech code to any BRM result code except CHECKPOINT.

Open BRM_home/sys/dm_fusa/fusa_codes.
Use the instructions in the file to edit the file.
Save the file.
Stop and restart the Paymentech DM.

Changing How BRM Handles Paymentech Address Validation Return Codes

Paymentech provides return codes when verifying customer addresses. AVS validates only credit cards with addresses in the United States and Canada. To change how BRM responds to validation return codes, customize the PCM_OP_PYMT_POL_VALIDATE policy opcode. See "Processing Paymentech Address Validation Return Codes" in BRM Opcode Guide.

Specifying the Batch Mode Encryption Key

If you process multiple credit card transactions at a time, batch mode processing uses temporary send and receive files to capture records to and from Paymentech. To prevent any misuse of the temporary batch files, sensitive data such as the card number and security code is encrypted.

You specify the encryption method and key in the Paymentech configuration file. The default encryption method is OZT. For more information, see "Encrypting Data" in BRM Developer's Guide.

Note:

You should change the encryption key regularly. Before changing the encryption key, ensure that all pin_recover operations using the -rfr and -resubmit parameters that depend on the current encryption key are completed.

To specify the encryption key:

Open the Paymentech DM configuration file (BRM_home/sys/dm_fusa/pin.conf) in a text editor.
Edit the -crypt entry:
```
- crypt Encrypt_method| BRM_home/lib/Encryption_library "Secret_key"
```
where:
- Encrypt_method is the type of encryption method, which is either aes or ozt.
- Encryption_library is the path and file name of the encryption library. The prefix for the library is lib for Solaris and Linux, or null "" for Windows. The extension for the library is .so for Solaris and Linux, and .dll for Windows.
- Secret_key is your encrypted AES or OZT key.
For example:
```
- crypt ozt|BRM_home/lib/libpin_crypt_ozt4dm64.so "&ozt|encryptedKey" 
```
Note:

You can copy and paste the key or you can type it.
Save and close the file.
Stop and restart the Paymentech DM.

Obtaining Card Type Indicator Information from Paymentech

You can configure BRM to request Card Type Indicator (CTI) details from Paymentech, which specify the type of card that consumers use for payments.

To set up dm_fusa to request CTI details during account creation with online and batch transactions, customize the PCM_OP_PYMT_POL_SPEC_VALIDATE and PCM_OP_PYMT_POL_PRE_COLLECT policy opcodes according to the comments provided in the source files. When Paymentech returns CTI details, BRM stores it in the PIN_FLD_TYPE_STR field of /event/billing/charge/cc and /event/billing/validate/cc objects in the BRM database.

Note:

Paymentech supports two versions of CTI record: 01 and 02. BRM supports version 02 because it is the superset of version 01.
Batch transactions are used only for deposits and conditional deposits.

See "BRM-Initiated Payment Processing" in BRM Opcode Guide for more information.

If BRM sends the Format Indicator and the MOP does not equal AX, CR, CZ, DD, DI, IM, JC, MC, MR, VI, or VR, Paymentech rejects the transaction with Response Reason Code 241 (Illegal Action).

If this Format Indicator is sent and Action Code does not equal AU, BI, PP, or VF, Paymentech rejects the transaction with Response Reason Code 225 (Invalid Field Data).

If this Format Indicator is sent, the MOP equals AX, and the Action Code does not equal PP, Paymentech rejects the with Response Reason Code 225 (Invalid Field Data).

Since action code PP is not used in BRM, customizations enabling Card Type Indicator must make sure that CTI is not sent for Amex Cards.

Requiring Additional Protection against Credit Card Fraud

Paymentech offers additional fraud prevention using Visa CVV2 numbers and American Express CID numbers.

By default, the CVV2 and CID numbers are considered to be optional when CSRs add or change a customer's credit card information. To require the CVV2 or CID number as part of account creation, change the following fields in the Connection Manager (CM) configuration file (BRM_home/sys/cm/pin.conf).

Note:

For security reasons, the CVV2 and CID numbers are stored in BRM with a NULL value. If you have the cvv2_required entry enabled, the information is sent directly to Paymentech for validation without being stored in the database. (Even if your CM does not require this additional fraud prevention, Paymentech still accepts the information if it is sent).

To require Visa CVV2:

Open the Connection Manager (CM) configuration file (BRM_home/sys/cm/pin.conf).
Change the value in the following entry from the default, 0, to 1:
```
- fm_pymt_pol cvv2_required 1
```
Save the file.

You do not need to restart the CM to enable this entry.

To require American Express CID:

Open the Connection Manager (CM) configuration file (BRM_home/sys/cm/pin.conf).
Change the value in the following entry from the default, 0, to 1:
```
- fm_pymt_pol cid_required 1
```
Save the file.

You do not need to restart the CM to enable this entry.

If these entries are missing from the CM configuration file, CVV2 and CID are not required for account creation. For more information on how BRM handles these numbers, see "CVV2/CID Fraud Prevention Functionality" in BRM Opcode Guide.

Specifying the Maximum Number of Digits Allowed for CVV2 Verification

By default, Customer Center and BRM accept a maximum of three CVV2 digits when validating a customer's credit card.

To change the maximum number of CVV2 digits that can be entered, perform the following:

For Customer Center: Use the Configurator application provided with Customer Center SDK to modify the maximum number of CCV2 digits allowed by Customer Center. You enter the information in the CVV2 Number - maximum digits allowed field of the Payment Configurator.
For BRM server: Customize the PCM_OP_CUST_POL_VALID_PAYINFO policy opcode to validate the number of digits passed in the PIN_FLD_SECURITY_ID input flist field of the PIN_FLD_CC_INFO array.

Enabling Paymentech Direct Debit Processing

Depending on the choices made during installation, the settings for direct debit might not be turned on. (Turned off is the default.)

Open the Connection Manager (CM) configuration file (BRM_home/sys/cm/pin.conf).

Change the value of the direct debit entries:

For example:

- fm_pymt_pol dd_validate 1
- fm_pymt_pol dd_revalidation_interval 3600
- fm_pymt_pol dd_collect 1

Save the file.

You do not need to restart the CM to enable this entry.