Testing Paymentech Credit Card Processing

8 Testing Paymentech Credit Card Processing

Learn how to test Paymentech credit card processing in Oracle Communications Billing and Revenue Management (BRM).

Topics in this document:

About Testing Paymentech Credit Card Processing

Paymentech provides connections for testing credit card and direct debit processing, but you must schedule testing times with Paymentech. In addition, you can use the BRM Paymentech simulators to test credit card and direct debit processing without connecting to Paymentech.

Caution:

To test credit card and debit card processing with BRM Paymentech simulators, you must use the account numbers from the test environment only.

Use the payment processing simulator to do the following:

Test the connections in your payment processing configuration.
Test how to handle no response or dropped-line situations.
Test any part of your BRM system that includes BRM-initiated payment processing. For example, you can create credit card accounts and use the simulator to charge them.
Test how the BRM system responds to credit card validation and authorization. You can also test BRM's response to the Visa fraud prevention system (CVV2). For example, you can test how BRM responds when trying to create an account that uses an invalid credit card.

Note:

The Paymentech simulator does not check for the credit card's expiration date.

The payment processing simulator is located in BRM_home/bin. It includes two utilities: answer_s and answer_b.

Caution:

Use the answer_s and answer_b utilities only in test environments. In production environments, uninstall these utilities to prevent sensitive data from being used for verification.

The answer_s utility simulates online transactions.

The answer_s utility automatically simulates the Paymentech HeartBeat application during BRM-initiated payment processing. It verifies that the HeartBeat responses from the Paymentech Data Manager (dm_fusa) are on time and in the correct format when sent to the payment processor (which is the answer_s utility in this case). If not, the utility resets itself to a listen state, which the simulator handles as a socket disconnect and writes the errors to the BRM_home/apps/fusa_server/answer_s.pinlog file, if one is configured. See "Defining the Credit Card Functionality to Test". For information on how to handle the errors, see "Monitoring the Paymentech Connection".
The answer_b utility simulates batch transactions.

You can create test accounts that use a credit card payment method. You must use one of the following pairs of credit card numbers and expiration dates listed in Table 8-1 for your test accounts.

Table 8-1 Example Credit Card Expiration Data

Credit Card Number	Expiration Date
4444 1111 2222 3333	0999
4101 0000 0000 0000	any expiration date

Setting Up the Paymentech Simulator

Setting up the Paymentech simulator involves the following tasks:

Defining the Credit Card Functionality to Test

You can define which area of functionality to test with answer_s and answer_b by editing the Paymentech simulator configuration file (BRM_home/apps/fusa_server/pin.conf). This file includes configuration instructions.

Note:

The entries can be changed interactively because the answer_s and answer_b servers read them from the configuration file at each connection.

Open the simulator configuration file (BRM_home/apps/fusa_server/pin.conf).

Change the response and result codes as necessary. For example:

-   answer_s    v_code   100
-   answer_s    avs      I3
-   answer_s    s_code   M
-   answer_b    v_code   100
-   answer_b    avs      I3

To write processing information to a log file, add the following entries:

-   answer_s    loglevel 3
-   answer_s    answer_S.pinlog
-   answer_b    loglevel 3
-   answer_b    answer_b.pinlog

Save and close the file.

Configuring the Paymentech DM for Testing

To configure the Paymentech DM for testing:

Open the Paymentech DM configuration file (BRM_home/sys/dm_fusa/pin.conf).
Specify at least two dm_fusa back ends.
Change the online_srvr and online_port entries to point to the answer_s utility port number and IP address. By default, the port number is 5678.
Change the batch_srvr and batch_port entries to point to the answer_b utility port number and IP address. By default, the port number is 5679.
Save and close the file.
Stop and restart the Paymentech DM.

Specifying an IP Address for the Paymentech Simulator

Systems configured with multiple network cards use multiple IP addresses for each network card. You can configure the Paymentech simulator to listen to all IP addresses to determine where to connect, or, if you know the IP address (for example, one provided by Paymentech), you can define it in the answer_* utility's pin.conf file.

Open the simulator configuration file (BRM_home/apps/fusa_server/pin.conf).
Do one of the following:
- To enable Paymentech to listen to any IP address located on the machine where the answer_* utility is running, add the following entry to the file:
```
- answer answer_name -
```
- To assign a specific IP address for the answer_* utility, add the following entry to the file:
```
- answer answer_name IP_address
```
  where IP_address is the IP address of the system running the simulator.
  
  For example:
```
- answer answer_name 102.13.112.122
```

Returning Specific Values for Card Type Indicator

You can define specific values to return for Card Type Indicator (CTI).

Open the simulator configuration file (BRM_home/apps/fusa_server/pin.conf).

Add the following parameters:

- answer_s cti_resp USANYNYNYNYN

- answer_b cti_resp USANYNYNYNYN

Save and close the file.

Running the Paymentech Simulators

The Paymentech simulators are in BRM_home/bin.

Note:

Start the simulators before you start the Paymentech DM.

You can start and stop the simulators through the command line:

start_answer &
stop_answer

Simulating Failed Credit Card Transactions

General soft declines are failures that can be retried later with possible success. This includes reasons like insufficient credit limit and other transitory causes. General hard declines are failures that are unlikely to succeed if retried. These include reasons like lost and stolen credit card and chronic payment failures.

To create a hard or soft decline on a credit card that you can use to test resolving failures, do the following:

Create a credit card account.
Stop the answer_b utility and the Paymentech DM.
Open the answer_b configuration file (BRM_home/apps/fusa_server/pin.conf) and change the vcode value to 502.
Restart the answer_b utility. See "Running the Paymentech Simulators".
Restart the Paymentech DM.
Advance the time one month and run pin_bill_day.
Verify that the amount due is not collected.
Verify the PIN_FLD_RESULTS value in the /event/billing/payment/cc object is a 7 (soft decline) or an 8 (hard decline).

Resolving Failed Credit Card Transactions

In addition to the regular responses, answer_b also handles request for response (RFR) file requests by returning the contents of the RFR file specified in the answer_b configuration file.

To test recovery of failed transactions:

Create an account that uses a credit card.
If you have not already created failed credit card transactions, do the following to force a transaction failure:
1. Advance the time one month.
2. Run pin_bill_day.
3. Stop the answer_b utility while billing runs.
Verify the PIN_FLD_RESULTS value in the /event/billing/payment/cc object is a 6 (service unavailable).
Run the pin_clean utility to find transaction IDs for failed transactions.
Edit a fusa send file (fusas*). Enter the transaction IDs for the transactions that have checkpoint records. Fusa send files are located in the TEMP directory.
Enter the file name of the RFR file in the Paymentech simulator configuration file.
Resolve the failed transactions. See "Resolving Failed BRM-Initiated Payment Transactions".