1. Configuring and Collecting Payments
  2. Configuring Payment Methods

13 Configuring Payment Methods

Learn how to configure payment methods for Oracle Communications Billing and Revenue Management (BRM) payments.

Topics in this document:

To create a custom payment method, see "Adding a Custom Payment Method" in BRM Opcode Guide.

About Payment Methods

A payment method is the mode by which customers pay their bills. The payment method is selected for an account when the account is created, but it can be changed at any time.

Note:

You can set up multiple payment methods for an account and assign a different one to each bill unit (/billinfo object) in an account, but you can use only one payment method per bill unit.

You can configure custom payment methods. To do so, you need to do the following:

  • Update the /config/payment object.

  • Modify the PCM_OP_CUST_POL_PREP_PAYINFO policy opcode to validate the custom payment method. For example, add code for your custom payment method everywhere the opcode checks the various payment methods.

Default Payment Methods

By default, BRM supports the following payment methods:

  • Cash, check, and postal order payment methods. You allocate cash, check, and postal order payments by using Payment Tool. Customers of this type usually use the Invoice payment method.

  • Credit card payment method. Credit card payments are BRM-initiated. Because some credit card payments are made automatically, accounts that pay bills by these methods should always use the balance forward accounting type. See "About Accounting Types" in BRM Concepts.

    When a customer registers for a credit card payment method, BRM attempts to validate the card by default.

    When a credit card payment is made, BRM returns a confirmation number that the customer can use to identify the payment. See "About Credit Card Payment Confirmation Numbers" in BRM Opcode Guide.

  • Direct debit payment method. If a customer uses the direct debit payment, the customer's bank account is debited automatically each billing cycle. Direct debit charges are verified by the bank routing number and the checking account number. Direct debit payments are BRM-initiated.

    In the US and Canada, 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.

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

    Because some direct debit payments are made automatically, accounts that pay bills by this method should use the balance forward accounting type. See "About Accounting Types" in BRM Concepts.

  • Invoice payment method. Accounts that use the Invoice payment method pay by check, cash, or other externally initiated payment methods. By default, accounts that use an Invoice payment method receive invoices on a monthly basis. You use Payment Tool to process invoice-generated payments.

  • Prepaid payment method. Customers who use the Prepaid payment method pay for service usage in advance. They send check or cash payments and can also pay by using a prepaid voucher. With prepaid balances, the customer is always expected to have a credit (negative) balance. For example, when an IP telephony customer pays $10 for 100 minutes of usage, the account currency balance is -10 US Dollars. As the customer makes calls, the balance increases until the credit limit (0) is reached. When you run billing, no collection process is performed on prepaid balances because they are paid in advance of billing.

    Accounts that have prepaid balances should use balance forward accounting because payments are made before there is a due amount. (With open item accounting, you are billed only for open items that are due.)

  • Nonpaying payment method. Nonpaying bill units are child bill units; their bill is paid by the account that owns their paying parent bill unit. If an account has two bill units (and thus two bills), one paying and one nonpaying, the account pays one bill and the account that owns the nonpaying bill unit's paying parent pays the other. See "About Charge Sharing Groups" in BRM Managing Customers.

  • Undefined payment method. Accounts with the Undefined payment method never receive a payment request. You typically use undefined accounts for free trial offers. Creating an undefined account enables a customer to register without having to submit a credit card number. You can also use undefined accounts for testing BRM and for creating CSR accounts.

    Undefined accounts require a login name and password so customers can be authenticated and authorized. You can only assign an undefined payment method to an account during account creation.

    Because an account with a payment method of Undefined never pays a bill, you need to set the credit limit to Unlimited.

    Revenue generated from undefined accounts can be recorded as general ledger (G/L) data.

  • Voucher payment method. When a customer buys a voucher, either a CSR or the customer enters the voucher ID & PIN and BRM validates the voucher and transfers its prepaid balances to the specified account balance.

    Voucher payments cannot be handled by the BRM-initiated payment process or by Payment Tool. To provide voucher payments for your customers, you must have Voucher Manager and Voucher Administration Center installed. For more information, see "About Managing Voucher Inventory" in BRM Telco Integration.

  • Wire transfer payment method. Wire transfers include any transfer of money from a customer's bank account to your company or to your company's payment processor through an automated teller machine (ATM), computer, telephone, or the like. Customers who pay their bills with wire transfer payments usually have the Invoice payment method defined in their accounts. You handle wire transfer payments by using Payment Tool.

Payment methods are stored in the /config/payment object and defined in the BRM_home/include/pin_pymt.h file. Each payment method is associated with an element ID.

Important:

To avoid conflicts with payment IDs reserved by BRM, assign custom payment methods an element ID greater than 10099.

Table 13-1 lists the standard payment methods and element IDs.

Table 13-1 Payment Methods and Element IDs

Payment method Element ID

PIN_PAY_TYPE_UNDEFINED

Used during account creation.

0

PIN_PAY_TYPE_PREPAID

Used to keep negative balances.

10000

PIN_PAY_TYPE_INVOICE

Used for monthly invoices.

10001

PIN_PAY_TYPE_DEBIT

Used for checking account debit.

10002

PIN_PAY_TYPE_CC

Used for credit cards.

10003

PIN_PAY_TYPE_DD

Used for US/Canadian direct debits.

10005

PIN_PAY_TYPE_SMARTC

Used for smartcards.

10006

PIN_PAY_TYPE_SUBORD

Used to roll up balances to the parent account.

10007

PIN_PAY_TYPE_BETA

For use by beta testers only. Billing utilities ignore this.

10008

PIN_PAY_TYPE_INTERNAL

Used for internal employees. Used the same way as guest accounts.

10009

PIN_PAY_TYPE_GUEST

Used for guest accounts. It is not charged, but credit limits apply.

10010

PIN_PAY_TYPE_CASH

Used for cash.

10011

PIN_PAY_TYPE_CHECK

Used for personal bank checks.

10012

PIN_PAY_TYPE_WTRANSFER

Used for wire transfers.

10013

PIN_PAY_TYPE_PAYORDER

Used for inter-bank payment orders.

10014

PIN_PAY_TYPE_POSTALORDER

Used for postal payment orders.

10015

PIN_PAY_TYPE_VOUCHER

Used for payment vouchers.

10016

PIN_PAY_TYPE_FAILED

Used for unconfirmed payments that failed.

10017

PIN_PAY_TYPE_SEPA

Used for SEPA payments.

10018