Funds Capture Process Flows

Overview

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 Collections
Oracle iReceivables
Oracle iStore
Oracle Lease Management
Oracle Order Capture
Oracle Order Management
Oracle Partner Management
Oracle Quoting
Oracle Service
Oracle Service Contracts
Oracle Receivables
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.

Funds Capture Flow Overview

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 picture is described in the document text

The following information describes the processes performed in the Funds Capture Flow:

Source Product Creates Transaction

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 Product Requests Authorization from Oracle Payments for Transaction

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.

Source Product Passes Transaction and Authorization Information to Oracle Receivables

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.

Oracle Receivables Initiates Settlement Process

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.

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

Create Transaction in Source Product Flow

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 picture is described in the document text

The information below describes the steps performed in the Create Transaction in Source Product Flow (F1).

Set Up Payer

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.

Capture Payer information

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.

Store Information in Payer Entity

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.

Create Transaction

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.

Select Payment Method

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.

Select Payment Instrument

The payment instrument is selected. The payment instrument is the means used for settling a payment. Examples of payment instruments include the following:

credit cards
debit cards
bank accounts

Payment instruments are entered the same way as payment methods.

Capture Payment Attributes

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.

Validate Transaction Payment Information

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.

Store information in Transaction Payment-Extension Entity Table

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.

Send Results Notification

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.

Perform Error-Handling

The source product resolves any errors returned by Oracle Payments. Each source product is responsible for its own error handling.

Store Reference to Extension Entity

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.

Using ISO20022 Direct Debit

This topic provides overview of ISO20022 Direct Debit.

Changes to Customer Payment Instruments

Following are the business rules for payment instruments assignments:

Debit Authorization field is removed from the existing Payment Instruments window of Bank Account Transfer region, accessed through Oracle Receivables
A new Debit Authorization region is added in the Bank Account Transfer region. It contains Create Debit Authorization at the header level when selected displays the information on mandates attached to a bank account.
The Create Debit Authorization will be active only when you select the option for the assigned bank account. This lets you create information of the new mandate.
The table in the Debit Authorization display debit authorization information in various columns.
Update column displays pencil icon in active mode against each mandate attached to a bank account.
Pressing update pencil icon for a mandate opens the Enter Debit Authorization window. It displays the selected mandate. The status of the mandate is determined based on the existing logic.
Priority displays priority of the mandate. You can increase or decrease the priority of a mandate.
Whenever a new mandate is created, it is created with priority 1. Subsequent mandates are created with incremental priorities.
For any bank account, active mandate with highest priority acts as the default mandate. If there are three mandates attached to a bank account and priority 1 mandate is inactive then priority 2 mandate becomes the default mandate, if it is active.
Three new attributes, Local Instruments, Service Level, and Purpose Code, are added in the Bank Account Transfer Attributes region. These fields display values from the new seeded lookup IBY_LOCAL_INSTRUMENT, IBY_SERVICE_LEVEL, and IBY_PURPOSE_CODE.
On the verification and settlement transactions, local instrument, service level and purpose code default from the site level payer. If the site level payer has null values, then these fields default from the account level payer. If Funds Capture Process Profile has these values configured, then values are taken from the FCPP.

Entering Debit Authorization

Following changes are made to Enter Debit Authorization window:

Payer name on the mandate comes from the customer context. The Payer name is default with the customer name. You can modify the value
Two new attributes, Frequency and Final Collection Date, are provided. These are mandatory attributes. The frequency represents intended frequency of the collection against a debit authorization whereas final collection date represents intended final collection date.

Changes to Funds Capture Process Profile

Following are business rules for new and modified behavior of Funds Capture Process Profile page:

Two new regions, Payment Logical Grouping and Payment Attributes, are added.
Payment Logical Grouping has the option, Batch Booking.
Payment Attributes has three options, Local Instrument, Service Level and Purpose Code. These three attributes retrieve values from seeded lookup IBY_LOCAL_INSTRUMENT, IBY_SERVICE_LEVEL and IBY_PURPOSE_CODE respectively.
Batch booking option is mapped to the related attribute in the ISO20022 message to indicate whether batch booking enabled or not
Local Instrument and Service level attributes are also present at the payer level, Funds Capture Process Profile, that override the payer setup. If you configure these attributes at the FCPP level, then the payer level setup is ignored.

Creating Transaction Payment Instrument

Following are the changes made to Payment Instruments window:

A new field, Debit Authorization, is added that is accessible from the Invoice Workbench in Oracle Payments and Receipt Workbench in Oracle Receivables.
Debit Authorization is available only when funds capture payment method is bank account transfer. It is active only when the bank account number field has value.
When the bank account is default on the invoice or is selected, the active mandate with highest priority assigned to that bank account is automatically default on the invoice. The list of value displays only active mandates.
On the receipt level, you cannot edit the Debit Authorization. Also, you cannot edit the Final Transaction for Debit Authorization at the receipt level.
For ISO20022 transactions, Receivables must enforce invoice-grouping rule as one per invoice. This is needed because different invoices of the same customer, for the same sales order, on the same day can use different mandates.

Changes to Debit Authorization Public APIs

Create Mandate API

This API creates a new mandate in iby_debit_authorizations. It returns debit authorization ID of the new mandate. Includes the following two new parameters:

Frequency: Intended frequency of the collection against a debit authorization
Final Collection Date: Intended final collection date Update or Amend

Mandate API

This API updates an existing mandate. It also handles amendment of the mandate. This API includes, Customer Name, which indicates the name of customer.

Check Debit Authorization Exist API

This API checks whether a mandate already exists in the system or not. The caller should pass the authorization reference number. If the mandate exists then debit authorization ID and external bank account assignment ID is returned along with active status. The parameter is, Authorization Reference Number with the value, Yes.

Debit Authorization API

This view retrieves the attributes of a debit authorization. This includes the Debit Authorization ID parameter.

Seeding the XML Publisher Format Templates and Mapping the attributes for ISO Direct Debit Initiations

Direct debit initiation message format is based on the ISO20022 framework. Before sending the message, it is ensured that the message is in the correct format. The XML Publisher Format Templates used for the ISO Direct Debit Initiation are seeded. You can reuse these templates.

Two new Direct Debit Initiation Templates, ISOCGI Direct Debit Initiation Template- Structured and ISOCGI Debit Initiation Template – Unstructured, are seeded. These templates create payment format.

Following are the guidelines for ISO CGI Direct Debit messages:

The required elements in the CGI are accepted by all CGI supporting banks. They define a standard set of data with agreed country or payment instrument qualifications.
Any data populated in a schema-defined optional field that is not required by an individual bank are ignored and do not stop processing of the message.
Where individual clients do not maintain a CGI-Required or Conditional element in their systems, they should consult with their banks on the minimum of data elements required for that type of transaction. This could result in the need to add those data elements into the client's systems. The general attributes are assigned in the CGI and are used in conjunction with the country or payment instrument rules produced for the CGI.

If a country or payment instrument has not been addressed, then the banks engaged by the client work to agree on a common addition to the CGI country or payment instrument rules.

Seeding new Formats for ISO Direct Debits

The Formats to be used for the ISO CGI Direct Debit Collection Initiation are seeded. There are two separate formats for structured and unstructured messages. These formats are seeded in Funds Capture Process Profiles, which in turn are used for ISO CGI direct debit transactions. Additionally, Payments also provides seeded format for Payer Verification process. Some of the validations, that are related to mandate attributes, are attached to this format. This ensures verification of active and correct mandate.

Seeding Funds Capture Process Profiles for ISO CGI Direct Debit

Two new Funds Capture Process Profiles are seeded in the Payments applications for ISO20022 CGI Direct Debit to support structured and unstructured remittance.

Authorize Transaction from Source Product Flow

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 picture is described in the document text

The information below describes the steps performed in the Authorize Transaction from Source Product Flow (F2).

Request Authorization

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.

Payment System Routing

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.

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

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.

Instrument = Credit Card, Debit Card, or Bank Account?

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.

Credit Card or Debit Card

The following actions occur if the payment instrument is a credit card or debit card.

Extract and Format Operation

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.

Open Connection with 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.

Validate Payment Instrument

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

Authorize Funds

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.

Bank Account

The following actions occur if the payment instrument is a bank account.

Verify Valid Debit Authorization Exists

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.

Extract and Format Operation

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.

Open Connection with Payment System

Once the data to transmit is formatted, Oracle Payments opens a connection with the payment system.

Validate Payment Instrument

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.

Receive Payment System Response

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.

Perform Instrument Risk Evaluation

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.

Process Response: Map Errors

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.

Store Information in Transaction Authorization Entity

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.

Send Results Notification

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.

Perform Error-Handling

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.

Store Reference to Authorization Entity

Finally, the source product stores the unique reference to the authorization.

Settle Transaction from Receivables Flow

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.

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

The following diagram shows the processes performed in the Settle Transaction from Oracle Receivables Flow (F3):

Settle Transaction from Oracle Receivables Flow

the picture is described in the document text

The information below describes the steps performed in the Settle Transaction from Oracle Receivables Flow (F3).

Automatic Funds Capture Process Flow

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.

Receive Funds Capture Process Request

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.

Read Funds Capture Process Profile and Payment System for each Settlement

For each settlement, Oracle Payments reads the funds capture process profile and the payment system information. Oracle Payments uses this information in subsequent processing.

Settlement Validation

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.

Settlement Batch Creation

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.

Extract and Format Operation

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.

Security Operation

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.

Transmission Operation

Once the settlement batch has been secured, it is transmitted to the payment system for processing and capture of funds.

Acknowledgement Process

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.

Automatic Funds Capture Process Flow in Oracle Receivables

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

the picture is described in the document text

Create Automatic Receipts

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.

Authorization on Receipt?

Oracle Receivables ensures that its receipts have valid authorizations before they are sent to Oracle Payments for settlement.

Oracle Payments: Authorization Expiration Handling

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.

(Yes) Update Receipt Status = Confirmed

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.

(No) Authorize Receipt

If the receipt does not have an authorization, Oracle Receivables follows the authorization flow presented in the Authorize Transaction from Source Product Flow.

Update Receipt Status = Confirmed

Once Oracle Receivables has received the authorization from Oracle Payments, it can update its receipt status to Confirmed.

Pass Receipts to Oracle Payments in Funds Capture Process Request

Oracle Receivables submits settlements to Oracle Payments as a funds capture process request.