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 Ssimulator 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.

Using SFTP for Testing Batch Payment Transactions

You can configure the Paymentech Data Manager (dm_fusa) to use SFTP for sending batch payment transactions to the answer_b server. Batch payment transactions include batch payments, multiple verifications, multiple authorizations, deposits, and refunds.

To test batch payment transactions through SFTP, follow these steps:

Setting Up Authentication Between dm_fusa and answer_b

Set up authentication between dm_fusa and answer_b by generating a public key on the dm_fusa machine and copying it to your Paymentech Simulator server.

To set up authentication between dm_fusa and answer_b:

Generate an RSA public key.

For example, this command generates an RSA public key with a key length of 4096 bits:
```
ssh-keygen -t rsa -b 4096
```
Copy the RSA public key to the Paymentech Simulator server:
```
ssh-copy-id -i pathPublicKey  userName@hostNameSimulator
```
where:
- pathPublicKey is the path and file name of the public key generated in step 1.
- userName is name of the dm_fusa user.
- hostNameSimulator is the host name of the Paymentech Simulator server.

Verify the connection:

sftp -i pathPublicKey  userName@hostNameSimulator

Configuring Your SSH Client Configuration File for answer_b

Connect dm_fusa to the Paymentech Simulator server by setting the following in the SSH client configuration file, located at ~/.ssh/config:

Host CServer   
   HostName sftpHost      
   User userName   
   Port portNumber    
   IdentityFile pathPrivateKey

where:

sftpHost:Host name of the Paymentech's SFTP server.
userName: User name for accessing the Paymentech SFTP server.
portNumber: SFTP port number for the Paymentech server.
pathPrivateKey: Path and file name of the private key that matches the public key you generated in "Setting Up Authentication Between dm_fusa and answer_b".

Testing Batch Payment Transactions Using SFTP

You can configure the Paymentech DM (dm_fusa) to test how it sends batch payment transactions to the Paymentech Simulator. Batch payment transactions include batch payments, multiple verifications, multiple authorizations, deposits, and refunds.

To test batch payment transactions using SFTP:

Open the Paymentech DM configuration file (BRM_home/sys/dm_fusa/pin.conf).
Set the connection type between dm_fusa and Paymentech Simulator for batch payment transactions:
```
- answer_b batch_proto sftp
```

Uncomment and configure the following entries:

- answer_b sftp_host hostName
- answer_b sftp_pkey_pwd passPhrase
- answer_b sftp_indir inputPath
- answer_b sftp_outdir outputPath

Table 2-2 describes the values to use with the pin.conf entries.

Table 8-2 Variables for the pin.conf Entries

Parameter	Description
hostName	The host section name in the SSH client configuration file.
passPhrase	The SFTP private key passphrase for the answer_b server. If omitted, the passphrase is retrieved from the wallet.
inputPath	The absolute path to the input directory where batch files are uploaded to the answer_b server using SFTP.
outputPath	The absolute path to the output directory where response files are downloaded from the answer_b server using SFTP.

Save your changes.
Stop and restart the Paymentech DM for the settings to take effect.

Using TCP/IP for Testing Batch Payment Transactions

To configure the Paymentech DM to test batch payment transactions over TCP/IP:

Open the Paymentech DM configuration file (BRM_home/sys/dm_fusa/pin.conf).
Set the connection type between dm_fusa and Paymentech Simulator for batch payment transactions:
```
- answer_b batch_proto socket
```
Update 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 5678.
```
- answer_b batch_srvr batchSrvr 
- answer_b batch_port batchPort 
```
Save and close the configuration 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.

To specify an IP address for the Paymentech Simulator:

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 192.0.2.150
```

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.
In the answer_b configuration file (BRM_home/apps/fusa_server/pin.conf), change the v_code entry to 502:
```
- answer_b v_code 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 directories you specify in the dm_fusa pin.conf file. The answer_b sftp_indir entry specifies the input directory, and the answer_b sftp_outdir entry specifies the output directory.
(For SFTP only) 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".