Understanding Oracle Payments

Functionality Common to Both Funds Capture and Funds Disbursement

Payments functionality that is common to both the Funds Capture and the Funds Disbursements sides of Oracle Payments is the following:

access control
APIs
servlets
transmission
security

Understanding Access Control

Access control is an Oracle Payments feature that enables you to control user access in viewing and/or updating data. It is primarily used to secure transaction data and is controlled by the user's security profile. Access control in Oracle Payments that is controlled by permissions on multiple organizations is known as Multiple Organization Access Control (MOAC). MOAC is setup using profiles in Oracle HRMS (Human Resource Management System), where you specify an organization or a hierarchy of organizations to which the user has access. The profile is then assigned to the user, responsibility, or other level.

Overview

Companies model their business units in various ways to maximize performance and cost savings. Oracle Payments can be configured to support a variety of payment models. It can work in a completely decentralized model, where each organization within the company handles its own financial activities. Alternatively, if a company decides to centralize its financial activities in a shared service center, Oracle Payments can efficiently support the shared service center model also.

Additionally, Oracle Payments provides support to companies that wish to use the payment factory model. The payment factory model enables operating units to maintain their own accounts payable and other payment administrative functions. The payment factory handles communication and transactions with the deploying company's banking partners. Invoice selection occurs in Oracle Payables within a single operating unit. Then a payment factory administrator uses Oracle Payments to consolidate payments from different operating units into a single payment file for transmission and settlement, thereby reducing transaction costs.

Payment Function

A payment function is the type of payment made or captured by a source product. Each document payable has a payment function. For example, Oracle Payables supports the payment functions of making payments to suppliers and others. Different applications have different payment functions. In Oracle Payments, you can limit users to certain payment functions.

Multi-Organization Access Control (MOAC)

Oracle Payments supports Multi-Organization Access Control (MOAC). MOAC is a subfeature of Access Control that enables you to define multiple organizations and the relationships among them within a single installation of Oracle Applications. These organizations can be operating units, business groups, legal entities, sets of books, or inventory organizations.

The primary advantage of MOAC is that you can take action on documents in different operating units without logging into different responsibilities. Data security is maintained using security profiles that are defined for a list of operating units for which specific users are given data access privileges.

Access Control in Read-Only Pages

In read-only pages, you can only view documents or payments for which you have access. That is, the data you see displayed is that to which you have access.

Conversely, you are unable to view documents or payments that belong to an organization or payment function to which you do not have access. However, payment process requests, payment instructions, and funds settlement batches can contain data from multiple organizations and are not organization-specific. In these cases, if you have access to an organization that owns data in the request, instruction, or settlement batch, you will be able to see them. But within that request, instruction, or settlement batch, you will only be able to see the transaction data owned by the organizations to which you have access.

Access Control in Action Pages

Action pages are those pages where you take any kind of action on documents payable, payments, payment process requests, payment instructions, funds settlement transactions, or settlement batches. This includes printing checks, correcting validation errors, or taking other actions in the Funds Capture and Funds Disbursement Dashboards. You can only act on an entity if you have access to everything within the entity. For example, if a payment instruction includes payments for Organization 1 and Organization 2, and you only have access to Organization 1, you will be unable to go to any action page for the payment instruction. That is, if you only have partial access to the data in an object, you are unable to access that object. In this event, a message indicating that you do not have full access to the object is shown.

Access Control in Disbursement System Options Setup Page

In the Disbursement System Options setup page, you can view and update organization-level system options only for those organizations to which you have access. Oracle Payments restricts what you can see and update, in that you only see that for which you have access.

Access Control in all Other Setup Pages

In all other setup pages, Oracle Payments does not restrict you from what you can see and update, regardless of access control.

Access Control in Payment Process Concurrent Programs

The following concurrent programs are restricted by your access to organizations:

Create Payment Instructions: Funds Disbursement. The program will only pick up those payments for which you have permission to take action.
Create Settlement Batches: Funds Capture. The program will only pick up those transactions for which you have permission.

Understanding Oracle Payments APIs

Oracle Payments provides two types of APIs to simplify the integration of existing or new applications with Oracle Payments for payment processing.

Oracle Applications APIs: Oracle Applications use these APIs to integrate with Oracle Payments for funds capture and funds disbursement. These are internal to Oracle Applications.
Electronic Commerce APIs: Third-party applications can use these APIs to integrate their applications with Oracle Payments for funds settlement transactions. The third-party application can be a stand-alone application that communicates with Oracle Payments via Java APIs or PL/SQL APIs.
Payment System Integration: You can integrate with payment systems by creating or updating XML Publisher templates, transmission configurations, and payment system servlets. The templates are used to translate payment data into a payment system's format. Transmission configurations contain the details of transmission to payment systems and servlets manage the actual transmission process. Oracle Payments provides the Payment System Integration Model to interface with payment gateways and payment processors.

Understanding Oracle Payments Servlets

Oracle Payments consists of the following servlets:

ECServlet

The ECServlet provides an interface to the Oracle Payments engine to process payment-related funds capture operations such as authorization. This servlet is primarily used for the PL/SQL APIs provided by Oracle Payments.

Payment system servlets

Payment system servlets take payment files, as formatted by Oracle Payments, and transmit them to payment systems according to transmission configurations set up in Oracle Payments. Oracle Payments bundles payment system servlets developed by Oracle and/or interfaces with servlets developed by its payment system partners. The payment systems communicate with the payment acquirers or banks to process payment transactions. Oracle Payments includes payment system servlets for Paymentech, First Data (North), and Concord EFSnet. Some payment systems, such as VeriSign, have built their own Oracle Payment servlets.

Field-installable servlets

Oracle Payment supports field-installable servlets. These payment system servlets are not bundled with Oracle Payments. This feature allows a payee to acquire a new, additional, or upgraded payment system servlet and configure it in the same way as the payment system servlets bundled with Oracle Payments.

The ability to add field-installable servlets provides payment flexibility and allows new releases of Oracle Payments and the payment systems to be independent of each other. It also enables users of source products to customize the payment system for their specific needs and regions.

Field-installable payment system servlets for Oracle Payments are available from Oracle's payment system partners, or can be custom built.

Understanding Transmission

To transmit data to or from a payment system, you need a transmission protocol and a transmission configuration. First, you must have a transmission protocol, which defines the method of transmission. Transmission configurations, which specify concrete transmission details, must be associated with one transmission protocol.

To illustrate, Oracle Payments supports a generic transmission protocol for flat files called File Transfer Protocol for Static File Names. This protocol is a generic method to electronically transmit data, whereas FTP to Paymentech is a specific transmission configuration that specifies how to transmit data to a specific location using FTP as the method.

On the funds capture side, the transmission protocol and configuration are associated with the funds capture process profile, whereas on the funds disbursement side, the transmission configuration is associated with the payment process profile.

Transmission Protocol

Oracle Payments seeds transmission protocols, which are used by all funds capture process profiles and may be used by payment process profiles. These common seeded protocols, such as FTP, are comprised of the following:

a code entry point, which the payment system servlet uses to accomplish transmission
a list of parameters, such as network address and port, for which the transmission configuration must supply values
transmission protocol entry points, which are independent of payment servlets and may be invoked from the Oracle Payments engine

You can view the seeded transmission protocols in Oracle Payments setup pages.

Transmission Configuration

Each transmission protocol has parameters that require values. The values defined for the parameters comprise the transmission configuration for the transmission protocol. For example, the payment system, Paymentech, may require a Socket IP Address of X and a Socket Port number of Y, among other values. Together XY, and the other values, represent Transmission Configuration A for a given transmission protocol.

Understanding Oracle Payments Security

Oracle Payments stores and processes highly sensitive financial data. To ensure proper security of this data, the Oracle Payments has advanced security features. Oracle Payments has several features to ensure the security and privacy of your data.

This section explains the security features of Oracle Payments and describes the setup required to properly utilize these features.

Multiple Organization Access Control

MOAC (Multi-Organization Access Control) is part of the Oracle Payments security feature. For information on MOAC, see Multi-Organization Access Control (MOAC).

Payment Instrument Encryption

Payment Instrument Encryption is an advanced Oracle Payments security feature that enables Oracle Applications to encrypt credit card data. This feature assists with your compliance with the cardholder data protection requirements of the Payment Card Industry (PCI) Data Security Standard and with Visa's Cardholder Information Security Program (CISP). The Visa program is based on the PCI Data Security Standard. When the feature is enabled, credit card and bank account numbers for external third parties, such as customers, suppliers, or students are encrypted.

Note: Other products such as iExpenses do store internal credit card numbers in Oracle Payments' tables.

Adoption of the Payment Instrument Encryption feature should be part of the implementation of a complete security policy, which is specific to your organization. For example, your security policy should include a regular schedule to rotate keys to secure your payment instrument data. For general guidelines on securing Oracle E-Business Suite applications products, see Best Practices for Securing Oracle E-Business Suite, Oracle MetaLink Document 189367.1.

Oracle Payments Engine to Oracle Payments Servlet Communication

Oracle Payments architecture lets you install the payment system servlet in a machine outside the firewall. If you have installed either Oracle Payments (or its components) or the source product in a distributed environment, Oracle recommends configuring SSL between Oracle Payments and the payment system components. You can create an Oracle Wallet to store certificates and credential information to support authentication of the engine, in this case a client of the servlet, by the server running the servlet. You can specify the wallet location and password using FND profiles. You can configure the server where the servlet is running to request client certificates (on the engine side). Oracle Payments retrieves the certificates from the Oracle Wallet and sends the certificates to the server for authentication. Oracle Payments also supports basic authentication of the payment system by the servlet.

These security features are recommended to guard against unauthorized access to data and Oracle Payments services. Oracle iAS web server (Apache Server) provides several types of authentication that you can use to secure servers, listeners, and servlets.

Firewall Protection

Oracle strongly recommends that you install Oracle Payments and the payment system servlets on a machine inside the firewall.

Secure Socket Layer

If either Oracle Payments (or its components) or the source product is installed in a distributed environment, Oracle recommends enabling SSL communication between Oracle Payments and the payment system components.

Basic Authentication for Payment Systems

For setting up security for basic authentication between Oracle Payments and payment system servlets, you must perform some tasks both in the Oracle Payments setup user interface and in the Apache Server administration tool. While configuring Oracle Payments for a particular payment system, you must assign the payment system user name and password in the payment system configuration screens. You must assign the same user name and password in the Apache Server that runs the payment system servlets.

For details on setting up basic authentication in Apache Server, see the Apache Server documentation.

IP Address Restriction

In addition to using the merchant user name and password, you can restrict access to Oracle Payments and payment systems through IP address restriction. By using IP address restriction, a feature of the Apache Server, you can specify one or both of the following parameters:

The IP addresses of all trusted hosts (machines from which the web server should accept transaction requests for Oracle Payments)
The IP addresses of some non-trusted hosts (machines from which the web server should refuse transaction requests for Oracle Payments)

If a request is from a machine on the trusted list, Oracle Payments processes the requested transaction. If the request is from a machine on the non-trusted list, Apache Server denies the request and prevents Oracle Payments from processing it.

Through IP address restriction, you can limit access to all operations from non-trusted machines.

For more information about IP address restriction, including how to specify trusted hosts, see Apache Server documentation.

Other Security Related Information

Separate HTTP ports for site administration and Oracle Payments administration increases security.

Related Topics

For information on Oracle Wallet, see Oracle E-Business Suite System Administrator's Security Guide.

Understanding Funds Capture

This section presents functionality and terms that are relevant to the funds capture process.

Understanding Funds Capture Process Profile

On the funds capture side, the funds capture process profile is a blueprint, which contains information that tells Oracle Payments how to communicate with the payment system. The funds capture process profile contains information for each of the following steps of the funds capture control process:

online payer verification for a bank account transfer, online authorization for a credit card payment, or online debit for a debit card payment
notification
acknowledgement
rules for building settlements into batches

The funds capture process profile on the funds capture side plays the same role as the payment process profile on the funds disbursement side. The funds capture process profile is defined to control the behavior of all funds capture operations, as listed above. Unlike the payment process profile, however, the funds capture process profile is always derived from routing rules, which are created during Payee setup.

Funds capture process profiles also specify the payment system account to be used for processing transactions.

Understanding Payment Methods (Funds Capture)

On the funds capture side of Oracle Payments, a payment method is the medium by which a third party payer chooses to remit payment to the first party payee. For example, a customer remits payment for a product or service to the deploying company. Oracle Payments supports the following payment methods for automated funds capture processing:

bank account transfers
credit cards
PINless debit cards
bills receivable remittances

Oracle Payments enables flexible setup of funds capture payment methods as follows:

You can define unique payment methods for bank account transfers.
Oracle Payments seeds a single payment method for credit card and PINless debit cards.

Understanding Payees

In Oracle Payments, the payee represents a first party entity that is collecting money from customers (in the case of funds capture payments). A payee also has a business relationship with a payment system, in which the payment system processes transactions for the payee.

You can have more than one payee in Oracle Payments for funds capture. You can have multiple payees, for example, because different business units or legal entities in one organization want to process transactions through different payment systems, or use separate relationships with a payment system.

When you create a payee in Oracle Payments, you must specify several pieces of information.

organizations for which this payee processes transactions
a list of payment instrument types that the payee accepts
payment system accounts and funds capture process profiles that this payee uses to process transactions
risk formulas
routing rules

Integration with Other Oracle Applications

Oracle Payments integrates with other Oracle Applications to provide payment processing across your enterprise. Various source products send transaction requests to Oracle Payments for processing. Without Oracle Payment, each of these applications would need to build its own integrations to payment systems. Oracle Payment saves integration effort by providing a single source to payment systems such as Concord EFSnet, First Data North, and other country-specific or region-specific payment systems.

Example of a Payment Processing Flow Using Oracle Payments and Other Oracle Applications:

Sales application (for example, iStore or TeleSales): A customer purchases a product and decides to pay by credit card. The sales application submits the order.
Order Capture or Order Management: Order Capture and Order Management process the order. Both use Oracle Payments to verify if the credit card number is valid and authorize the order amount. They can also perform some risk evaluation as part of the authorization.
Oracle Receivables: When the order is shipped, the transaction information is passed to Oracle Receivables and the billing and takes place.
Oracle Collections: When the payment is overdue and your call center begins funds disbursement collection attempts, Oracle Collections uses Oracle Payments to authorize and settle credit card transactions.

Oracle Payments Integration with Oracle Applications

Understanding Credit Card Transactions

Among funds capture payments, Oracle Payments handles credit card, PINless debit card, purchase card, and EFT transactions. This section explains the process flow for a typical credit card transaction.

Traditional Credit Card Transactions

Traditional credit card transaction processing involves a third party payer, a first party payee, an issuing bank, an acquiring bank, a payment processor, and, optionally, a payment gateway.

A credit card transaction consists of two phases: authorization and settlement. A typical flow might occur as follows:

Authorization

The third party payer purchases goods or services and sends credit card information as part of an order or invoice to the first party payee.

The first party payee accepts the order and sends an authorization request to the payment processor through Oracle Payments and optionally a payment gateway.

The payment processor matches the information with a database maintained by the issuing bank to determine if the customer has enough available credit to cover the transaction. If so, then the payment processor reserves the funds and sends an authorization code back to Oracle Payments.
Settlement

The first party payee delivers goods to the customer and needs to settle the transaction, that is, capture the funds reserved in the authorization. Settlement may occur at the same time as authorization. Settling transactions includes batch administration.

The first party payee issues capture, void, return, credit, and settlement batch functions to the payment processor through Oracle Payments and optionally, the payment gateway.

The payment processor settles the payment with the issuing bank and causes the funds to transfer to the acquiring bank.

Voice Authorization

Sometimes credit card processing networks decline transactions with a referral message indicating that the merchant must call the cardholder's issuing bank to complete the transaction. The payment information in such cases is submitted over the phone. If the transaction is approved, the merchant is provided with an authorization code for the transaction. To facilitate follow-on transactions through Oracle Payments for this voice authorization (for example, capture or void), Oracle Payments provides voice authorization support for gateway-model and processor-model payment systems.

Understanding Purchase Cards

A purchase card is a type of credit card that is issued by an organization to its employees. The card is generally used by the employees for purchasing corporate supplies and services. Payments are made by the corporate buyer to the card issuer.

Benefits of Purchase Cards to the Merchant (First Party Payee)

Businesses use purchase cards to cut costs and streamline labor intensive processes to procure goods and services. As a result, many buyers prefer merchants that accept purchase cards.
Merchants generally receive better rates from card associations or issuing banks with purchase cards than with credit cards.

Benefits of Purchase Cards to the Buyer (Third Party Payer)

A better reconciliation stream by providing purchase order number and additional information.
Aggregation of purchases when companies receive one invoice for multiple purchase cards.
Streamlining the purchase order process. Lower processing costs by simplifying the purchasing process, reducing paperwork, and automating controls on the spending limits.
Merchants accepting purchase cards help the buyer by making purchase information available electronically. This may help companies (buyers) comply with tax regulations, reporting requirements, and expense reconciliation.

Purchase Card Data Levels

For a purchase card, three levels of data can be captured and sent by a merchant to the buyer organization through the payment system. They are:

Level I:

Level I transaction data consists of only basic data. A standard credit card transaction provides level I data to the processor. The buyer cannot derive any special benefits from purchase card usage if the merchant passes only level I data.

Level II:

Level II transaction data consists of data such as tax amount and order number in addition to level I data.

Level III:

Level III line item detail provides specific purchase information such as item description, quantity, unit of measure and price. This information is very useful to the buyer to help streamline accounting and business practices and to merge payment data with electronic procurement systems. Data in the table below is only indicative. The actual fields are payment system-dependent.

Note: Oracle Payments supports Level III data for both payment processors and gateway model payment systems.

The table below lists information on data that is passed by Oracle Payments in each level.

Data	Level 1	Level 2	Level 3
Card Number	X	X	X
Card Holder Name	X	X	X
Card Expiration Date	X	X	X
Card Holder Billing Address	X	X	X
Currency Code	X	X	X
Tax Amount		X	X
Transaction/Order Number		X	X
Ship from Postal Code		X	X
Destination Postal Code		X	X
Discount Amount			X
Freight Amount			X
Duty Amount			X
Line Item Information			X

Processing Purchase Card Transactions

The transaction phases in a purchase card transaction are the same as in a credit card transaction. The phases are authorization and settlement. For more information about transaction phases, see Understanding Credit Card Transactions.

Oracle Payments automatically recognizes purchase cards based on a set of seeded card number ranges. Oracle Payments passes additional information to the payment system during the settlement or settlement batch operation and through Gateway online requests. Authorization and other settlement operations carry the same information for purchase cards as they do for credit cards.

Understanding PINless Debit Card Transactions

PINless debit card transactions are a type of payment method offered by some payment systems to first party payees in selected industries that are traditionally viewed as recurring billers. The consumer initiates the debit card payment process without providing a PIN. The merchant authenticates the consumers and assumes 100% liability for the transaction and any subsequent adjustments.

Process Flow for Gateway-Model Payment System

Most gateway type payment systems handle PINless debit card transactions in a single step. After receiving the authorization request, the payment system will send the transaction to the debit network. The consumer's account (payer) is debited after the authorization request is approved. The merchant's account (payee) is credited sometime later. PINless debit card transactions are different from the process flow of credit card transactions where the authorization and fund capture are separated into two steps.

To ease integrations for source products, Payments requires an authorization, but allows settlement to be optional.

The authorization step routes and sends the transaction to the payment system, saves the transaction into Oracle Payments and returns the authorization response to the source product (similar to credit cards).

If the source product invokes settlement, the original transaction is retrieved from Oracle Payments schema. If the transaction was authorized, a Success message is returned to the source product.

Process Flow for Processor-Model Payment System

For most payment processors, the flow for PINless debit cards is identical as that for payment gateways. However, some processor type payment systems (such as Paymentech) require an additional settlement step to complete the transaction. The first party payer's account will be credited after settlement and the fund transfer is said to be completed.

To ease integrations for source products, Payments requires an authorization, but allows settlement to be optional. If a payment system requires a settlement step, Payments automatically performs that step without input from the source product.

As in the gateway case, if the source product does invoke settlement, the original transaction is retrieved from Oracle Payments. If the transaction was authorized, a Success message is returned to the source product.

Understanding Funds Capture Bank Account Transfers

Oracle Payments supports funds capture bank account transfers for both business-to-consumer and business-to-business models. The funds capture bank transfer functionality facilitates electronic transfer of payment amounts from a customer's bank account to the payee's bank account.

Electronic Funds Transfer (EFT) Online Validations

EFT online validations are a real time service provided by some payment systems to validate the third party payer bank account to be used in an EFT transaction. EFT online validations service ensures that the third party payer's bank account instrument exists and that there is no fraud alert. Electronic funds transfer transactions are not real time, since one or two business days are needed to complete the transaction. It is not possible, therefore to ensure that the bank account is still open and has sufficient funds. EFT online validation assists with validity checking as follows:

The validation step is an optional step for EFT transactions. It can be performed any number of times.
The validation is performed in real time.
The EFT online validation response message shares the same message standard with the credit card authorization response message for processor type payment systems.

Note: EFT online validation is only offered for United States ACH and not for all payment systems. EFT online validation checks whether a bank account exists and that the account is not flagged as fraudulent. EFT online validation does not reserve funds or check if the account has sufficient funds.

Understanding Gateway-Model and Processor-Model Payment Systems

Oracle Payments supports both gateway-model and processor-model payment systems. The processor model describes the interface between Oracle Payments and a payment processor. A payment processor is a service that interacts directly with banks and card institutions such as Visa, Mastercard, and American Express, to process financial transactions. The gateway model describes the interface between Oracle Payments and a payment gateway. A payment gateway is a service provider that acts as an intermediary between a first party payee and a payment processor.

The choice of integrating to a gateway-model or processor-model payment system is generally determined by the business type, number of transactions per day, and the acquiring bank. Processors typically have more rigorous security, connectivity, and testing requirements. Gateways provide ease-of-use, often using SSL based internet connectivity. Gateways charge additional fees (including per-transaction fees), beyond what the processor charges. Typically, pricing varies by payment system and the processor model payment systems often favors higher-volume merchants who are willing to put forth the effort and cost of processor connectivity. The Gateway model favors lower-volume merchants, or merchants who are willing to pay a per-transaction premium for easier set up and connectivity.

A gateway-based system takes all transactions online. A processor-based system allows authorizations in real-time and follow-up transactions such as settlements and credits offline. Offline transactions must be batched together and sent as a single request to the payment system. All transactions other than authorizations are, by default, performed offline. Offline transactions are sent to the processor when the next settlement batch operation is attempted.

You can create settlement batches manually or automatically according to a schedule, using the Funds Capture Process Home or the concurrent request manager. You can retrieve the final statuses of transactions in a settlement batch by retrieving clearing information. This is also done through the Funds Capture Process Home or the concurrent request manager.

Credit cards cannot be clubbed with other settlement batch. The settlement batch for refund is always a follow on transaction.

Understanding Terminal-Based and Host-Based Merchants

For gateway-model payment systems, Oracle Payments supports these processing models that the financial industry uses for credit card transactions:

Terminal-Based Merchant

The first party payee determines when the payment gateway should create settlement batches.
Host-Based Merchant

In this model, the payment gateway's host machine maintains all the transactions and is usually responsible for settlement batch operations at a predetermined frequency.

The choice of being a terminal-based or host-based merchant is generally determined by the business type, number of transactions per day, and the model supported by the payment gateway. The processing model that you choose affects how you perform the settlement operations. For a terminal-based merchant model, you must periodically perform settlement batch operations. Consult your acquiring bank for more information when you sign up.

Understanding Offline and Online Payments

Oracle Payments supports two models of payment processing for credit, purchase, and PINless debit cards as follows:

Funds capture bank account transfers are always offline.

The types of operations that you can process online depends on the payment system type you have chosen: gateway or processor model and your operation model: host-based or terminal-based.

For processor model payment systems, authorization operations must be online and settlement operations are offline. For gateway payment systems, both authorization and capture operations can be online.

Online Payment Processing

Online payment processing is the model in which a transaction is immediately forwarded to the payment system processor. The results from the payment system are immediately returned to the source product. Online transactions are supported for credit, purchase, and PINless debit cards. Online validation transactions are supported for Electronic Funds Transfer.

Offline Payment Processing

Offline payment processing is the model in which transactions are not immediately forwarded to payment systems. When a source product submits a transaction in a scheduled mode, or if the payment is predated, the payment information is saved in the Oracle Payments database and is sent to the payment system at a later time.

The offline method uses a concurrent program that submits offline transactions at regular intervals. The program browses the stored transactions and sends transactions to the payment systems and updates to the source products.

Understanding Risk Management

Fraudulent credit card payments continue to grow in number, as do subsequent losses by banks and merchants. Improved fraud detection has, therefore, become essential.

Oracle Payments provides risk management functionality for credit card and purchase card transactions. Oracle Payments includes a number of built-in risk factors and provides the ability to adjust risk calculation formulas and risk thresholds.

A risk factor includes any information which a first party payee wants to use to evaluate the risk of fraud when a third party payer attempts to make a payment. Examples of risk factors are: address verification, time of purchase and payment amount. These risk factors can be configured for each first party payee.

Risk management functionality enables first party payees to manage the risk involved in processing transactions online. It allows businesses to have several predefined risk factors to verify the identity of their customers and to assess their customers' credit rating and risk rating in a secure environment.

First party payees can associate the risk factors with different weights as a formula and define any number of risk formulas in Oracle Payments based on their business model. When a source product requests an authorization, it can specify the formula to be used to assess risk. When the source product requests an authorization with a risk formula specified, Oracle Payments evaluates the risk and, in parallel, sends the authorization request to the payment system. After getting a response from the payment system, Oracle Payments returns both the authorization code and the risk score to the source product. The source product now decides whether to continue with the transaction and make a settlement or discontinue the transaction.

Alternatively, the Risk API can be called independently of the authorization APIs. Using the Risk API separately allows merchants to evaluate risk first. Depending on the risk score, first party payees may not want to submit the authorization to a payment system and incur a transaction charge. Please note that when the source product calls the Risk API separately, Oracle Payments cannot evaluate the risk scores associated with AVS (Address Verification System). Oracle Payments gets the AVS codes directly from the payment system during an authorization request. As no authorization request is sent in this scenario, Oracle Payments cannot get AVS codes from the payment system and hence cannot evaluate risks scores associated with AVS.

Risk management helps businesses in reducing manual operational overheads to handle bad transactions and in avoiding costly penalties such as chargebacks from banks.

Note: Oracle Payments does not support risk management for PINless debit card or bank account transfer transactions.

Risk Factors Shipped with Oracle Payments

The following is a list of basic risk factors shipped with the Risk Management component. These risk factors can be configured per payee.

Payment amount limit is the amount involved in a payment request. It varies from business to business and the risk factor score can be configured for different amount ranges based on the business model.
Time of purchase is the time that a payment request is made by the customer. Site administrators can define the time duration during which the payment requests are high risk and assign the risk factor scores for each duration.
Ship to/bill to address is used to match the ship to address to the bill to address in a payment request. A payment request is considered high risk if these two addresses do not match.
Risky payment instruments are a list of payment instruments (e.g, credit cards, bank accounts) that are considered risky by each payee. These include the instruments that were used by customers earlier and had resulted in fraud or chargebacks. Such a list can be generated internally by the payee or obtained from other sources. If these instruments are reused in a payment request, then the payee may again face fraud or chargeback. Risk management functionality can detect whether risky payment instruments are being used during processing by looking at the risky instrument repository. If the instrument being used for the payment is found in the repository, then the payment is considered a high risk payment. The Risky Instruments Upload Utility adds and deletes a list of risky instruments from the database.
Transaction amount is the total amount of payments made by a customer using the same instrument in a specified duration of time. The duration of time is set up by the user. This is related to the payment amount limit risk factor. A customer can make payments in smaller amounts, which are not captured by the payment amount limit risk factor but can be captured by the transaction amount risk factor. Transaction amount risk factor sums up the total amount of payments in a specific duration of time and captures the risk on that amount. The total number of payments made during a specific time period can be checked by looking at the payment history. The site administrator can set up a time duration and a transaction amount. In evaluating this risk factor, if the total payment amount exceeds the transaction amount within the specified time duration, then the payment is considered a high risk payment.
Payment history tracks the reliability of the payer involved in a payment request. If a payer has a good history of payments over a long duration, then payments requested by this payer are considered to be low risk payments.
Address verification service (AVS) check is the risk involved on the AVS code that is returned by the credit card network. Address verification service is provided by MasterCard and Visa credit card networks to match the billing or shipping address with the address that is maintained for the cardholder by the issuing bank. Oracle Payments does address verification during an authorization request, by calling the payment system with the address and zip code information along with the payment transaction information. The payment system then does the authorization and also returns various AVS codes to Oracle Payments. Various AVS codes are returned based on the complete address match, zip code match, street address match, etc. A site administrator can configure all AVS codes returned by the payment systems and their corresponding risk factor scores. This service is only provided in the United States of America.
Frequency of purchase tracks the sudden surge in the use of a payment instrument in a short duration. For a particular payment instrument in a payment request, if the frequency of use in a duration configured is more than the setup value, then the payment request is considered to be a high risk payment.

Oracle Receivables Risk Factors

For customers who have both Oracle Payments and Oracle Receivables installed and registered, more risk factors are available. These risk factors are set up in Oracle Payments and the values of these risk factors are set up in Oracle Receivables. Oracle Receivables stores credit management information about customer accounts such as credit rating and risk rating. The following are risk factors used in risk analysis:

Credit limit is an overall credit limit associated with a customer's account. If a customer has an outstanding balance and the total amount of payment made by the customer exceeds the overall credit limit, then the payment becomes a high risk payment. Overall credit limit varies from business to business. It can be set up as an overall credit limit at the customer or site level through Oracle Receivables.
Transaction credit limit is the credit limit per transaction associated with a customer's account. When a payment request exceeds the transaction credit limit, it becomes a risky payment. The transaction credit limit varies from business to business. It can be set up at the customer or site level through Oracle Receivables.
Credit rating is the information that enables payees to effectively manage financial terms with their customers. It is useful for online financing or in evaluating purchases of a large amount by a new customer. Credit Rating is a user defined field and the information can be taken from Oracle Receivables. A payee associates risk scores to credit rating. A higher risk score implies that selling goods or services to the customer is risky.
Risk code is a user defined risk assessment field in Oracle Receivables. It is useful for online financing or for evaluating purchases of a large amount for a new customer. The information is available from Oracle Receivables. A payee associates risk scores to all the risk codes. A higher risk score implies that selling goods or services to the customer is risky.

Oracle Payments Routing and Operation

Oracle Payments accepts funds capture payment transactions from source products and routes them to the appropriate payment systems using the appropriate payment system account and funds capture payment profile. Each payee can have its own set of routing rules with its own set of priorities.

What Constitutes a Routing Rule?

Every routing rule is made up of the following components:

Basic Rule Information - This information is used to select and rank all the rules that may be applicable to a payment transaction. The basic rule information consists of Rule Name and Payment Method.
Destination Information - The destination information specifies the payment system to which the payment transaction should be routed and how it should be sent. The destination information consists of Payment System Account and Funds Capture Process Profile.
Routing Rule Conditions - This specifies the conditions under which a rule becomes applicable to a payment transaction. A rule condition is comprised of a criterion for the condition (such as Amount, Currency, Organization ID, Card Type, Card Number and Bank Routing Number), the type of operation related to the criterion, and the value of the criterion. Multiple rule conditions can be defined for a routing rule.

How Routing Works

Routing of a payment transaction is based on a set of routing rules set up in the Oracle Payments user interface by the Oracle Payments administrator. The routing engine finds the appropriate Payment System Account and Funds Capture Process Profile, and through them, the Payment System in the following sequence:

The routing engine retrieves the rules associated with the Payee and Payment Method specified in the payment request.
The routing rule with the highest priority is evaluated first. If the values in the transaction match the conditions specified in the routing rule, the request is routed to the corresponding Payment System using the specified Payment System Account and Funds Capture Process Profile.
If the values in the request do not match the conditions specified, the routing rule with the next highest priority is evaluated.
In case the payment request values do not match any of the conditions specified, the transaction is routed to the default Payment System using the default Payment System Account and Funds Capture Process Profile.

Routing rules are prioritized by an administrator. During processing, the rules are evaluated in the order in which they are prioritized.

Oracle Payments supports credit cards, purchase cards and bank account transfers. The payment methods available depend on the payment system that you decide to use.

Payees and businesses can customize how Oracle Payments routes transactions to the payment systems using routing rules based on their business rules and the available payment methods. For example:

A business sends all electronic payment transactions to a single payment system: Payment System A.
A business sends all small or micropayment transactions to Payment System A and all credit card transactions to Payment System B.
A business sends all bank account transfers under $10 to Payment System A, and all other transactions to Payment system B.
A business sends all transactions using US dollars to Payment System A and all transactions using other currencies to Payment System B.

Routing Rule Conditions

Routing rule conditions determine whether the rule is applicable to a payment transaction. A rule can have multiple rule conditions. A rule is applicable to a payment transaction only if the payment transaction can meet all the conditions for the rule. For example, a payee can route all Visa credit card transactions when the order amount is greater than 500 US dollars to Payment System C.

The following table lists the values in the Operation and Value fields for a selected payment instrument type and criterion.

Payment Instrument Type	Criterion	Operation	Value
Credit Card	Card Issuer	Equal, Not Equal To	Select a card issuer from the list of values.
Credit Card	Currency	Equal, Not Equal To	Select a currency from the list of values.
Credit Card	Amount	Greater than, Greater than or equal to, Less than, Less than or equal to	Specify a value.
Credit Card	Card Number	Equal, Not Equal To	* Specify a value.
PINless Debit Card	Card Issuer	Equal, Not Equal To	Select a card issuer from the list of values.
PINless Debit Card	Currency	Equal, Not Equal To	Select a currency from the list of values.
PINless Debit Card	Amount	Greater than, Greater than or equal to, Less than, Less than or equal to	Specify a value.
PINless Debit Card	Card Number	Equal, Not Equal To	* Specify a value.
Bank Account Transfer	Payer Bank Routing Number	Equal, Not Equal To	Specify a value.
Bank Account Transfer	Currency	Equal, Not Equal To	Select a currency.
Bank Account Transfer	Amount	Greater than, Greater than or equal to, Less than, Less than or equal to	Specify a value.

* - Value can be digits, spaces, dashes and wild card character (%). For example, if the value is 4111%, then the routing rule applies to all card numbers that begin with 4111.

Understanding Transaction Reporting

Oracle provides management summaries directly from the transaction data. Transaction reporting (TR) users can view indicators on a daily, weekly, or monthly basis, targeted to their particular lines of business and summarized across all processors, types of cards, and transaction types.

Transaction reporting lets every manager in an organization of any size to know the state of business transacted on credit and purchase cards on a daily basis, and to make mid-course corrections that drive the business towards achieving its goals. Transaction reporting helps enterprises achieve consistent, high-integrity information, corporate wide alignment, and collaborative decision making. A proactive e-mail notification system relieves the burden of constantly monitoring critical measures. Through transaction reporting, Oracle Payments provides an environment that supports mixed workloads, such as processing transactions versus running queries, without compromising on performance or scalability, providing the simplest, and therefore the least costly approach.

Functioning of the E-mail Push System

The Oracle Payments e-mail push system provides the ability to send e-mail notifications to specified users which frees mail from the need to monitor critical measures.

Any user with the Oracle Payments Daily Business Close User responsibility can run the e-mail push system by submitting a concurrent request. You can configure the Oracle Payments e-mail push system to send e-mails on a pre-defined schedule. The reports provide a daily summary of transactions. For best results, schedule the process to run at the close of business everyday. Specify the recipients for the e-mail notification by providing the e-mail ID or user names as parameters for the concurrent task. The user names must have valid e-mail IDs associated with them. Specify multiple recipients for a notification by separating the e-mail IDs or user names by a comma (',').

The e-mail push system sends the following information to the receiver after summarizing the transactions for that day.

Login URL
Date that the report was generated
Total number of transactions
Total transaction amount
Total number of authorization transactions
Total authorization amount
Total number of settled transactions
Total captured amount
Total number of credit/return transactions
Total credit/return amount
Total number of credit card transactions
Total credit card transactions amount
Total number of purchase card transactions
Total purchase card transactions amount

Scheduling E-mail Push Programs

To schedule concurrent requests for e-mail push programs:

Log in to Self Service Applications as any user with the Oracle Payments Daily Business Close User responsibility.

Choose the Oracle Payments Daily Business Close User if the user has multiple responsibilities linked to the user name.
Navigate to the Submit a New Request window.
Select the Single Request option.
From the Name choice list, select IBY Push E-mail Report.
Specify the recipient e-mail address. For multiple addresses, use the comma (',') as a separator.
To define a schedule, click Schedule.

The Schedule window appears.
Define the schedule.

Defining a schedule can be as simple as submitting as soon as possible or using a more complex schedule.
Click Submit.

Understanding Funds Disbursement

This section presents functionality and terms that are relevant to the funds disbursement process.

Understanding Documents Payable

A document payable is a transaction in a source product that is sent to Oracle Payments for payment. An example of a document payable in Oracle Payables is an invoice. During the payment process, documents payable are grouped together into actual payments.

Understanding Payments

A payment is a single transfer of funds from one person or organization to another via printed payment document or electronic transmission.

Payment Process

The payment process starts when a source product, such as Payables, needs to pay documents payable, such as invoices. The source product user groups the documents payable into a payment process request and submits the request to Oracle Payments. Within Oracle Payments, the Build Payments program takes the submitted documents payable, validates them, groups them into payments, and then validates the payments. Each payment consists of one or more documents payable. Next, the Create Payment Instructions program groups the payments into payment instructions, and then validates the payment instructions. Each payment represents a check that will be printed or a single electronic funds transfer transaction, depending on the type of processing selected. Each payment instruction results in one payment file that contains pertinent information on one or more payments, such as payment amount and an account to be credited or debited. In the case of electronic payments, the payment file includes the payment instructions in a format required by the financial institution. To actually make payments, you print checks or electronically transmit the payment instruction to an external payment system or to a financial institution.

The figure below depicts the high-level payment process.

Payment Process

the picture is described in the document text

Understanding Payment Methods (Funds Disbursement)

On the funds disbursement side of Oracle Payments, a payment method is a payment attribute on a document payable. The payment method indicates the medium by which a first party payer makes a payment to a third party payee. Payment methods also include other information used during the early stages of payment processing, such as validations and rules that determine how payment methods can be assigned to documents payable. Examples of funds disbursement payment methods include the following:

checks printed in-house by the payer
checks outsourced to the bank for printing
electronic funds transfers, through ACH in the United States or BACS in the United Kingdom
wires

Oracle Payments seeds some payment methods, but also enables you to define your own as well.

A source product user, such as an Oracle Payables associate, must select a payment method when entering a document payable, such as an invoice. The source product uses Oracle Payments setup to default payment methods onto each document payable and to restrict the user's choice of payment methods to encourage efficient payment processing.

Understanding Payment Process Profiles

A payment process profile is a payment attribute assigned to documents payable, which specifies handling of the documents payable, payments, and payment instructions by Oracle Payments. Payment process profiles include several types of information, including specifications for payment instruction formatting and transmission.

Payment process profiles can be assigned to documents payable either by the source product user or by the Oracle Payments payment administrator. The selection of valid payment process profiles is determined by the payment process profile's usage rules, which are created in Oracle Payments setup. Usage rules for payment process profiles can be based on payment method, payment currency, first party organization, or internal bank account.

Payments are built from documents payable that have the same payment process profile, among other attributes. Payment instructions are built from payments that have the same payment process profile, among other attributes. Therefore, the payment process profile is available to specify Oracle Payments behavior at every step of the payment process.

When you create a payment process profile, you must specify whether the profile governs payment processing for printed or electronic payments. Accordingly, the payment process profile allows you to assign appropriate payment document printing values or payment system communication configurations. The payment process profile also includes a payment instruction format, which is in turn associated with an XML Publisher template, as well as rules for grouping documents payable into payments and payments into payment instructions.

The relationship between payment process profiles and payment methods is many-to-many. For example, you can define one generic payment method like Electronic, and map it to any number of specific payment process profiles like: US Automated Clearing House and German EFT. Alternatively, you can set up specific payment methods that map one-to-one with payment process profiles. Additionally, you can define one payment process profile for multiple payment methods. This may be desirable when multiple payment methods can be handled by the same payment format. For example, the Germany Domestic profile can handle Outsourced Checks and EFT Payments payment methods.

For positive pay and electronic payment processing, payment process profiles are mapped to payment systems, payment system accounts, and transmission configurations.

Oracle Payments seeds a limited number of payment process profiles.

Understanding Payment Process Requests

A payment process request is a request created by a source product for Oracle Payments payment services. The payment process request, which originates in the source product during the documents payable selection process, contains one or more documents payable to be paid, along with information that allows Oracle Payments and the source product to identify the request and optional payment processing instructions. The source product may submit payment process requests to Oracle Payments via user action or concurrent program.

Once the payment process request is submitted to Oracle Payments, the Build Payments program validates the documents payable, groups the documents payable into payments according to document attributes and payment process profile grouping rules, and then validates the payments.

Understanding Payment Grouping

Payment grouping is set up using check boxes in the Payment Grouping region of the Create Payment Process Profile page. Selection of payment grouping attributes specifies that only payments with like payment grouping attributes will be included in a payment instruction when that Payment Process Profile is used during the Create Payment Instructions program.

Understanding Payment Instructions

A payment instruction contains one or more payments, along with aggregate payment information, and is created by running the Create Payment Instructions program. Depending on your setup, a payment instruction can be converted into a payment file to be printed onto payment documents, such as checks, or into a payment file that is transmitted to a payment system or financial institution for further processing and disbursement. To see the relationship between payment instructions and payments, see Payment Process.

Each payment instruction that is electronically transmitted to a payment system or financial institution is associated with a payment file. This payment file contains data that instructs the payment system or financial institution how to make the payment. The following information is typically included in electronically transmitted payment files:

number of payments to be made
amount of each payment
first party payer and third party payee bank account information
name of payees

The following information is typically included in printed payment files:

amount of each payment
numbering of checks
name of payees

Understanding Validations

Overview

In payment processing, it is critical to ensure that payment files sent to payment systems and financial institutions are valid, in addition to being correctly formatted. If this is not done, the payment process is slowed, which results in additional time and cost due to problem resolution. To help achieve straight-through processing, Oracle Payments enables you to ensure that payment-related validations are present.

Oracle Payments provides seeded validations that are associated with the supported payment formats by default. Validations are implemented using a flexible framework that enables you to assign new validation rules. You can choose between using the seeded library of validations, using your newly added validations, or using some combination of these rules.

Some of the system validations are:

Payee bank account must be active.
Checks whether the payment is resulting in international payment. If it is an international payment, then checks whether the "Allow international Payment" is selected at the Payee bank account level.
Checks whether the payment currency is same as the payee bank account currency. If it is not, then checks if it supports multi currency.

The default validation rules are business rules that are followed in the business. If you look at the validation rules mentioned, most of them are general standard practices followed in the business. There is no specific document on the default validations and we cannot document all the general business rules also.

Additionally, you have choices with respect to the timing of validation rule execution. Validations can be assigned toward the beginning or toward the end of the payment process. A combination of rule assignments can also be used. You can adapt validation rule assignment to support your business model. For example, assigning and executing validations toward the beginning of the payment process may be best for a decentralized payment environment, whereas assigning and executing validations toward the end of the payment process may be better in a shared service environment, where payment specialists can resolve validation failures.

Seeded validations can be assigned in one the following places:

Create Payment Method page--funds capture side
Create Payment Method page--funds disbursement side
Create/Update Format page

Validations are comprised of the following categories:

Pre-defined Validations
User-defined Validations

Country-Specific Validations

A country-specific validation is a validation related to a specific country. It is comprised of a code and multiple sub-validations that are required for the specific country, a validation point, and additional specifications regarding the payment formats and/or payment methods to which the validations are applicable. Country-specific validations are seeded by Oracle Payments and cannot be modified. For a listing of Oracle Payments seeded, country-specific validations, see Country-Specific Validations.

The table below describes the elements of a country-specific validation.

Elements of a Country-Specific Validation
Element	Description
Code	The internal code for the validation.
Sub-Validations	All the validations that are executed in a certain validation.
Validation Point	The point at which the validation is executed in the payment process. Validations occur at the following points in the payment process: Document Level in the Source Product: The validation is executed early in the process while the documents are created in the source product. The validation is run by the source product user while he/she, for example, is entering invoices in Payables. Example of a validation run at the document level in the source product: Assign validations to the payment method on the invoice Document Level in Oracle Payments: The validation is automatically executed late in the process by the Build Payments program as the documents are grouped into payments. Example of a validation run at the document level in Oracle Payments: Assign validations to the payment format. Payment Level in Oracle Payments: The validation is automatically executed late in the process by the Build Payments program as the documents are grouped into payments. This occurs when the validation is set on a field, such as the payment amount. Example of a validation run at the payment level in Oracle Payments: Assign validations to the payment amount on the payment. Payment Instruction Level in Oracle Payments: The validation is automatically executed late in the process by the Create Payment Instruction program as the payments are grouped into payment instructions. This occurs when the validation is set on a field, such as the payment instruction total amount. Example of a validation run at the payment instruction level in Oracle Payments: Assign validations to the total payment amount on the payment instruction.
Entity to which the Validation is Applicable	The entity to which the validation is linked. Oracle Payments enables you to control, through the user interface, which payment method or payment format will execute which validations. Certain applicability links are seeded by default. You can, however, change these applicabilities. For example, you can specify that you want a certain validation that is linked to a certain payment format to be applicable to another payment format as well.

User-Defined Validations

User-defined validations are basic validations that correspond to simple operations. For example, validating that the length of a certain field does not exceed a specific character limit is an example of a user-defined validation. These validations can be used as components, or building blocks, to build more complex validations. They enable you to validate, for example, the following conditions:

length of a field
whether a field is populated
whether a field contains non-numerical characters

To illustrate the application of user-defined validations, you can create a new payment format, for example, in the Create Format setup page and then assign validations to the newly created format.

Note: The user-defined validations are executed at the same points as the country-specific validations. For information on validation points, see the Validation Point, in the Elements of a Country-Specific Validation table.