2 About BRM-Initiated Payment Processing

This chapter describes Oracle Communications Billing and Revenue Management (BRM)–initiated payment processing, and provides information on how to set it up in your BRM system.

For information on using Paymentech to process credit card or direct debit payments, see "Configuring BRM-Initiated Payment Processing".

For information about handling externally initiated payments, such as checks or cash, see "Managing Externally Initiated Payments".

About BRM-Initiated Payments

A BRM-initiated payment is a payment that requires no action from the customer. The customer's credit card or checking account is charged by your online payment processor or automated clearing house (ACH). The customer's account balances are updated automatically and any outstanding payments are closed.

BRM supports direct debit of funds by using Paymentech and all of the credit cards supported by Paymentech. It also supports debit cards that do not require a personal identification number (PIN) to perform transactions. See your Paymentech documentation for the latest information.

When you select direct debit payment support during installation, the direct debit payment method is defined in the BRM system, and direct debit is available as a payment method when creating or modifying an account. For more information about direct debit processing, see "Implementing a Direct Debit Payment Method".

BRM also supports Single Euro Payments Area (SEPA) Direct Debit and SEPA Credit Transfer as BRM-initiated payments. For more information about SEPA payment processing, see "About SEPA Payment Processing".

Figure 2-1 shows how BRM handles BRM-initiated payments:

Figure 2-1 BRM-Initiated Payments

Description of ''Figure 2-1 BRM-Initiated Payments''

About Transactional and Nontransactional Payment Processing

BRM-initiated payment processing is either transactional or nontransactional:

• Transactional: Payments that occur in their entirety in one communication session between BRM and a payment processor. The communication session is bidirectional and occurs entirely online. By default, all BRM-initiated payments are processed this way.

• Nontransactional: Payments that occur in two or more communication sessions between BRM and a payment processor. The initial session occurs online when BRM sends a payment request to the payment processor. Subsequent sessions can occur online or offline; for example, processing service personnel may send payment information to you over a network or on CDs. BRM-initiated payments are processed this way whenever the initial communication is interrupted; for example, the processing system may have a system failure, or missing data may need to be supplied manually.

About Account Verification for Online Processing

BRM supports Paymentech's Account Verification function in the BRM-initiated payment processing for Paymentech. This Account Verification functionality complies with Paymentech Online version 7.4 Revision 3. For information, see the OnLine Processing Format Specification version 7.4 Revision 3 technical specification on the Chase Paymentech library Web site.

Paymentech recommends the use of Account Verification to differentiate credit card/account validation requests from authorization requests. This is because Visa imposes a penalty for all authorization requests that are neither deposited nor reversed.

The Account Verification function supports the following Paymentech methods of payment for credit cards:

• VI, the entry used to indicate Visa as the method of payment.

• MC, the entry used to indicate MasterCard as the method of payment.

The account verification function supports EC as the method of payment entry for direct debit cards in the United States and Canada.

Prerequisites

To use Paymentech's 120-byte batch request/response format, you must complete the required certification with Paymentech for online payment processing. This step should be completed before you allow customers to log in to a production system. You can obtain more information on obtaining the required certification from the Chase Paymentech Web site at:

http://www.chasepaymentech.com

If you plan to enhance your existing payment processing with Paymentech's Account Verification function, then before you do so, ensure that all pre-authorized payments are deposited or reversed.

About Action and Response Reason Codes

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

• When a transaction needs validation only, Paymentech Manager sends the action code LO and a transaction amount is $0.00.

  Paymentech in turn, validates this direct debit transaction against an Automatic Clearing House (ACH) eligibility file, Notification of Change (NOC) file, and Electronic Check Processing (ECP) internal negative file for Canadian ECP.

  If the account verification is successful for a transaction with an LO action code and the amount set to $0.00, Paymentch responds with a Response Reason Code 101 (Validation passed Paymentech negative file and data edit check).

• When the Paymentech Manager must verify the direct debit transaction against a third-party negative file for United States ECP, it sends the action code VO and a transaction amount $0.00.

  If the account verification of a transaction with an VO action code for an amount set to $0.00 passed the third-party negative file for United States ECP, Paymentech responds with a Response Reason Code 102 (Account verification Passed external negative file).

• When the Paymentech Manager must verify the account for VISA or MasterCard, it sends the action code VF and a transaction amount $0.00.

  If the account verification of a transaction with an VF action code for an amount set to $0.00 is successfully approved, Paymentech responds with a Response Reason Code 104 (No Reason to Decline).

For more information, see the 120-Byte Batch Processing Versions 2.0.0-3.0.0 Rev 2 Addendum in Support of Account Verification technical specification on the Chase Paymentech library Web site.

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 merchant 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 merchant where transactions are going to be on a periodic basis.

• A transaction type 7 indicates a channel encrypted transaction between a cardholder and a merchant. 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 OnLine Processing Format Specification version 7.4 Revision 3 technical specification on the Chase Paymentech library Web site.

About Credit Card Transactions

To process credit card payments and authorizations, BRM uses two types of credit card transactions: online and batch:

• Online transaction handles a single transaction, for example, a credit card validation or authorization.

  To process online transactions for Paymentech, BRM creates a permanent socket connection to the credit card processor.

• Batch transaction handles more than one transaction at a time. You use batch processing when you run the "pin_collect" and "pin_deposit" billing utilities.

  To process batch transactions for Paymentech, BRM creates a new socket connection for each batch. When the batch has been sent, the connection is closed.

About Merchant Numbers and Account Identifiers

To determine where to deposit your BRM-initiated payments, the payment processors use a merchant ID and a merchant number. Your payment processor assigns your merchant numbers.

If you collect payments in multiple currencies, you need a merchant ID and merchant number pair for each currency.

Note:

The Paymentech Data Manager (DM) determines the type of credit card from the credit card number.

A merchant ID consists of the following parts:

• The merchant identifies a type of account. In most cases, all of your accounts use the same merchant. The default merchant is the first merchant listed for the payment processor, which is defined in the /config/ach storable object.

• The ISO currency code, such as 840 for US Dollars.

Paymentech Merchant Information

The following example shows merchant IDs and numbers in the Paymentech Data Manager (DM) configuration file. In this example, mid_ispname_840 is the first merchant ID, and 050505 is the first merchant number.

Note:

There is a merchant ID for each currency, and each merchant ID is mapped to a different merchant number.

-   dm_fusa   mid_ispname_840     050505
-   dm_fusa   mid_ispname_250     050506
-   dm_fusa   mid_ispname_276     050507

Using More Than One Merchant

You might use more than one merchant if you separate deposits based on payment method (for example, if you deposit payments to a third-party service provider).

If you use multiple merchants, each merchant must be entered in the following files:

• The payment processor configuration file (BRM_Home/sys/data/pricing/example/pin_ach). You specify merchants for each processor and then load the file into the BRM database. See "Setting Up Merchants and Payment Processors".

• The payment processor Data Manager (DM) configuration file (for example, BRM_Home/sys/dm_fusa/pin.conf).

• The Connection Manager (CM) configuration file (BRM_Home/sys/cm/pin.conf). In this file you specify a connection to the database for each payment processor Data Manager.

About Credit Card Validation and Authorization

Credit card validation validates the customer's address by checking the ZIP code and street address. Credit card authorization validates the customer's credit card by checking the card number, expiration date, credit limit, and so forth.

By default, validation occurs during registration, and when a customer changes their credit card number.

Authorization occurs at the following times:

• During billing, the pin_collect utility authorizes payments and deposits them. (A credit card deposit is also called a settlement.)

• If there are charges during registration, for example, cycle forward fees or purchase fees.

• When a customer service representative (CSR) changes an account payment method by using Customer Center.

About Credit Card Validation

If you use the Address Verification System (AVS), Paymentech gives you a discount for each credit card transaction charge. By default, BRM sends the customer's name, address, and ZIP code for validation. However, you can get the AVS discount even if you only supply the ZIP code.

Important:

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

About Credit Card Authorization

Credit card authorizations made during registration or later by using Customer Center do 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 when you run billing.

The Credit Card Validation and Authorization Process

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

1. BRM sends a validation request along 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 if 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 take place.

   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.

2. BRM sends another validation request along with an authorization to charge for an actual amount, for example, 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 if the authorization passed.

You can change how BRM responds to validation and authorization return codes. For more information about how BRM handles Paymentech address validation and authorization return codes, see:

• Changing How BRM Handles Paymentech Address Validation Return Codes

• Changing How BRM Handles Paymentech Authorization Return Codes

About Credit Card Tokenization

Credit card tokenization is a secure method of storing credit and debit card data. It replaces the credit and debit card numbers with random identifiers, referred to as tokens. These tokens are typically of the same length as the credit or debit card numbers and includes the last four digits of the credit or debit card numbers. This enables customer service representatives (CSRs) to identify credit and debit cards.

You can enable credit card tokenization in BRM by updating the Paymentech DM configuration file (BRM_Home/sys/dm_fusa/pin.conf). See "Enabling Credit Card Tokenization" for more information.

When credit card tokenization is enabled, BRM requests Paymentech for tokens and stores only the tokens in the BRM database. These tokens are then used for any BRM-initiated payments instead of the actual card numbers. The actual card numbers and their mapping to the tokens are stored securely in Paymentech. Tokens are valid only between the merchant system and the credit card processor. Therefore, these tokens can be transmitted safely without the risk of exposing the credit or debit card data.

Credit card tokenization occurs:

• During account registration

• When credit cards are used for one-time payments

• When customers change their credit or debit card number

• When customers want to change to the credit card payment method

Use the pin_cc_migrate utility to replace the existing credit or debit card numbers in the /payinfo/cc objects with tokens. See "About Replacing Credit Card Numbers with Tokens" for more information.

The Credit Card Tokenization Process

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

1. BRM sends the credit or debit card number along with the validation and authorization request to Paymentech.

   Note:

   When credit card validation is disabled, BRM sends the credit or debit card number along with a token-only request to Paymentech.

2. Paymentech returns a token along with the validation and authorization codes to BRM.

3. BRM stores the token, instead of the credit or debit card number, in the /payinfo/cc, /event/billing/charge/cc, or /event/billing/validate/cc objects.

   Important:

   If the credit card validation fails, tokenization does not take place. In this case, a string value (asterisks (******) followed by the last four digits of the credit card) is stored in the /event/billing/validate/cc object. This string value can be used to authenticate a credit or debit card, but cannot be used for any transaction.

About Replacing Credit Card Numbers with Tokens

When you enable credit card tokenization, the new credit and debit card numbers entered in Customer Center; for example, during account registration, are automatically replaced with tokens. To replace the existing credit or debit card numbers stored in the BRM database with tokens, use the pin_cc_migrate utility. See "pin_cc_migrate" for information on the pin_cc_migrate utility.

To replace the credit or debit card numbers with tokens:

Note:

If you are migrating legacy credit card data into the BRM database, migrate the data before running the pin_cc_migrate utility. See "About Migrating Credit Card Information from Legacy Databases" for more information.

1. Enable credit card tokenization in BRM. See "Enabling Credit Card Tokenization" for more information.

2. Ensure that the outstanding payments for credit card accounts are closed. See "About Depositing BRM-Initiated Payments" for more information.

3. Run the pin_cc_migrate utility. See "Replacing Credit Card Numbers with Tokens" for more information.

4. (Optional) Purge the old credit card event and audit trail objects that contain the credit card numbers. See "About Purging Old Credit Card Event and Audit Trail Objects" for more information.

Replacing Credit Card Numbers with Tokens

To replace all the credit card numbers in the /payinfo/cc objects, run the following command:

pin_cc_migrate -vendor payment_processor_name

where payment_processor_name is the credit card processor or automated clearing house (ACH) to use for validating credit cards and debit cards.

For example:

pin_cc_migrate -vendor fusa

To replace only a specific number of credit card numbers in the /payinfo/cc objects, run the following command:

pin_cc_migrate -vendor payment_processor_name -num number  

where number is the number of /payinfo/cc objects to be selected for tokenization.

For example:

pin_cc_migrate -vendor fusa -num 10

To replace the credit card numbers only for a specific account, run the following command:

pin_cc_migrate -vendor payment_processor_name -account account_POID

where account_POID is the Portal object ID (POID) of the account to be selected for tokenization.

For example:

pin_cc_migrate -vendor fusa -account 3421343

To specify the time range for selecting the credit card numbers for tokenization, run the following command:

pin_cc_migrate -vendor payment_processor_name -start_date mm/dd/yy -end_date mm/dd/yy 

For example:

pin_cc_migrate -vendor fusa -start_date 01/01/11 -end date 10/30/11

The start and end dates specify the time range for selecting the /payinfo/cc objects for tokenization.

See "pin_cc_migrate" for information on the pin_cc_migrate utility.

About Purging Old Credit Card Event and Audit Trail Objects

When you run the pin_cc_migrate utility, only the credit and debit card numbers stored in the /payinfo/cc objects are replaced with tokens. The credit and debit card numbers stored in the following objects are not replaced:

• Event objects created for credit card validation and credit card charges (such as /event/billing/charge/cc and /event/billing/validate/cc objects)

• Audit trail objects created for tracking credit card payments (such as /event/audit/customer/payinfo/cc and /au_payinfo/cc objects)

Oracle recommends that you purge these event and audit trial objects immediately after you run the pin_cc_migrate utility. You can purge the old event and audit trail objects by using the BRM utilities or purging scripts. See the following for more information:

• To purge the event objects, see "About Purging Event Objects" in BRM System Administrator's Guide.

• To purge the audit trail objects, see "Archiving Audit Data" in BRM Developer's Guide.

Important:

If you purge the /event/billing/charge/cc objects, you cannot refund payments to the same credit card accounts that were used for one-time payments made before running the pin_cc_migrate utility.

About Migrating Credit Card Information from Legacy Databases

When migrating legacy credit and debit card data into the BRM database, do one of the following:

• If tokens are stored in the legacy database instead of the actual credit or debit card numbers, when you create the XML file for migrating data, do the following:

  1. Ensure that you add the card type value for each credit card account. This ensures that the legacy credit and debit card data is migrated in the same format that is used for storing the credit card data in the PAYINFO_CC_T table.

     The following are the card type values that are used in the PAYINFO_CC_T table:

     • 1 for VISA card

     • 2 for MASTER card

     • 3 for American Express card

     • 5 for Discover card

     • 6 for Diners Club card

     • 7 for Carte Blanche

     • 8 for JCB

     • 9 for SWITCH

     • 10 when the card type is unknown

     See "About Creating XML Files" in BRM Managing Customers for more information on creating XML file for migrating legacy credit card data.

  2. Enable credit card tokenization in BRM. See "Enabling Credit Card Tokenization" for more information.

• If credit or debit card numbers are stored in the legacy database, after migrating the card numbers from the legacy database, do the following:

  1. Enable credit card tokenization in BRM. See "Enabling Credit Card Tokenization" for more information.

  2. Run the pin_cc_migrate utility to replace the credit and debit card numbers with tokens. See "pin_cc_migrate" for more information on the pin_cc_migrate utility.

See "Migrating Customer Accounts" in BRM Managing Customers, for more information on migrating data from legacy databases.

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. For more information, see "Configuring BRM-Initiated Payment Processing".

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.

About the Paymentech HeartBeat Application

The Paymentech HeartBeat application is a background process that checks the application-to-application connectivity between BRM and Paymentech. When the Paymentech DM (dm_fusa) successfully connects to Paymentech to process BRM-initiated payments, Paymentech acknowledges the secure connection by sending a HeartBeat message. The Paymentech DM responds by sending back a HeartBeat message to Paymentech to confirm that the connection is working properly and that the expected transactions and data types are being sent.

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.

Important:

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

The request and response messages should continue for the duration of the connection and are comprised of a unique sequence number and a current timestamp.

For information on initializing the HeartBeat application and troubleshooting errors, see "Using the Paymentech HeartBeat Application".

About Applying Charges Directly to Credit Card Accounts

You use Customer Center to apply charges directly to a customer's credit card.

When you charge a credit card, BRM performs only a credit card authorization. The payment is deposited by running the "pin_deposit" payment utility. By default, you run the pin_deposit utility every day by running the pin_bill_day script.

See "About Depositing BRM-Initiated Payments".

General Ledger Impact of Charges

The general ledger impact of charges made directly to credit cards is recorded when the payment is made, not when the charge is initiated. By default, payments are associated with G/L ID 109.

About Collecting BRM-Initiated Payments

The pin_collect utility collects the balance due for bills that are paid by credit card or direct debit. The balance due is calculated by the pin_bill_accts utility, and is derived from the total from all bill items, minus amounts that were adjusted, transferred, and so forth.

The pin_collect utility collects payments for accounts that had a bill created by the pin_bill_accts utility on that day. This is why you run the pin_bill_accts utility first.

If you miss a billing day, the pin_collect utility still collects on accounts whose billing day was missed. This is because the pin_bill_accts utility creates bills for the missed billing days, and the pin_collect utility collects payments for those bills.

You can use the -rebill option to collect on accounts whose billing day is before the day that you run the pin_collect utility.

The pin_collect utility performs the credit card authorization and deposits the payment at the same time (as opposed to pin_deposit, which only deposits payments that have been pre-authorized.)

The pin_collect utility searches for outstanding checkpoint events for the specified /account object. If any are found, it flags the result as ”Checkpoint Outstanding”.

For information about the pin_collect utility syntax, see "pin_collect".

When to Run the pin_collect Utility

Run the pin_collect utility at the following times:

• In the pin_bill_day script for all accounts.

• In the pin_bill_week script with the rebill option on all active accounts.

• In the pin_bill_month script with the rebill option on all closed/inactive accounts.

  Important:

  When you use multiple payment processors, you run this utility for each payment processor. See "Using More Than One Payment Processor".

You can also run the pin_collect utility manually to rebill accounts from a specific date.

Increasing Performance of the pin_collect Utility

To increase billing performance, you run multiple threads of the pin_collect utility. See "Tuning Billing Performance" in BRM System Administrator's Guide.

Setting the Minimum Amount to Collect

By default, pin_collect does not collect amounts less than two dollars. To change the minimum amount, see "Specifying the Minimum Payment to Collect" in BRM Configuring and Running Billing.

About Depositing BRM-Initiated Payments

The pin_deposit utility deposits pre-authorized credit card payments into your account.

Pre-authorization occurs in two cases:

• When a customer specifies a credit card payment method.

• When a CSR issues a charge in Customer Center.

The pin_deposit utility searches for all pre-authorized but unpaid credit card transactions made within the past 30 days (from yesterday), and sends the credit card authorization codes and the transaction dates to the credit card processor for depositing.

For information about the pin_deposit utility, see "pin_deposit".

When to Run pin_deposit

Use the pin_bill_day script to run the pin_deposit utility daily.

You should run the pin_deposit utility daily because VISA authorizations expire in 7 days. (MasterCard authorizations expire in 30 days.) You can deposit pre-authorized payments after the authorization has expired, but the transactions cost more to process.

Important:

When you use multiple payment processors, you run this utility for each payment processor. See "Using More Than One Payment Processor".

If performance warrants, you can modify the scope of the search by using the start and end options to change the starting and ending dates of the search.

Increasing Performance of the pin_deposit Utility

To increase billing performance, you run multiple threads of the pin_deposit utility. See "Tuning Billing Performance" in BRM System Administrator's Guide.

About Resolving Failed BRM-Initiated Payment Transactions

Use the pin_clean utility to troubleshoot failed BRM-initiated payment transactions, such as credit card or direct debit transactions. For more information, see "Resolving Failed BRM-Initiated Payment Transactions".

For information about the pin_clean utility, see "pin_clean".

When to Run the pin_clean Utility

You should run the pin_clean utility every day to look for failed BRM-initiated payment transactions.

Tip:

The pin_clean utility writes output to stdout, so you can write a script to run the pin_clean utility daily and write the output to a file.

Example of Running pin_clean

The following example shows a typical pin_clean session:

1. Start the pin_clean utility:

   % pin_clean
   

2. A summary of checkpoint records appears, followed by a list of options.

   CheckPoint Log Summary:
      PIN_CHARGE_CMD_VERIFY        3
      PIN_CHARGE_CMD_AUTH_ONLY     3
      PIN_CHARGE_CMD_CONDITION     0
      PIN_CHARGE_CMD_DEPOSIT       0
      PIN_CHARGE_CMD_REFUND        2
   
   Choose function by number:
      1) View PIN_CHARGE_CMD_VERIFY
      2) View PIN_CHARGE_CMD_AUTH_ONLY
      3) View PIN_CHARGE_CMD_CONDITION
      4) View PIN_CHARGE_CMD_DEPOSIT
      5) View PIN_CHARGE_CMD_REFUND
      6) Delete All
      7) Done
   

In this example, there are three failed verification transactions, three failed authorization transactions, and two failed refund transactions.

About Recovering BRM-Initiated Payment Transactions

Use the pin_recover utility to resolve failed BRM-initiated payment transactions. When resubmitting failed credit card and direct debit transactions, the pin_recover utility takes the billinfo's current payment type while, which must be either 10003 for credit cards or 10005 for direct debit transactions.

When to Run the pin_recover Utility

You should run this utility whenever the pin_clean utility finds failed transactions. See "Resolving Failed BRM-Initiated Payment Transactions".

For information about the pin_recover utility, see "pin_recover".

Caution:

If you use a credit card payment processor other than Paymentech, ensure that it uses duplicate transaction detection. If not, using the pin_recover utility can cause customers to be billed twice.

How BRM-Initiated Payment Transactions Are Performed

Note:

The BRM-initiated payment collection utilities (pin_collect and pin_deposit) process payments for multiple bills associated with multiple /billinfo objects. To process externally initiated payments, such as checks and cash payments, for multiple /billinfo objects, write custom code that records the deposits you have received and calls PCM_OP_PYMT_COLLECT.

To perform a BRM-initiated payment transaction, PCM_OP_PYMT_COLLECT calls PCM_OP_PYMT_CHARGE.

The input flist contains a PIN_FLD_SESSION_OBJ field, which defines the session in which the event occurred: either a payment batch event or a refund batch event.

The input flist also contains an array of specific operations to perform, so any number of operations can be batched together into a single call. The command is specified within each operation, so a single batch can contain a mixture of different commands.

The billing information for each operation, such as credit card number and expiration date, can be specified as options on the input flist. If it isn't specified, PCM_OP_PYMT_CHARGE retrieves the necessary information from the account storable objects specified within the operations. After it has all the data, the operations are forwarded to the opcode responsible for processing that payment method (for example, PCM_OP_PYMT_CHARGE_CC and PCM_OP_PYMT_CHARGE_DD for credit card charges and direct debit charges, respectively).

Note:

• For security reasons, the credit card CVV2 and CID numbers are not stored in BRM. If the cc_collect entry is enabled, PCM_OP_PYMT_CHARGE passes the security information to the payment processor for authorization and collection only at time of account creation. When collecting payments, PCM_OP_PYMT_CHARGE does not pass the information. In addition, it omits the PIN_FLD_SECURITY_ID field from the input flist of PCM_OP_ACT_USAGE so it is not written to the /event/billing/charge/cc object. The result is that the CVV2/CID information is stored in the database with a NULL value. For more information, see "Requiring Additional Protection against Credit Card Fraud".

• BRM supports direct debit transactions from checking accounts only.

Each of the commands listed below in Table 2-1 can be executed as an operation. They are also called by Customer Center:

Table 2-1 Commands to Perform Transactions

Command	Description
PIN_CHARGE_CMD_VERIFY	Verify the address information.
PIN_CHARGE_CMD_AUTH_ONLY	Authorize a charge. The credit limit is decreased on the credit card, but no charge is posted.
PIN_CHARGE_CMD_CONDITION	Authorize and deposit a charge.
PIN_CHARGE_CMD_DEPOSIT	Deposit a previously authorized charge.
PIN_CHARGE_CMD_RECOVER_PAYMENT	Recovers payments by using outstanding checkpoints.
PIN_CHARGE_CMD_REFUND	Refund a charge.
PIN_CHARGE_CMD_RESUBMIT	Resubmit the batch of charges.
PIN_CHARGE_CMD_RFR	For transactional payments, requests the RFR file to retrieve payments. For nontransactional payments, reads the RFR file to retrieve payments.

For each operation specified, the result of the operation is stored in the corresponding /event/billing/charge storable object.

The result is stored both as a numeric value returned by the payment processor, and as an enumerated result. The enumerated result should generally be used by applications to determine what happened because its values are independent of which settlement house was used.

Possible result values for an operation are shown in Table 2-2:

Table 2-2 Result Values for Operation

InputPIN_FLD_RESULT	OutputPIN_FLD_RESULT	OutputPIN_FLD_DESCR
PIN_CHARGE_RES_PASS	PIN_RESULT_PASS	Validation successful
PIN_CHARGE_RES_SRVC_UNAVAIL	PIN_RESULT_PASS	Validation successful
PIN_CHARGE_RES_FAIL_ADDR_AVS	PIN_RESULT_FAIL	Unable to verify address
PIN_CHARGE_RES_FAIL_ADDR_LOC	PIN_RESULT_PASS	Street address mismatch
PIN_CHARGE_RES_FAIL_ADDR_ZIP	PIN_RESULT_FAIL	ZIP code mismatch
PIN_CHARGE_RES_FAIL_CARD_BAD	PIN_RESULT_FAIL	Credit card number not valid
PIN_CHARGE_RES_FAIL_DECL_SOFT	PIN_RESULT_FAIL	General soft decline Card failed credit check
PIN_CHARGE_RES_FAIL_DECL_HARD	PIN_RESULT_FAIL	General hard decline Card failed credit check
PIN_CHARGE_RES_FAIL_NO_ANS	PIN_RESULT_FAIL	No answer from settlement house Unable to validate now
PIN_CHARGE_RES_CHECKPOINT	PIN_RESULT_FAIL	Unable to validate now
PIN_CHARGE_RES_CVV_BAD	PIN_RESULT_FAIL	Security ID check failed

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.

Note:

By default, account balances are not updated if there is a decline. To update account balances when a decline occurs, you must customize the PCM_OP_PYMT_POL_CHARGE policy opcode.

You can send multiple charges in one call by using the PIN_FLD_CHARGES array on the input flist. This array is designed for batch processing; you just make one call to PCM_OP_PYMT_CHARGE for a whole list of charges (or accounts to charge). These entries on the input flist of this opcode are of special interest:

• The PIN_FLD_POID entry at the top of the input flist is only used for routing; it only requires a correct (user) database number.

• The PIN_FLD_ACCOUNT_OBJ entry is the POID of the account actually being charged (verified) by this element of the PIN_FLD_CHARGES array. In a batch, this POID is presumably different for every element.

If the PCM_OPFLG_CALC_ONLY flag is set, the opcode does not change any fields in the database and does not create an /event/billing/charge object. However, it does provide a charge calculation to the caller by returning the fields that would have been used to create the event object and the charge item.

Caution:

Do not set the PCM_OPFLG_CALC_ONLY flag if you are connected to a payment processor, for example Paymentech. This may cause the charge to be sent to the credit card company, even though the charge is not created in BRM. This may result in a double charge on the account.

PCM_OP_PYMT_CHARGE works as follows:

1. Opens a transaction.

2. Using checkpoints, creates the /event/billing/charge event for each payment.

3. Calls PCM_OP_PYMT_CHARGE_CC or PCM_OP_PYMT_CHARGE_DD, depending on the payment method, to process the charges from the payment DM.

4. Updates the checkpoint in the charge event for each transaction received from the payment DM.

5. For each PIN_FLD_CHARGES in the input flist:

   1. Closes billing for the account.

   2. Creates a payment item and records the account number, bill number, and transaction ID from the input flist, and the fact that the money has been received.

   3. Adds the PIN_FLD_STATUS value in the output flist.

      For failed payments, sets the PIN_FLD_STATUS value to PIN_PYMT_FAILED. For successful payments, sets the PIN_FLD_STATUS value to PIN_PYMT_SUCCESS.

   4. Calls the PCM_OP_PYMT_POL_CHARGE policy opcode to update the reasons array.

   5. Sends the payment status and the reasons array (PIN_FLD_REASON_ID and PIN_FLD_REASON_DOMAIN_ID) to PCM_OP_PYMT_COLLECT.

   6. For payments with a successful status, applies the charge to the customer's account. For payments with a failed status, sends the PIN_FLD_STATUS value to the PCM_OP_PYMT_APPLY_FEE to create the payment fees.

6. Closes the transaction.

How BRM Performs Credit Card Charges

To perform a credit card charge, PCM_OP_PYMT_CHARGE calls PCM_OP_PYMT_CHARGE_CC.

The PCM_OP_PYMT_CHARGE_CC input flist contains the PIN_FLD_SESSION_OBJ field, which references either the /event/billing/batch/payment or /event/billing/batch/refund object. This determines the batch type being submitted (payment or refund).

The PCM_OP_PYMT_CHARGE_CC input flist contains an array of specific operations to perform, so any number of operations can be batched together into a single call. The command is specified within each operation, so a single batch can contain a mixture of different commands. This opcode supports all commands handled by PCM_OP_PYMT_CHARGE.

The operations are forwarded to the credit card processing Data Manager (for example, the Paymentech DM) for processing.

With most credit card payment services, performing an authorization is much faster than a conditional deposit (authorization plus deposit). Thus, for applications where latency is important, it may be desirable to perform just the authorization step in real-time. BRM daily billing performs the necessary deposits for all outstanding authorizations from the previous day. This removes a significant amount of latency from the real-time process, but still authorizes the charge so it is guaranteed to deposit successfully.

The set of Paymentech return codes handled by BRM is listed in the BRM_Home/sys/dm_fusa/fusa_codes file. As explained in "Changing How BRM Handles Paymentech Authorization Return Codes", these codes can be modified. See "How BRM-Initiated Payment Transactions Are Performed" for a list of the PIN result codes from BRM-initiated payment transactions.

Unless the PCM_OPFLG_CALC_ONLY flag is specified, PCM_OP_PYMT_CHARGE_CC creates an /event/billing/charge/cc storable object for each operation. If an array of operations was specified, then more than one event storable object is created. The event storable objects are created even if the credit card operations cannot be performed.

Caution:

Do not set the PCM_OPFLG_CALC_ONLY flag if you are connected to a payment processor, for example, Paymentech. This may cause the charge to be sent to the credit card company, even though the charge is not created in BRM. This may result in a double charge on the account.

How BRM Performs Direct Debit Charges

BRM supports direct debit transactions from customer checking accounts only. To perform a batch of Paymentech direct debit transactions, PCM_OP_PYMT_CHARGE calls PCM_OP_PYMT_CHARGE_DD.

This opcode is used for the Paymentech direct debit implementation shipped with BRM, and is available for you to use in creating a custom direct debit implementation for the bank or payment clearing house you choose.

Important:

Debit cards that require a personal identification number (PIN) are not supported.

About Paymentech Direct Debit Implementation

PCM_OP_PYMT_CHARGE_DDEBIT supports all commands handled by PCM_OP_PYMT_CHARGE.

Unless the PCM_OPFLG_CALC_ONLY flag is specified, this routine creates an /event/billing/charge/ddebit storable object for each operation. If an array of operations is specified, then more than one event object is created.

Caution:

Do not set the PCM_OPFLG_CALC_ONLY flag if you are connected to a payment processor, for example, Paymentech. This may cause the charge to be sent to the credit card company, even though the charge is not created in BRM. This may result in a double charge on the account.

Creating a Custom Direct Debit Implementation

By default, PCM_OP_PYMT_CHARGE_DD returns direct debit payment information, a charge status, and a payment status to the calling opcode for updating respective events. Effectively this opcode performs a loopback operation that you must change before you can implement direct debit charging. It does not output transaction data for a direct debit clearinghouse. BRM users must create an application to extract the information from the database for a specific direct debit clearinghouse.

For more information on adding a direct debit to your BRM system, see "Implementing a Direct Debit Payment Method".

How BRM Performs a Batch of Direct Debit Charges

To perform a batch of Paymentech direct debit transactions, PCM_OP_PYMT_CHARGE calls PCM_OP_PYMT_CHARGE_DD. The processing is performed on a per-batch basis; only one command and one payment method can exist in the same batch.

PCM_OP_PYMT_CHARGE_DD supports all commands handled by PCM_OP_PYMT_CHARGE, except that it does not create a payment structure and handles transaction charges of $1 only. See "How BRM-Initiated Payment Transactions Are Performed" for a list of the PIN result codes from BRM-initiated transactions.

The input flist contains a PIN_FLD_SESSION_OBJ field, which defines the session in which the event occurred: either a payment batch event or a refund batch event (/event/billing/batch/payment or /event/billing/batch/refund).

Unless the PCM_OPFLG_CALC_ONLY flag is specified, this routine creates an /event/billing/charge/dd storable object for each operation. If an array of operations was specified, then more than one event storable object is created. The event storable objects are created even if the direct debit operations cannot be performed.

Caution:

Do not set the PCM_OPFLG_CALC_ONLY flag if you are connected to a payment processor, for example, Paymentech. This may cause the charge to be sent to the credit card company, even though the charge is not created in BRM. This may result in a double charge on the account.

For more information on credit card handling, see "About the Billing Utilities" and the pin_collect, pin_recover, and pin_deposit sections in particular.

The set of Paymentech return codes handled by BRM is listed in the BRM_Home/sys/dm_fusa/fusa_codes file. As explained in "Changing How BRM Handles Paymentech Authorization Return Codes", these codes can be modified.

How BRM Checks the Results of BRM-Initiated Batch Payment Operations

To check the results of batch payment operations, set the PIN_FLD_COMMAND value in the PCM_OP_PYMT_COLLECT input flist to PIN_CHARGE_CMD_RECOVER_PAYMENT. This causes PCM_OP_PYMT_CHARGE to call PCM_OP_PYMT_RECOVER.

PCM_OP_PYMT_RECOVER posts the results of charges for which no information was returned.

PCM_OP_PYMT_RECOVER calls the following opcodes:

• To check the results of a batch of credit card charges, PCM_OP_PYMT_RECOVER_CC calls PCM_OP_PYMT_RECOVER_CC. This opcode posts results of credit card charges for which no information was returned.

  PCM_OP_PYMT_RECOVER_CC is specific to the Paymentech DM.

• To check the results of a batch of direct debit charges, PCM_OP_PYMT_RECOVER_CC calls PCM_OP_PYMT_RECOVER_DD. This opcode posts results of direct debit charges for which no information was returned. The results are passed back and used for transaction reconciliation.

  PCM_OP_PYMT_RECOVER_DD is specific to the Paymentech DM.

How BRM Validates Credit Card and Direct Debit Transactions

To validate credit card and direct debit transactions, use PCM_OP_PYMT_VALIDATE. This opcode is called by PCM_OP_CUST_PREP_CUSTOMER and PCM_OP_CUST_POL_VALID_PAYINFO during registration.

PCM_OP_PYMT_VALIDATE calls the PCM_OP_PYMT_POL_VALIDATE policy opcode to determine the success or failure of a BRM-initiated transaction validation. See "Changing How BRM Handles Paymentech Address Validation Return Codes".

PCM_OP_PYMT_VALIDATE reads the /config/payment storable class to determine the transaction type and the opcode to call, and then calls the appropriate opcode to validate the transaction.

• Credit card transactions: PCM_OP_PYMT_VALIDATE_CC.

  PCM_OP_PYMT_VALIDATE_CC performs a batch of online credit card validations and applies the validation policy to the results.

• Direct debit transactions: PCM_OP_PYMT_VALIDATE_DD.

  PCM_OP_PYMT_VALIDATE_DD performs a batch of online direct debit validations and applies the validation policy to the results. PCM_OP_PYMT_VALIDATE_DD calls the appropriate DM to process validations, then returns the results to the Internet.

  Note:

  BRM supports direct debit transactions from checking accounts only.

For both opcodes, the input flist contains an array of specific operations to perform, so any number of operations can be batched together into a single call. The command is specified within each operation, so a single batch can contain different commands. The PIN_FLD_SESSION_OBJ in the input flist is either /event/billing/batch/refund or /event/billing/batch/payment, depending on the batch type: payment or refund.

How BRM Handles Credit Card Information during Account Creation

During the account creation process, PCM_OP_CUST_COMMIT_CUSTOMER passes credit card information to PCM_OP_PYMT_VALIDATE and PCM_OP_PYMT_COLLECT, which collect any credit card payments charged at account creation and validate the credit card information returned by the payment processor.

• PCM_OP_PYMT_COLLECT calls the PCM_OP_PYMT_POL_SPEC_COLLECT policy opcode, which passes the bill unit associated with the payment and returns a list of open items to be paid in the PIN_FLD_ITEMS array.

• PCM_OP_PYMT_POL_SPEC_COLLECT calls PCM_OP_PYMT_GET_ACH_INFO to retrieve the Automated Clearing House (ACH) information.

• PCM_OP_PYMT_GET_ACH_INFO retrieves ACH information from the /config/ach object. It uses the ACH vendor name or element ID in the input flist to determine which element in the ACH_INFO array should be used.

If the cc_collect value in the CM pin.conf file is set to 1, during account creation for credit card accounts, the total due amount for the account is charged immediately and the payment is allocated immediately to all open bill items. Therefore, after the account is created, it will have no pending amount due and no unapplied payments. For such accounts, Customer Center displays the following account balance information in the Summary tab:

• Amount due for all bills: 0

• Adjustments/Payments not applied: 0

• Due now: 0

  Important:

  In the Payments tab, the received payment is displayed as allocated, regardless of whether a bill has been created yet.

About Credit Card Fraud Prevention

Paymentech offers an additional fraud prevention option for Visa and American Express transactions. Visa and American Express debit and credit cards have a non-embossed identifier.

• For Visa cards, this field holds the three-digit CVV2 (Card Verification Value 2) ID.

• For American Express, this fields holds the four-digit CID (Card identifier).

Many people who defraud with credit cards know the account numbers and expiration dates of the card, but do not have the card in their possession and cannot provide the CVV2 or CID number. The Visa CVV2 number is on the back of the card in the signature panel. The American Express CID number is on the front of the card. CSRs can request this information when registering customers.

For security reasons, these numbers are not stored in BRM. PCM_OP_PYMT_VALIDATE omits the PIN_FLD_SECURITY_ID field from input flist of PCM_OP_ACT_USAGE so it is not written to the /event/billing/charge/cc object. The result is that the CVV2/CID information is stored in the database with a NULL value.

You can configure BRM to make the identification numbers required or optional when a CSR registers a customer, adds a credit card to an account, or changes a customer's credit card information. In such cases, PCM_OP_PYMT_VALIDATE_CC sends the information in the PIN_FLD_SECURITY_ID field directly to the payment processor. The PIN_FLD_SECURITY_RESULT field is part of the PIN_FLD_RESULTS element. The value is validated when PCM_OP_VALIDATE_CC issues the PIN_CHARGE_CMD_VERIFY command to the Paymentech DM.

You can also configure Customer Center and BRM to validate the maximum number of digits entered for the CVV2 number. See "Specifying the Maximum Number of Digits Allowed for CVV2 Verification".

For more information, see "Requiring Additional Protection against Credit Card Fraud".