4 Supported Paymentech Functionality

Learn how Oracle Communications Billing and Revenue Management (BRM) supports Paymentech functionality such as account verification and batch processing.

Topics in this document:

• About Paymentech Account Verification

• About Stored-Credential Transactions

• Supported Transaction Types

• Payment Formats and Batch Processing

• Paymentech and International Transactions

• How Paymentech Manager Handles Electronic Check Processing

About Paymentech Account Verification

BRM supports Paymentech's Account Verification feature. Paymentech recommends the use of Account Verification to differentiate validation requests from authorization requests. This is because Visa imposes a penalty for all authorization requests that are neither deposited nor reversed.

Account Verification supports the following Paymentech credit-card payment methods:

• VI for Visa

• MC for MasterCard

Account Verification supports EC for direct debit cards in the United States and Canada.

About Action and Response Reason Codes

BRM sends the following Action Codes to indicate the type of service Paymentech must perform on the transaction:

• To verify a Paymentech-supported direct debit transaction, BRM sends the action code LO and a transaction amount of $0.00. Paymentech validates the transaction against various validation files. If account verification is successful, Paymentech responds with Response Reason Code 101 (Validation passed Paymentech negative file and data edit check).

• To verify a direct debit transaction against a third-party negative file for United States ECP, BRM sends the action code VO and a transaction amount of $0.00. If account verification passes, Paymentech responds with Response Reason Code 102 (Account verification Passed external negative file).

• To verify the account for VISA or MasterCard, BRM sends the action code VF and a transaction amount of $0.00. If account verification is successful, Paymentech responds with Response Reason Code 104 (No Reason to Decline).

For more information, see the Paymentech documentation.

About Stored-Credential Transactions

Credit card networks, such as VISA, MasterCard, Diners, Discover, JCB, and American Express, support the stored credential framework, which allows merchants to use stored credentials for transactions. A stored credential is a cardholder's payment information, such as an account number or a payment token, that is stored by a merchant or its agent, a payment facilitator, or a staged digital wallet operator for processing future transactions. Paymentech card processors also support customer-initiated or merchant-initiated transactions with stored credentials.

BRM supports payment transactions with stored credentials for VISA, MasterCard, Diners, Discover, JCB, and American Express cards. You can also customize BRM to support stored-credential transactions for other card networks. When VISA, MasterCard, Diners, Discover, JCB, and American Express cards are used for payments, the PCM_OP_PYMT_COLLECT opcode sends the following information required for card transactions to the Paymentech Data Manager (dm_fusa) and stores the responses received from the Paymentech DM for future transactions:

• Type of charge, such as recurring, one-time, or installment

• Transaction type

• Information on whether the card details are stored for future use

• A unique ID (TXID) obtained from a previous verify/charge transaction of the same type

You can override the information sent to the Paymentech DM based on your business requirements. If you do not want to store credentials for future transactions, you can remove this information from the input passed to the PCM_OP_PYMT_COLLECT opcode. See "Storing Card Credentials for Future Transactions" in BRM Opcode Guide.

For information about purging card credentials, see "Purging Card Credentials" in BRM Opcode Guide.

Supported Transaction Types

BRM supports the following transaction types to describe the circumstances under which a transaction takes place.

• A transaction type 1 indicates a single mail/telephone order transaction where the cardholder is not present at a sales location and completes the sale through the phone or mail. The transaction is not for recurring services and does not include sales that are processed through an installment plan.

• A transaction type 2 indicates a recurring transaction that represents an arrangement between a cardholder and a sales location where transactions are going to be on a periodic basis.

• A transaction type 7 indicates a channel encrypted transaction between a cardholder and a seller. The transaction was completed through the internet, using a form of Internet security such as Secure Sockets Layer (SSL) but authentication was not performed.

The BRM Paymentech Manager Configuration file stores "" (blank) as the default value for the transaction type field. Configure the BRM_home/sys/dm_fusa/pin.conf configuration file to provide the required transaction type.

For information on transaction types in the online processing detail record, see the Paymentech documentation.

Payment Formats and Batch Processing

Paymentech batch processing supports the following:

• A refund file can be in 120-byte format, even if the corresponding authorization/deposit was completed in 96-byte format.

• The Request for Response (RFR) header record must be in the same byte format as the response file. That is, to pick up a 96-byte response file, Paymentech expects a 96-byte RFR header record; to pick up a 120-byte response file, Paymentech expects a 120-byte RFR header record.

Consider the following points about batch processing functionality:

• If you use the 120-byte message format, you must complete the certification for batch processing for Paymentech before you allow customers to log in to the production system. For more information about obtaining the certification, see the Paymentech website.

• For the UK Domestic Maestro (Switch/Solo) card (MOP = SW) with batch processing functionality, Paymentech expects the card issue date and the issue number (if present) in the UK Domestic Maestro extension record.

• BRM does not support creating accounts by using UK Domestic Maestro (Switch/Solo) card type. For existing subscribers, transactions other than the refund (Action Code = RF) are not supported.

• To enhance your existing payment processing with Paymentech's Account Verification feature, before doing so, ensure that all preauthorized payments are deposited or reversed.

For more information about Paymentech's 120-byte batch format, see the Paymentech documentation.

Paymentech and International Transactions

You can use Paymentech for credit card processing transfers outside the United States. Paymentech supports different currencies for different credit cards.

The Paymentech Address Verification System (AVS), which verifies customer addresses at time of purchase, is turned off if any non-ASCII encoding is entered in the address fields. You can customize the use of AVS further by changing some policy opcodes.

Paymentech supports only US and Canadian direct debit accounts. The routing number must be 9 digits and the checking account number can be up to 17 digits.

How Paymentech Manager Handles Electronic Check Processing

BRM Paymentech Manager processes all electronic check processing (ECP) transactions in accordance with National Automated Clearing House Association (NACHA) operating rules.

BRM Paymentech Manager provides Account Verification functionality for transactions in batch mode from any custom client to Paymentech. For more on Account Verification functionality and the support for online transactions, see "About Paymentech Account Verification".

Valid entries for ECP Authorization Method are:

• A. Accounts Receivable. When ECP Authorization Method is set to A, values for Check Serial Number and Image Reference Number are mandatory.

• I. Internet.

• P. Point of Purchase. When ECP Authorization Method is set to P, values for Check Serial Number, Terminal City, Terminal State, and Image Reference Number are mandatory.

• T. Telephone.

• W. Written.

BRM Paymentech Manager supports these authorization method values and the corresponding information as required by Paymentech.

If you customize electronic check processing with Paymentech, when ECP Authorization Method is set to A or P:

• Connection Manager ignores any input you provide in the fields that Paymentech mandates for Check Serial Number, Terminal City, Terminal State, and Image Reference Number.

• The Check Serial Number, Terminal City, Terminal State, and Image Reference Number mandatory fields are blank in the input BRM Paymentech Data Manager receives from Connection Manager.

In BRM, when you customize electronic check processing for end-to-end payment operations with Paymentech, avoid setting ECP Authorization Method to A or P.