Processing Credit Card and Debit Card Payments with Paymentech

2 Processing Credit Card and Debit Card Payments with Paymentech

Learn how Oracle Communications Billing and Revenue Management (BRM) uses Paymentech to process your customers' credit card and direct debit payments.

Topics in this document:

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.

About Credit Card Validation and Authorization

Credit card validation validates a customer's address by checking the ZIP code and street address. Credit card validation occurs during account creation, and when customers change their credit card number. If you use the Address Verification System (AVS), Paymentech gives you a discount for each credit card transaction charge.

Note:

AVS supports addresses in the United States and Canada only. For information about changing the AVS validation results, see "Changing How BRM Handles Paymentech Address Validation Return Codes".

Credit card authorization validates the customer's credit card by checking the card number, expiration date, credit limit, and so forth. Authorization occurs at the following times:

At account creation, or when customers change their payment method to a credit card payment.

This type of authorization does not charge the customer's account balance. The payment is recorded in the BRM database, and the balance in the account is adjusted, but the deposit is made later by the "pin_deposit" utility.
During billing, the pin_collect utility authorizes payments and deposits them.
If there are charges during account creation, such as a purchase fee.

Credit card validation and authorization occur in the same transaction, but BRM handles one at a time.

BRM sends a validation request with an authorization to charge $1.00.

Note:

The validation process requires a monetary charge. BRM issues an authorization for $1.00 so that only $1.00 is reserved on the customer's credit card if the AVS request passes.

The credit card processor returns a validation code and an authorization code. BRM ignores the authorization code and uses the validation code to determine whether the address validation passed. For example, by default an address validation fails if the 5-digit ZIP code is wrong.

Note:

Because BRM ignores the authorization, the customer is not charged $1.00.

If the address validation fails, the next step, authorization, does not occur.

Note:

If the Paymentech DM detects non-ASCII data in the address fields during the validation step, the result of the validation request is ignored. This has the same effect as not performing the validation check. This can occur when characters from another language are sent.
BRM sends another validation request with an authorization to charge for an actual amount, such as a purchase fee.

The credit card processor returns a validation code and an authorization code. This time, BRM ignores the validation code and uses the authorization code to determine whether the authorization passed.

About Setting Up Payment Processing With Paymentech

To enable BRM-initiated payment processing for Paymentech:

Install the Paymentech Manager software. You typically install this at the same time as the rest of the BRM software. If you did not, see "Installing Individual BRM Components" in BRM Installation Guide.
Contact Paymentech to establish a link with Paymentech. See "Exchanging Connection Information With Paymentech".
Edit the BRM_home/sys/dm_fusa/pin.conf file to configure the Paymentech DM to connect to Paymentech. See BRM System Administrator’s Guide for information on configuring DMs.
Configure merchant accounts. See "Setting Up Merchant Accounts".
Set up BRM to process PINless debit payments. See "Configuring PINless Debit Payment Processing".
Set up the Paymentech HeartBeat application. See "Monitoring the Paymentech Connection".
Specify Paymentech configuration options; for example, enabling direct-debit processing and enabling fraud protection. See "Paymentech Configuration Options".
Configure performance options. See "Configuring Paymentech Processing Performance".
Test the installation. See "Testing Paymentech Credit Card Processing".

Exchanging Connection Information With Paymentech

Before you can connect BRM to Paymentech, you need to exchange connection information.

Note:

Even if you already use Paymentech for credit card processing, you must plan for a setup and testing period for Paymentech direct debit.

Information You Need from Paymentech

You need the following information from Paymentech:

The IP address and port for the Paymentech online server (the server used for creating accounts) and batch server (the server used for handling regular payments).
The presenter ID and password, and the submitter ID and password.
Merchant account numbers for each currency you support. The same sets of merchant account numbers can be used for both credit card and direct debit. See "Setting Up Merchant Accounts".

Information Paymentech Needs from You

Table 2-1 lists the information that Paymentech needs from you.

Table 2-1 BRM Default Values for Paymentech

Paymentech Information	BRM Default
The IP address and port number for the machine running the Paymentech Data Manager (dm_fusa).	None. This is required only to use the Paymentech HeartBeat application, which is integrated with the Paymentech Data Manager. For more information, see "Monitoring the Paymentech Connection".
Is this for an existing Presenter ID (PID)?	No
What is the application software that formats the file?	Written by in-house programmers
What is the communications software that sends the file?	Customized by the software vendor
What is the online data communications protocol used to send the online authorization transaction?	TCP/IP Berkley Socket Interface
What is the batch data communications protocol used to send the batch file?	TCP/IP Berkeley Socket Interface
What online format will you use to send online authorizations?	For information about compatible Paymentech online processing format specifications, see "Additional BRM Software Requirements" in BRM Compatibility Matrix.
Will you load balance online authorizations between Paymentech's data centers, or will you use one data center as primary and one as backup?	Primary and Backup
What batch format will you use to send batch files?	For information about compatible Paymentech batch processing format specifications, see "Additional BRM Software Requirements" in BRM Compatibility Matrix.
Will you receive the batch reply file by sending an RFR (Request For Response) record or not?	1 Call (IA) - No RFR record sent to pick up the reply file.
Will you send authorizations separately from deposits OR will you send conditional deposits that will result in a deposit upon authorization approval?	Separate authorizations and deposits and conditional deposits.
What will the average size of your files be in production? (How many records/transactions?)	None. This number should be based on your company's projected customer account creation growth and billing rate.
What is the projected submission schedule?	Daily.
Number of times per day?	Once.
What Paymentech functionality do you intend to test?	This list reflects a typical prepaid services company. Online Credit Card Authorization Online Electronic Check Processing (ECP) Verification PINless Direct Debit Purchase Authorizations Batch Electronic Check Processing (ECP) Validate & Deposit Batch Deposits Batch Conditional Deposits (for authorization & settlement) Batch Refunds Full AVS (Address Verification Service) Zip only AVS No AVS Visa CVV2 Amex CID MasterCard CVC2 Discover CID ECI Indicator (also called Transaction Type) International Currencies (specify) Merchant Descriptor (requires Risk approval) Switch/Solo Cards

Configuring Paymentech Processing Performance

Configure the following options:

To improve performance during account creation, see "Increasing Account Creation Speed When Paymentech Is Offline" in BRM Managing Customers.

Handling Concurrent Online Paymentech Requests

You can increase billing performance by using the fusamux program. Because Paymentech allows only a single connection per customer, the fusamux program takes multiple DM backends and bundles them into a single connection. This enables BRM to process multiple transactions and send them to Paymentech in a single connection.

Without fusamux, the Paymentech DM connects directly to Paymentech. When you use fusamux, the Paymentech DM connects to the fusamux application, which in turn connects to Paymentech. When you use fusamux, you must change entries in the Paymentech DM to point to fusamux instead of pointing to Paymentech.

To configure the fusamux daemon:

Open the Paymentech DM configuration file (BRM_home/sys/dm_fusa/pin.conf).
Edit the fusamux entries:
- Set the fusamux online_port and fusamux online_srvr entries to point to the Paymentech online server IP address and port number.
- Set the fusamux_port entry to the port on which the fusamux daemon listens.
- Set the dm_fusa online_port entry to the port on which fusamux listens.
- Set the dm_fusa online_srvr entry to point to the fusamux IP address.
- Set the dm_fusa qm_n_be entry to a number between 4 and 8.
Save the file.
Stop and restart the Paymentech DM.

Setting the Connection Timeout Length and Retries

If you have problems connecting to Paymentech, increase the connection timeout length and number of retries:

Open the Paymentech DM configuration file (BRM_home/sys/dm_fusa/pin.conf).
Increase the number of times that dm_fusa retries a connection to Paymentech:
```
- dm_fusa connect_retrys value
```
The default is 2, but you can enter any number.
Change the amount of time, in seconds, that dm_fusa waits for a response from Paymentech for online authorizations:
```
- dm_fusa fusa_timeout value
```
The default is 600.
Change the amount of time, in seconds, that dm_fusa waits for a response from Paymentech for batch scripts:
```
- dm_fusa fusa_batch_timeout value
```
The default is 600.
Save the file.
Stop and restart the Paymentech DM.

Monitoring the Paymentech Connection

The Paymentech HeartBeat application is a background process that checks the connectivity between BRM and Paymentech. When the Paymentech DM successfully connects to Paymentech, Paymentech acknowledges the connection by sending a HeartBeat message. The Paymentech DM responds by sending back a HeartBeat message to Paymentech.

If Paymentech does not receive a response message from BRM within 120 seconds of sending a request message, or if the response message is incorrect, Paymentech resets the connection to a listen state. BRM handles this as a socket disconnect and recovers accordingly. Errors are written to the BRM_home/sys/dm_fusa/dm_fusa.pinlog file.

Note:

If BRM stops receiving HeartBeat messages and is in the middle of a transaction, the connection will not disconnect.

To initialize the HeartBeat application, provide Paymentech with the IP address and port number of the machine running the Paymentech Data Manager (dm_fusa). The HeartBeat application will run automatically each time you process BRM-initiated payments.

The following entry is a typical HeartBeat request and response pair:

Received (20) chars: Heartbeat request [HO19999999813123258^M]
Sending Heartbeat response [HI19999999813123300^M]

If these entries are missing or are not continuous for the duration of the connection with Paymentech, work with Paymentech to troubleshoot why the connection was lost or the HeartBeat application was not enabled from their end.

Note:

If a connection is made between the DM and Paymentech, and Paymentech does not initiate the HeartBeat messages, BRM assumes there is no HeartBeat application support and continues with payment processing as normal.

If an error occurs with the HeartBeat application during payment simulation, an error message similar to the following is written to the BRM_home/apps/fusa_server/answer_s.pinlog file:

Received (20) chars: Heartbeat response Validation failed in process_it() : HI19999999813123300^M

In order for this message to be logged, the payment processing simulator configuration file (BRM_home/apps/fusa_server/pin.conf) must contain the following entries:

- answer_s loglevel 3
- answer_s logfile answer_s.pinlog

For more information, see "Testing Paymentech Credit Card Processing".

If a socket disconnect occurs with the payment processing simulator and no online transactions are occurring, errors similar to the following are written to the answer_s.pinlog file:

E Tue Aug 08 10:51:24 2006  elm  dm_fusa:2994  qbe_fusa.c(1.13):645 1:elm:dm_fusa:2991:1:0:1155059471:0
Socket read error in dm_fusa_respond_heartbeat() recv() returned (0)
E Tue Aug 08 10:51:24 2006  elm  dm_fusa:2994  qm_back.c(7):299 1:elm:dm_fusa:2991:1:0:1155059471:0
Error(7) processing heartbeat monitor fd(5)