|Oracle Payments User's Guide|
Part Number E13415-04
Note: This chapter assumes that Oracle Payments and all source products have been installed and properly set up. The user addressed in this chapter is the payment administrator, not the implementer.
This chapter provides the functional flows for funds capture.
For funds capture functionality, Oracle payments integrates with the following E-Business Suite products:
Oracle Lease Management
Oracle Order Capture
Oracle Order Management
Oracle Partner Management
Oracle Service Contracts
Oracle Student System
The Funds Capture Flow is an automated process using electronic payment methods, such as credit cards, debit cards, debits of bank accounts, and remittance of bills receivable to retrieve payment from the payer who owes a debt to the payee.
Oracle Payments supports the following categories of automated payment processing in the Funds Capture Flow:
debit card payments
credit card payments
bank account transfers (also known as electronic fund transfers)
remittance of bills receivable documents
The Funds Capture flow presents a view of the overall process that occurs when an application calls Oracle Payments for capturing funds automatically.
The Funds Capture Flow is comprised of the following phases:
Source product creates a transaction, which is used to store payment-related attributes.
Source product requests authorization from Oracle Payments for the transaction.
Source product passes the transaction and authorization information to Oracle Receivables.
Oracle Receivables initiates settlement process.
Oracle Payments settles the transaction.
The diagram below shows the steps performed in the Funds Capture Flow.
Funds Capture Flow Overview
The information below describes the steps performed in the Funds Capture Flow.
Source products interact with Oracle Payments when they create transactions that require automatic funds capture for settlement. When source products create transactions, they capture required payment attributes so Oracle Payments can perform the funds capture process.
Note: Creating a transaction is not the same as requesting an authorization or settlement. Instead, it is a preliminary step meant only for capturing payment information.
Source products request real-time authorization for the transaction from Oracle Payments. This step is required for credit cards and debit cards, and optional for bank account transfers. In the case of bank account transfers, this step is also called Electronic Funds Transfer Online Validation. When the source product requests an authorization, the transaction passes through Oracle Payments' instrument validation and/or authorization process. Payment attributes captured by the source products when they created the transactions are used in the authorization step.
This phase does not directly involve Oracle Payments. It involves the source product and Oracle Receivables. Source products pass the transaction and authorization to Oracle Receivables for future settlement. When Oracle Receivables accepts transactions from source products, it inherits payment attributes and authorization information. When Oracle Receivables creates its own manual transactions, it integrates with Oracle Payments to capture required payment attributes and obtain authorizations.
The final phase in the Funds Capture Flow is the settlement process, which is initiated from Oracle Receivables. During the settlement process, captured funds are processed and deposited into the first party payee’s bank account. The first party payee represents one or more organizations within the deploying company that receive funds as payment from third party payers (customers, paying students, and so on) via credit card payments, debit card payments, bank account transfers, or bills receivable transactions sent to banks.
The Create Transaction in Source Product Flow is the first flow of the funds capture process flows. This flow occurs when a source product creates a transaction for which funds must be captured for its settlement. Source Products are any products that accept payment instruments, such as credit cards or bank accounts, for automatic funds capture. Examples of source products are Oracle iStore, Oracle Order Management, and Oracle Student System. Oracle Receivables is also a source product when it creates its own invoices or receipts.
The diagram below shows the steps performed in the Create Transaction in Source Product Flow (F1).
Create Transaction in Source Product Flow
The information below describes the steps performed in the Create Transaction in Source Product Flow (F1).
The third party payer is set up by the source product's user. A third party payer is an entity or person who pays the first party payee to settle a debt. The third party payer is stored in Oracle Trading Community Architecture (TCA).
Third party payer setup is controlled by source products. It can be done before a transaction is created, as shown in the Create Transaction in Source Product Flow diagram or it can be performed during the transaction creation.
Payment related information about the third party payer is captured in the source product's user interface.
Information captured in this setup enables the first party payee to capture funds from the third party payer for payment. The first party payee is the deploying company that receives funds for payment by credit card payments, debits to bank accounts, or bills receivable transactions sent to banks. The payment-related information includes the default payment method that the first party payee has agreed to use with the third party payer and the payment instruments that the third party payer has authorized the payee to use, such as bank accounts or credit cards.
The information captured in the user interface is stored in the Payer Entity, which is a table owned by Oracle Payments. The Payer Entity is linked to the party in Trading Community Architecture.
The source product creates a transaction. This can be done online or automatically through any process that the source product uses to create transactions it owns.
This step captures information needed to settle payment for the transaction using Oracle Payments’ funds capture process. This step and the Select Payment Instrument step occur only after the information for the payer has been successfully captured.
First, the payment method is selected. A payment method is a payment attribute on a document receivable. The payment method indicates how the third party payer is going to make the payment. Examples of payment methods include the following:
credit card payments
debit card payments
bills receivable payments
The payment method is entered in a field on the transaction. Source products include this field in their user interface.
The payment instrument is selected. The payment instrument is the means used for settling a payment. Examples of payment instruments include the following:
Payment instruments are entered the same way as payment methods.
Any payment attributes needed for the transaction are captured. These are entered in the same way as the payment method and the payment instrument. Payment attributes vary depending on the instrument. For example, a credit card instrument may need an additional card security code captured.
When payment information is committed to the database, Oracle Payments performs required validations. These validations occur in both the user interface and in the Authorization API that Oracle Payments provides. Validations differ depending on how a transaction is settled. For example, validations for the use of a credit card vary from those required for a direct debit payment.
Validations performed at this stage are only those that Oracle Payments can execute immediately. It is not possible to conduct all validations immediately since some are payment-format specific and are unknown until later in the flow. The purpose of performing validations immediately is to make the source product user aware of issues as early as possible in the transaction payment cycle. This enables the source product user to take corrective action before the transaction requires settlement.
Information about the payment methods, payment instruments, and payment attributes collected by the source product is stored in the Transaction Payment-Extension Entity table owned by Oracle Payments. This database entity stores the data and creates a unique reference identifier for the transaction.
Oracle Payments returns information to the source product about the success or failure of capturing the information required for funds capture. Additionally, this step sends the unique reference identifier for the transaction to the source product.
The source product resolves any errors returned by Oracle Payments. Each source product is responsible for its own error handling.
Finally, the source product stores the unique reference identifier for the transaction in the Transaction Payment-Extension Entity table. Storing this reference identifier provides a permanent link between the transaction and its extension, known as the transaction extension. The transaction extension is a row in the Transaction Payment-Extension Entity table that contains the payment attributes of the transaction and an identifier that corresponds to the transaction.
The Authorize Transaction from Source Product Flow is the second flow of the funds capture process flows. This flow occurs when an source product requests authorization from Oracle Payments for the funds capture transaction.
Authorization is the real-time process that occurs within Oracle Payments that authorizes the payment instrument for the transaction amount when a funds capture transaction is confirmed. Authorization differs according to the following payment instrument types:
credit cards: the authorization process requests authorization and blocking of funds via the external payment processor and optionally includes risk evaluation
debit cards: the authorization process debits the third party payer's bank account immediately. Depending on the payment system, the first party payee may receive the funds at this time. Some payment systems require a separate settlement step to move funds to the first party payee.
bank account transfers: the authorization process is comprised of an optional online validation of the bank account using services offered by the payment system. This process invokes a service offered by some payment systems, typically in the United States. That service may include checking the existence of a bank account and comparing it to a list of known fraudulent account information. However, the process does not block funds, is not required, and the service is not offered by all payment systems.
Note: Except in the case of some debit card transactions, as noted above, authorization does not result in the transfer of funds into the deploying company’s bank account.
The diagram below shows the steps performed in the Authorize Transaction from Source Product Flow (F2).
Authorize Transaction from Source Product Flow
The information below describes the steps performed in the Authorize Transaction from Source Product Flow (F2).
The Authorize Transaction from Source Product Flow begins with the source product requesting authorization. This usually occurs when the transaction initiating the authorization has been confirmed. For example, in the case of Oracle Order Management, authorization is requested when the sales order is booked. Each source product requests authorizations from Oracle Payments in the appropriate point in its flow.
This process determines the payment system to which a transaction is sent. A payment system processes fund captures after establishing a business relationship with the deploying company. The payment system can be the same bank at which the deploying company has its bank accounts or it can be a third party processor that connects deploying companies and financial institutions. Credit card processing is typically handled by a third party processor. Deploying companies may use multiple payment systems, based on their payment processing needs. For example, a deploying company may use a third party processor for credit card processing, while sending bank account transfers directly to a financial institution.
For credit and debit cards, if you process an authorization through a payment system, you must do the settlement through the same payment system. For bank account transfers, however, you can process the authorization, or online bank account validation, through one payment system and process the settlement through another. All routing rules, whether for authorization or settlement, are applied in this step and the results are stored in the Transaction Authorization Entity table for later reference.
The Payment System Routing process also assigns a funds capture process profile to each transaction. The funds capture process profile is a key setup entity in Oracle Payments that contains information on processing transactions, including formatting and transmission.
The Authorize Transaction from Source Product Flow divides at this point. Oracle Payments determines which type of instrument is included in the authorization request and takes different actions depending on the instrument.
The following actions occur if the payment instrument is a credit card or debit card.
The Extract and Format Operation is a process that extracts data from Oracle Payments' tables and then uses Oracle XML Publisher to format the extracted data into a message that can be understood by the payment system. Oracle Payments then sends the formatted information to the payment system.
Once the data to transmit is formatted, Oracle Payments opens a connection with the payment system using transmission information specified in the funds capture process profile.
The payment system does the following:
validates the credit card or debit card sent for authorization
ensures that the credit card or debit card is active
may perform a fraud checking service
Once the payment system determines that the credit card or debit card is valid, it authorizes funds. For credit cards this action reserves the amount to be settled on the card. For debit cards, this action debits the third party payer's bank account and, depending on the payment system, may deposit the funds into the first party payer's bank account.
The following actions occur if the payment instrument is a bank account.
This is an optional process in the Authorize Transaction from Source Product Flow. Business practices or local laws sometimes require the first party payee to have written authorization for each third party payer allowing the payee to debit the payer's bank account. This is a system option in Oracle Payments. Part of the payer setup that Oracle Payments provides is a way for you to enter and store information about debit authorizations. This step checks the stored debit authorization information.
This process extracts data from Oracle Payments' tables and creates an XML message, which is then formatted by Oracle XML Publisher into a message that the payment system can understand.
This process and the following two processes are optional, based on the funds capture process profile setup. In some cases, the payment system does not support the functionality to validate bank accounts. In other cases, deploying companies may not want to use this feature, even if it is offered.
Once the data to transmit is formatted, Oracle Payments opens a connection with the payment system.
The payment system validates the bank account and performs an account verification check. Typically, it checks that the bank account number and the routing number are valid. It may also perform a fraud checking service.
The Authorize Transaction from Source Product Flow joins again at this point. Oracle Payments receives a response from the payment system and closes the connection. This response contains a variety of information, depending on the success or failure of the transaction.
This is an optional process that enables Oracle Payments to perform some evaluation for risk of fraud on the payment instrument. Note that Risk Evaluation is available only for credit card transactions. In some cases, this process requires input from the external payment system, such as address verification results.
Oracle Payments processes the response from the payment system. Part of this processing maps any errors returned by the payment system to errors that are meaningful to source product users. For example, each payment system may have a different error code to indicate that an instrument is invalid. Oracle Payments maps these different codes to one value that can be sent to the source product.
Information received from the payment system is stored in the Transaction Authorization Entity table owned by Oracle Payments. This is a table that stores the authorization information and creates a unique reference identifier for the transaction. The type of information stored here depends on the payment instrument. For example, a credit card that has a successful authorization has an authorization code, amount, and date in this table. The assigned funds capture process profile and payment system are also stored in this entity. This information is read during the settlement process.
Oracle Payments notifies the source product of the success or failure of the transaction authorization. This process also sends the unique reference identifier for the authorization to the source product.
The source product handles errors returned by Oracle Payments. For instance, the application may update a status on the transaction to indicate success or failure.
Finally, the source product stores the unique reference to the authorization.
The Settle Transaction from Oracle Receivables Flow is the third flow of the funds capture process flows. Settlements are received by Oracle Payments, stored, and later built into settlement batches for transmission to the payee.
The flow shown below applies when the payment system is a processor-model payment system. When the payment system used is a gateway, the process proceeds to the Settlement Batch Creation flow immediately and creates one message for each settlement passed from Oracle Receivables. With gateway payment systems, all operations in the Settle Transaction from Oracle Receivables Flow occur in real-time.
The Automatic Funds Capture Process in Oracle Receivables Flow represents a typical process flow for batch transactions, that is, settlement or credit transactions that must become part of a settlement batch. Part 1 of the flow shows what happens with funds capture process requests, that is, groups of settlements that are sent to Oracle Payments by Oracle Receivables. Part 2 shows the process to build the settlements into settlement batches and complete processing. These two parts do not occur at the same time, except in the case of gateway payment systems, as noted above. For example, multiple funds capture process requests can be sent to Oracle Payments throughout a day, and then settlement batches can be created later in the day at the close of business.
The diagram below shows the steps performed in the Settle Transaction from Oracle Receivables Flow (F3).
Settle Transaction from Oracle Receivables Flow
The information below describes the steps performed in the Settle Transaction from Oracle Receivables Flow (F3).
Oracle Receivables creates automatic receipts using the Automatic Funds Capture Process Flow and submits corresponding settlements in the form of funds capture process requests to Oracle Payments.
Once Oracle Receivables creates its receipts, it submits corresponding settlement requests to Oracle Payments in the form of a funds capture process request. This request includes the following:
information identifying the request
one or more settlements or credits
A funds capture process request originates from Oracle Receivables and contains settlements that need funds captured electronically. Oracle Payments receives the request and, after some validation, stores the information in its tables.
For each settlement, Oracle Payments reads the funds capture process profile and the payment system information. Oracle Payments uses this information in subsequent processing.
Oracle Payments validates all the settlements sent as part of the funds capture process request to ensure it has all the information required for payment processing. Oracle Payments then stores the settlements in the database. The status of the settlement validation and storage is returned to Oracle Receivables, depending on the outcome of the process. If a validation error occurs, Oracle Payments rejects the settlement and returns it to Oracle Receivables along with the reason for the error.
A settlement batch is the information compiled from settlements in one or more funds capture process requests that is formatted and transmitted to a payment system for settlement. Oracle Payments processes settlements from all submitted funds capture process requests and groups them according to their payment systems and other grouping rules to create settlement batches.
Oracle Payments extracts settlement batch data into an XML message. It then integrates with Oracle XML Publisher to format the XML message into an appropriate payment system format.
Some payment systems require the application of encryption or other security features to secure the settlement batch before it is transmitted to the payment system. This security operation takes place in this flow.
Once the settlement batch has been secured, it is transmitted to the payment system for processing and capture of funds.
At some time after the settlement batch is submitted, not necessarily immediately, the payment system may create an acknowledgement that the batch was received and/or processed. This process receives and processes those acknowledgements. A status is returned to Oracle Receivables at this point.
The Automatic Funds Capture Process in Oracle Receivables Flow represents the process that Oracle Receivables follows when using Oracle Payments for funds capture settlements. The diagram below shows the steps performed in the Automatic Funds Capture Process Flow (in Oracle Receivables).
Automatic Funds Capture Process Flow in Oracle Receivables
Oracle Receivables groups transactions into receipts. When the payment instrument is a credit or debit card, Oracle Receivables ensures that the originating invoice transaction amount with a unique authorization is created as one receipt. For credit or debit cards, one authorization results in one settlement. This ensures that the authorization information is valid during a settlement. For bank account transfers, however, different authorizations, that is, online bank account validations, can be combined into one settlement.
Oracle Receivables ensures that its receipts have valid authorizations before they are sent to Oracle Payments for settlement.
There is no precise way for Oracle Receivables to know if the authorization is completely valid. This cannot be determined until the actual settlement is made. When Oracle Payments sends a settlement to the payment system and it is rejected due to an expired authorization, Oracle Payments does not reject the request. Rather, Oracle Payments automatically re-sends the settlement for a new authorization and subsequent settlement. Oracle Payments only sends an authorization failure back to Oracle Receivables if the actual settlement fails.
Note: Oracle Payments does not automatically reauthorize settlements that are rejected due to expired authorizations.
Where a new authorization is successful, Oracle Payments updates the transaction authorization entity. Further, Oracle Payments updates the settlement with the new authorization information.
Oracle Receivables has the following statuses on its receipts: Confirmed, Remitted, and Cleared. The status set in this flow is Confirmed, which indicates that the receipt is created with its needed authorization.
If the receipt does not have an authorization, Oracle Receivables follows the authorization flow presented in the Authorize Transaction from Source Product Flow.
Once Oracle Receivables has received the authorization from Oracle Payments, it can update its receipt status to Confirmed.
Oracle Receivables submits settlements to Oracle Payments as a funds capture process request.
Copyright © 2000, 2010, Oracle and/or its affiliates. All rights reserved.