Note: Before implementing Oracle Payments, it is advisable to answer the questions in this section to ensure that your implementation meets your business needs.
This section presents implementation questions common to both funds capture and funds disbursement functionality and are, therefore, relevant to shared planning.
System security functionality is common to both funds capture and funds disbursement. When implementing Oracle Payments, you must specify appropriate security options for:
encrypting sensitive information about payment instruments
masking payment instruments and external bank accounts
verifying credit cards using the Address Verification System
Security issues to address before implementation include the following:
internal security requirements (data storage)
external security requirements (transmission)
fraud protection
Before implementing Oracle Payments, ensure that you understand the transmission security requirements of your payment system(s) and make sure that your network supports those requirements.
Note: Oracle Payments provides support for SSL, Secure FTP, and AS2, but you must mold this support into a comprehensive transmission security solution.
For information on setting up security options, see Step 2. Setting Up System Security Options.
For information on enabling third party payment systems to verify credit card owners, see Verifying Credit Card Owners.
For information on creating risk formulas to evaluate the risk of customers who wish to buy products or services from a payee, see Creating a Risk Formula.
Funds capture functionality involves the automated retrieval of payment from third party payers who owe debts to the first party payee, using electronic payment methods, such as direct debits of bank accounts, credit cards, and remittance of bills receivable.
Funds disbursement functionality involves making payments to third party payees. A payment can take an electronic form, such as EFT or wire, or a printed form such as a check.
You can choose to use either functionality or both, depending on your business needs.
Related Topics
For information on funds capture functionality, see Understanding Funds Capture.
For information on funds disbursement functionality, see Understanding Funds Disbursement.
For electronic payment processing, you must decide which payment system you want to use. Oracle Payments requires partnering with a third party payment system for processing electronic funds capture and funds disbursement transactions.
The table below lists the payment systems that are integrated and shipped with Oracle Payments for funds capture functionality, along with the payment methods that each payment system supports.
| Payment System | Credit Card | Purchase Card | PINless Debit Card | Bank Account Transfer | Electronic Funds Transfer Online Validation |
|---|---|---|---|---|---|
| Paymentech | Yes | Yes | Yes | Yes | Yes |
| First Data (North) | Yes | Yes | No | No | No |
| Concord EFS | Yes | Yes | Yes | Yes | No |
** U.S. ACH only
Note: The supported operations listed in the preceding table may change. For current information, contact your payment system.
There are other payment systems that support their own Oracle Payments integrations. The table below lists a payment system that provides its own integration with Oracle Payments, along with the payment methods this payment system supports.
| Payment System | Credit Card | Purchase Card | PINless Debit Card | Bank Account Transfer | Electronic Funds Transfer |
|---|---|---|---|---|---|
| VeriSign | Yes | No | No | Yes | No |
Related Topics
For information on setting up payment systems, see Step 8: Setting Up Payment Systems.
The source products you choose to use with Oracle Payments can be:
Preintegrated Oracle applications
Non-Oracle applications
Many Oracle applications, such as iStore, Order Capture, Telesales, Order Management, Oracle Receivables, Oracle Payables, and Collections are preintegrated with Oracle Payments out of the box.
Note: To ensure that preintegrated Oracle applications are set up correctly, see the setup documentation for each preintegrated Oracle application.
For non-Oracle applications, you must implement the appropriate APIs.
Related Topics
For information on APIs to implement with non-Oracle applications, see the Oracle Integration Repository at http://irep.oracle.com/.
Payment format requirements usually originate from payment systems or central banks. Formats are created by deploying companies to format funds capture transactions and funds disbursement payment instructions. Oracle Payments uses Oracle XML Publisher formatting templates to format electronic transactions and payment instructions according to the formatting requirements of specific financial institutions. Oracle Payments also provides seeded payment validations that you can apply to the supported payment formats.
Related Topics
For information on creating payment formats and applying them to an XML data file produced by Oracle Payments, see Step 3. Setting Up XML Publisher Formatting Templates.
For information on setting up country-specific codes and identifiers provided by a country's government or central bank that relate to how the country-specific payment is to be processed, see Step 14. Setting Up Bank Instruction Codes.
For information on setting up country-specific codes and identifiers provided by a country's government or central bank that relate to how the country-specific payment is to be delivered to a payee, see Step 15. Setting Up Delivery Channel Codes.
For information on setting up country-specific codes and identifiers provided by a country's government or central bank that relate to the reason for the payments, see Step 16. Setting Up Payment Reason Codes.
Before implementing Oracle Payments, you must determine whether your application needs to present information in different languages.
Your application may need to use NLS if either of the following is true:
The source product and the payment system use different languages or character sets. For example, the source product may use a Japanese EUC character set, while the payment system uses a Japanese Shift-JIS character set.
Clients of the source product use different languages. For example, a web site that expects customers to visit from all over the world might want to present its source product in different languages for different customers.
To enable character conversion in all these environments, the source product and the payment system must convey the language and character set information to Oracle Payments.
To communicate information about the language and character set to Oracle Payments, a source product and payment system servlet must pass a special parameter (NlsLang). This parameter is a part of every API included in this implementation guide.
NlsLang is an optional parameter. If your source product does not need to handle non-Latin1 character set parameters and does not need to communicate to clients or payment systems in different languages, you do not need to use this parameter.
If the source product does not pass the NlsLang parameter, Oracle Payments passes information from the source product to the payment service servlet without performing any conversion of character sets.
If the source product does pass a value for NlsLang to Oracle Payments, then Oracle Payments tries to convert parameters based on the value of NlsLang before sending those parameters to the payment system servlet.
To do so, Oracle Payments first checks its database for the list of preferred and optional languages for that payment system. The information in the database reflects what the Oracle Payments administrator entered using the Oracle Payments administration user interface.
Second, Oracle Payments does one of the following, depending on what it finds in the database:
If the database lists a language that matches the value of NlsLang, Oracle Payments keeps the value of NlsLang and passes it to the payment system servlet.
If the database does not list a language matching the value of NlsLang, Oracle Payments uses the language specified as the preferred language for that payment system, thus changing the value of NlsLang before sending it to the payment system servlet.
Finally, Oracle Payments converts the values of other parameters so they are sent to the payment system servlet in the language specified by NlsLang.
This conversion process works only in one direction; from the source product to the payment system servlet. If the payment system sets up NlsLang when it sends the data back, Oracle Payments uses that information to store the value of OapfVendErrmsg in its database. Oracle Payments does not convert data sent from the payment system servlet back to the source product.
The value of this parameter follows the same format as Oracle Server's NLS_LANG environment variable:
language_territory.charset
For example, JAPANESE_JAPAN.JA16EUC is a valid value for NlsLang.
Oracle Payments does not convert the response received from the payment system servlet in the response body. It only treats the data as binary and sends it directly to the source product.
However, if any binary information is sent, such as wallet data, then Oracle Payments converts the character set of the binary data to that specified by the value of NlsLang.
This section presents planning questions relevant to funds capture.
For funds capture functionality, you must decide how settlements are to be grouped into settlement batches. Parameters for grouping can be specified in the funds capture process profile. For information on funds capture process profiles, see Step 21. Setting Up Funds Capture Process Profiles.
For funds capture functionality, you must decide which credit card brands your company wishes to accept for payment, as well as their associated authorization validity periods, in days.
Related Topics
For information on setting up credit card brands, see Step 23. Setting Up Credit Card Brands.
Oracle Payments provides the following APIs:
Payment Instrument Registration APIs to store payment instruments such as credit cards, bank accounts, PINless debit cards, and purchase cards.
Payment Processing APIs to perform credit card, PINless debit card, and purchase card operations, such as authorization, capture, and bank account transfer operations
Risk Management APIs to perform risk analysis
For funds capture functionality, you must decide, based on your requirements, what functionality your source products need, which determines which APIs to use.
Note: Each preintegrated Oracle application already implements the Oracle Payments API relevant to its operation. If you use a preintegrated Oracle application, then no further integration is needed.
Payment instrument registration is required. Non-Oracle products can implement payment instruments registration using Payment Instrument Registration APIs and instrument identifiers that are generated using payment requests with Oracle Payments.
You must decide whether you want to:
implement online and/or offline payment processing
accept credit card, PINless debit card payments, purchase cards, or bank account transfers, or some combination
implement the risk functionality to detect fraudulent transactions
Once you decide on the functionality you wish to implement, you can then review the corresponding APIs on the Oracle Integration Repository at http://irep.oracle.com/.
Oracle Payments can run credit card risk management during the authorization phase. If you want to independently perform risk evaluation, then separate risk management APIs can be called from your source products.
Related Topics
For additional information on the preceding APIs, see the Oracle Integration Repository at http://irep.oracle.com/.
Oracle Payments supports bank account transfers as settlements. It also supports EFT online validations for bank account transfers. EFT validations help you verify that the payer's bank account is valid, but they do not place a hold on any funds and they are not offered by all payment systems or in all countries. The validations are online and real time, similar to credit card authorizations, whereas the actual funds transfers are performed offline as settlements. Funds transfers are not performed online since these transaction require one or two business days to complete.
The Source Product Reference number must not be the same as that of the Bank Account Transfer transaction number. It is usually the bank account transfer number plus one.
Related Topics
For information on implementing bank account transfers, see the Oracle Integration Repository at http://irep.oracle.com/.
Oracle Payments provides risk management functionality for credit card and purchase card transactions in E-Business applications. Oracle Payments includes a number of seeded risk factors and provides the option to payees or suppliers of running or not running the risk evaluation functionality for each authorization.
A risk factor includes any information which a payee wants to use to evaluate the risk of the customer wanting to buy goods or services from the payee. Examples of risk factors include address verification, time of purchase, and payment amount. These risk factors can be configured for each payee.
Risk management functionality enables payees to manage the risk involved in processing transactions online. It enables businesses to specify any number of predefined risk factors to verify the identity of their customers and assess their customer credit rating and risk rating in a secure environment.
Related Topics
This section presents planning questions relevant to funds disbursement.
Funds disbursement involves making payments from the first party payer, the deploying company, to third party payees, such as suppliers. A payment can be in electronic form, such as EFT or wire, or in printed form, such as a check.
For funds disbursement functionality, you must decide whether to setup more or less granular disbursement payment methods. The least granular payment methods are those seeded in Oracle Payments, such as Check or Electronic. They describe methods of making payments at the highest level. Under this kind of setup, you can associate many payment process profiles and payment formats with each method. This requires less knowledge from source product users such as invoice entry clerks, but possibly more work later in the payment process.
Alternately, you can define more granular payment methods and associate each to a single payment format and payment process profile. You can even choose to associate specific validations to each payment method. An example of a very granular payment method is Italian Electronic Funds Transfer. With this kind of setup, the source product user needs more knowledge. This approach has advantages, however. For example, payment method validations are run earlier at invoice entry time and thus, errors can be fixed more quickly.
Creating a funds disbursement payment method includes creating usage rules and setting validations. Usage rules specify when a disbursement payment method is available for use by source products for documents payable. By creating usage rules, you enable or disable payment methods for each source product integrated with Oracle Payments. You can provide different usage rules for different source products and change whether and when the payment method is available. Additionally, you can set validations so they run early in the payment process.
Related Topics
For information on funds disbursement payment methods, see Step 12. Setting Up Funds Disbursement Payment Methods.