3Manage Funds Capture

This chapter contains the following:

Oracle Fusion Payments processes authorization requests that are received from source products. An authorization is a real-time process that:

  • Validates credit card information

  • Reserves funds through the payment processor and issuing bank

Note: Credit card services are currently not available in Oracle Financials Cloud implementations.

Settings That Affect Authorizations for Credit Cards

The following table describes the options that affect authorization processing:

Page or Dialog Box User Interface Element Action

Create or Edit Funds Capture Process Profiles Page

Formats tab, Authorization section: Outbound Format choice list and Inbound Response Format choice list.

Accounts tab: Authorization Transmission Configuration choice list

Controls the formats and transmission configurations used to communicate with the payment system.

Create Routing Rules Page

All fields.

  • Routes funds capture transactions to a payment system

  • Determines the payment system account and the funds capture process profile to be used for authorization processing.

Reorder Priority of Routing Rules Dialog Box

All fields

Reorders priority of routing rules.

Set Rules Page

All fields

Specifies default payment systems that are used if no routing rules are set up or if none of the conditions in the routing rules are met for the funds capture transaction.

How Authorizations for Credit Cards are Processed

The following diagram illustrates the steps performed in the authorization process.

This diagram illustrates the steps performed in the authorization
process.

The authorization process for credit cards includes the steps described in the following table.

Step Description

Request authorization.

The source product requests authorization. Oracle Fusion Receivables creates an automatic receipt.

This process determines the payment system to which a transaction is sent, as well as the funds capture process profile.

Route transaction to payment system.

Routing rules are applied in the order of their priority. Payments performs settlements or refunds through the same payment system used for authorizations.

Perform extract and format operation.

This process:

  • Extracts data from Payments tables

  • Uses Oracle Business Intelligence Publisher (Oracle BI Publisher) to format the extracted data into a message that is understood by the payment system.

Open connection with payment system.

Payments:

  • Opens a connection with the payment system using transmission information specified in the funds capture process profile

  • Sends the formatted authorization request

Validate payment instrument.

The payment system or the issuing bank:

  • Validates the credit card

  • May perform a fraud checking service

  • Ensures that the credit card is active

Reserve funds.

After the issuing bank determines that the credit card is valid, it reserves funds.

Receive payment system response.

Payments receives a response from the payment system and closes the connection. The response contains a variety of information, depending on the success or failure of the transaction.

Update authorization status.

Authorization information received from the payment system is stored in the Transaction Authorization Entity table owned by Payments. This table creates a unique reference identifier for the transaction.

For example, a credit card that receives a successful authorization stores the following data in the table.

  • Authorization code

  • Amount

  • Date

  • Assigned funds capture process profile and payment system

The preceding information is used during the settlement process.

Send results notification.

Payments:

  • Notifies Receivables of the success or failure of the transaction authorization.

  • Sends the unique reference identifier for the authorization to the source product.

Perform error-handling.

Receivables displays any errors. You can resolve errors returned by Payments.

Store authorization reference.

The source product stores the unique authorization reference.

Oracle Fusion Receivables starts the settlement process, and Oracle Fusion Payments settles the transactions. Settlements received by Payments from Receivables are stored and later built into settlement batches for transmission to your processor or payment system. During the settlement process, captured funds are processed and deposited into the first party payee's bank account. First party payees are organizations within your company that receive payments from customers who pay with credit cards or bank account transfers.

Note: If you use a gateway payment system, individual settlements, rather than settlement batches, are submitted directly to your payment system.

Settings That Affect Settlement Batches

The following table lists the options that affect settlement batch processing.

Pages Tab Section User Interface Element

Create or Edit Funds Capture Process Profiles

Formats

Settlement

  • Outbound Format choice list

  • Inbound Response Format choice list

Create or Edit Funds Capture Process Profiles

Formats

Settlement Response Processing

  • Outbound Format choice list

  • Acknowledgment Parser choice list

Create or Edit Funds Capture Process Profiles

Creation Rules

Settlement Grouping Rules

All check boxes

Create or Edit Funds Capture Process Profiles

Creation Rules

Settlement Limit

  • Amount choice list

  • Conversion Rate Type choice list

  • Number of Settlements field

Create or Edit Funds Capture Process Profiles

Accounts

Settlement Transmission

  • Configuration choice list

  • Acknowledgment Transmission Configuration choice list

How Settlement Batches are Processed

Part 1 of the settlement process flow, as illustrated in the figure, includes the creation of a settlement transaction during the Receivables remittance process. This assumes that authorization was already performed.

Part 2, as illustrated in the figure, includes the grouping of individual settlements into batches and their submission to the payment system. Part 2 is separate from Part 1 and begins when the Create Settlement Batches process is manually run or scheduled.

Part 3, as illustrated in the figure, includes the receipt of the settlement batch acknowledgment. Part 3 is separate from Part 2 and begins when the Retrieve Settlement Batch process is manually run or scheduled.

This figure illustrates parts 1, 2, and 3 of the settlement
process flow for batch transactions.

The settlement process for processor payment systems includes the steps described in the following table.

Step Description

Remit receipts.

During receipt remittance, specifically during the approval of a remittance batch, Receivables submits corresponding settlements requests as a funds capture process request to Payments.

Receive funds capture process requests.

Funds capture process requests received by Payments include:

  • Information identifying the request

  • One or more settlements or credits

The funds capture process request contains settlements that need funds captured electronically.

Read funds capture process profile and payment system for each settlement.

For each settlement, Payments reads the funds capture process profile and the payment system information, as determined during the routing of the initial authorization transaction. Payments uses this information in subsequent processing.

Validate settlements.

  1. 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.

  2. Payments stores the settlements in the database. The initial status of the settlement validation and storage is returned to Receivables.

Group individual settlements into batches.

A settlement batch is settlement information from one or more funds capture process requests that's formatted and transmitted to a payment system for settlement.

Payments processes settlements from all submitted funds capture process requests and groups them by payment systems and other grouping rules to create settlement batches. Optional grouping rules are set in the funds capture process profile.

Extract and format settlement batch data.

  1. Payments extracts settlement batch data into an XML message.

  2. It integrates with Oracle Business Intelligence Publisher (Oracle BI Publisher) to format the XML message into a payment system format, as specified in the profile.

Transmit settlement batch to payment system.

After the settlement batch is formatted, it's transmitted to the payment system for processing and capture of funds as specified in the profile

Retrieve acknowledgments.

  1. The payment system may create an acknowledgment that the batch was received or processed.

  2. Payments retrieves the acknowledgment file. This step and the subsequent step are optional and depend on the level of service that's provided by your payment system.

Process status and update settlements.

Payments reads the acknowledgment file and updates the statuses of the applicable settlements. Receivables doesn't update receipt status based on this information, but restricts follow-on transactions, such as refunds.

Settlement grouping is configured by selecting one or more check boxes in the Settlement Grouping Rules section on the Create Funds Capture Process Profile page. Selection of settlement grouping attributes specifies that settlements with the same attribute are included in a unique settlement batch when that profile is used. The following scenarios illustrate how settlement grouping rule options are used to group settlements into settlement batches using a specific funds capture process profile.

Funds Capture Process Profile 1

In this example, Funds Capture Process Profile 1 has the following settlement grouping options selected:

  • Business unit

  • First-party legal entity

  • Settlement date

Create Settlement Batches

During funds capture transaction processing, the Create Settlement Batches program selects the settlements listed in the following table.

Settlement Amount External Payer Business Unit that Owns the Transaction First-Party Legal Entity that Owns the Transaction Settlement Date

A

1000 USD

Customer 1

California

North America

February 1, 2012

B

250 USD

Customer 2

California

North America

February 1, 2012

C

500 USD

Customer 3

Oregon

North America

February 1, 2012

D

750 USD

Customer 4

California

North America

March 1, 2012

The Create Settlement Batches program then groups the settlements into the following settlement batches:

Settlement Batch 1

Settlement Batch 1 contains Settlements A and B because both settlements have the same settlement grouping attributes as follows:

  • Business unit = California

  • First-Party legal entity = North America

  • Settlement date = February 1, 2012

Settlement Batch 2

Settlement Batch 2 contains Settlement C because it has the following settlement grouping attributes:

  • Business Unit = Oregon

  • First-Party legal entity = North America

  • Settlement date = February 1, 2012

Settlement Batch 3

Settlement Batch 3 contains Settlement D because it has the following settlement grouping attributes:

  • Business Unit = California

  • First-Party legal entity = North America

  • Settlement date = March 1, 2012

A settlement is a funds capture transaction that moves funds from the cardholder account or the bank account owner into the internal payee's account. Internal payees are your company's business units that receive payments from payers, such as customers, by credit card payments or direct debits to bank accounts. A settlement batch is a group of settlements and credits that are sent to the payment system together in a file. Settlement batches are generally used with processor payment systems, which interact with banks and card institutions, such as Visa and MasterCard to process financial transactions.

Note: Credit card services are currently not available in Oracle Financials Cloud implementations.

If your company has multiple divisions, each division is represented by a separate payment system account. A payment system account contains a relationship-specific value for each of the attributes required by the payment system. For example, your payment system may require a Submitter ID and Submitter Password to be included in any message sent to it. Each attribute is represented by a setting on the payment system account.

Settings That Affect Settlement Transaction Files

The values for the following payment system account settings on the Edit Payment System Accounts page affect the merger of settlement files into one batch:

  • Presenter's ID

  • Submitter's ID

If the values for the preceding payment system account settings are the same, settlement transactions are grouped into one settlement batch. This occurs even when the following payment system account settings have different values:

  • Division Number

  • Merchant Name

How Settlement Transaction Files Are Merged into One Settlement Batch

Processor payment systems accepts a daily limit of settlement batch files from deploying companies. Large companies may generate a large number of daily settlement batch files that exceed the payment system's limit. To counteract this constraint, Oracle Fusion Payments enables you to merge settlement transactions of different payment system accounts into a single settlement batch file.

Typically, separate settlement batch files are created for each payment system account. Whether you generate settlement batches manually from the Oracle Enterprise Scheduler submission page or automatically, they are based on a unique combination of the following:

  • Internal payee

  • Funds capture process profile

  • Payment system account

Oracle Payments provides the following funds capture predefined reports:

  • Funds Capture Accompanying Letter Formats

  • Funds Capture Authorization and Settlement Formats

  • Funds Capture Payer Notification Formats

All of the preceding reports are:

  • Processes that result in a formatted file

  • Formatted using a specific template

  • Manually generated, if opted, using the Scheduled Processes page

  • Automatically generated, if opted, using setup pages

Running Funds Capture Reports Manually

To manually run Payments reports, perform the following steps from the Scheduled Processes page using the Navigator menu.

  1. Click the Schedule New Process button.

  2. Search on the Process Name.

  3. Enter the applicable parameters.

  4. Enter the applicable process options and schedule.

  5. Click the Submit button.

Running Funds Capture Reports Automatically

The following table lists funds capture reports with their corresponding processes that automatically run after you select specific options on the applicable page.

Note: The applicable process is called internally. Any required parameter values are known by Payments without your intervention.
Name of Report and Process Report Description Options You Select for the Automatic Process Output

Report: Funds Capture Authorization and Settlement Formats

Process: Create Settlement Batches

Formats authorizations, settlements, and settlement batches, groups settlements into batches, and submits them to payment systems.

Automatically runs.

Settlement batches.

Report: Funds Capture Payer Notification Formats

Process: Send Receipt of Payment Notifications

Creates payment notifications that can be faxed, E-Mailed, or printed and mailed to external payers after the settlement or settlement batch is transmitted to inform them of a funds capture transaction that will charge their credit card or bank account.

Location: Create Funds Capture Process Profile page, Formats tab, Payer Notification section.

Option to select: Automatically submit at settlement check box.

Document.

Report: Funds Capture Accompanying Letter Formats

Process: Settlement Batch Accompanying Letter

Creates an accompanying letter for a direct debit settlement batch file that your company either prints and mails to the bank, or manually transmits to the bank, along with the settlement batch file.

Location: Create Funds Capture Process Profile page, Formats tab, Settlement section.

Option to select: Accompanying Letter Format check box.

Document.

ISO 20022 Direct Debit Prenotifications

An ISO 20022 direct debit prenotification is a written or electronic letter using the required ISO 20022 message standard for SEPA countries. A prenotification must be sent to your customer five days in advance of collection. The prenotification informs customers of each upcoming direct debit from their accounts. You must notify your customer of the amount and date of a planned ISO 20022 direct debit collection before you send instructions to your bank with the relevant ISO 20022 debit authorization attached.

The prenotification provides advance warning to your customers and ensures that funds are available for collection. The prenotification also allows your customer to reject a collection, if necessary, before settlement.

This topic discusses the following aspects of prenotifications:

  • ISO 20022 format

  • Generation

  • Validation

  • Delivery

ISO 20022 Format

Per ISO 20022 payment standards, the ISO 20022 direct debit prenotification letter must include the following information:

  • Debit authorization reference identifier

  • Debtor's bank account number

  • Debtor's bank

  • Direct debit currency must be euro only

  • Direct debit amount

  • Direct debit date

Generation

Before you can generate prenotifications, an active debit authorization must exist between you and your customer.

During receipt method setup, Receivables provides an option for users to specify whether transactions are ISO 20022. When an automatic receipt batch is created for ISO 20022 transactions, prenotifications are automatically generated by the Automatic Receipts Format Report.

Note: Before creating receipts, the Receivables user must know that they are for ISO 20022 transactions and that he or she must subsequently download prenotifications for delivery to customers. Receivables doesn't notify Payments when it generates prenotifications.

The following table describes the steps that the Receivables user can perform to submit the Automatic Receipts Format Report.

Scenario Step Description Result

Generate prenotifications while creating automatic receipts.

1. Navigate to the Create Automatic Receipt Batch page or to the Create Automatic Receipt Batch process in Oracle Enterprise Scheduler.

2. Enter all required attributes.

3. Select the Create, Approve, and Format options and submit the process.

Automatic receipt batch is created, approved, and formatted to generate prenotification letters.

Generate prenotifications while approving automatic receipts.

1. Navigate to the Receivables Balances work area.

2. Open an automatic receipt batch that is pending approval.

3. Select the Approve and Format action.

Automatic receipt batch is approved and formatted to generate prenotification letters.

Generate prenotifications while confirming automatic receipts.

1. Navigate to the Receivables Balances work area.

2. Open an automatic receipt batch that is pending confirmation.

3. Select the Format action.

Automatic receipt batch is formatted to generate prenotification letters.

Validation

Prenotifications don't undergo any validations.

Delivery

After generation, prenotifications are not automatically delivered to customers. Instead, they are manually downloaded and then delivered to customers by E-Mail or through a country's postal system.

Prenotifications are delivered according to the following guidelines for SEPA settlement batches:

  • A prenotification notifies the debtor at least five calendar days before collecting the payment, unless a different time line has been agreed between you and the debtor.

  • The lead time for submitting a SEPA CORE direct debit file (payment instrument governed by the rules of the SEPA Core Direct Debit Scheme) to a bank is five days for the first use of a debit authorization and two days for subsequent use.

  • The lead time for submitting a SEPA B2B (SEPA Business to Business) direct debit file to a bank for business debtors is one day for the first use of a debit authorization and one day for subsequent use.

Note: Receivables doesn't notify Payments when it delivers prenotifications.

You and your customer may agree to a frequency of prenotification delivery. For example, with a recurrent SEPA direct debit, you can agree to send a prenotification once a year. This can only be done, however, if the amount to be collected stays the same. Otherwise, a new prenotification must be sent to your customer.

ISO 20022 Payment Status Reports

An ISO 20022 payment status report, also known as an ISO 20022 direct debit acknowledgment, is an electronic message format that is based on the ISO 20022 message format called CustomerPaymentStatusReport (pain.002.001.03). The payment status report is sent by your bank or payment system to Oracle Fusion Payments. This inbound acknowledgment notifies you of the processing status of the ISO 20022 direct debit settlement batch transaction that you sent to your bank or payment system. Each settlement transaction is accepted or rejected.

The payment status report conveys the processing status, either directly or by inference, of every ISO 20022 direct debit settlement received by your bank or payment system. The payment status message format allows banks to specify an overall status for the direct debit settlement batch and individual statuses for some or all of the transactions. For example, it's possible for a direct debit settlement batch of five transactions to have an overall status of ACCEPT, while two individual transactions in the payment file have statuses of REJECT. In this case, the two transactions in the acknowledgment file failed, but by inference the other three batch transactions that were not in the acknowledgment file are inferred to have a status of ACCEPT.

Banks and payments systems use the payment status report to specify the following processing statuses:

  • Positive: Received, Accepted, or Accepted with Change

  • Pending

  • Negative: Rejected

  • Positive and negative: Partially Accepted

The use of the payment status report is always governed by a bilateral agreement between your company and the bank. A bilateral agreement specifies how your company wants to receive acknowledgments from the bank, whether:

  • Your company wants only one acknowledgment at any milestone.

  • Your company wants to receive acknowledgments at each milestone within the clearing process, such as the bank receiving the payment file, passing technical validations, passing business validations, and accepting or rejecting transactions.

A bilateral agreement can also specify whether your company wants to receive:

  • An acknowledgment for accepted transactions only

  • An acknowledgment for rejected transactions only

  • An acknowledgment that has details of both accepted and rejected transactions

Payments processes the payment status report message according to the message structure specified in ISO 20022 payments message standards for the CustomerPaymentStatusReportV03 (pain.002.001.03).

The following aspects of payment status reports are discussed in this topic:

  • Accepted status

  • Rejected status

  • Rejection and refund transactions

  • ISO 20022 direct debt transaction flow

  • Mapping of ISO 20022 reason codes to payment status and error codes

Accepted Status

Per ISO 20022 guidelines, group status represents the settlement file status. Several group statuses are provided that represent success. If you receive the payment status report message with the group statuses of ACCP, ACSP, or ACWC, the batch status and the transaction status of all the transactions within the batch are updated as Accepted.

Payments supports the following success statuses at the transaction level of the payment status report:

  • ACCP: Accepted with technical validation

  • ACSP: Accepted by the clearing system

  • ACWC: Accepted with a change

Rejected Status

The group status of RJCT applies to the batch. If you receive the payment status report message with the group status of RJCT, the batch status and the transaction status of all the transactions within this batch are updated as Rejected.

Payments supports the following failure status at the transaction level of the payment status report: RJCT: Rejected

Rejection and Refund Transactions

ISO 20022 direct debit collections that are diverted from normal execution before interbank settlement are known as rejection transactions. Rejection transactions and their associated rejection reasons appear in the payment status report. Payments supports the following rejection and refund transactions:

  • Invalid format of the ISO 20022 direct debit collection message

  • Incorrect IBAN check digit

  • Closed account

  • Deceased customer

  • Nonacceptance of direct debits by customer account

  • Claim by your customer for reimbursement of a direct debit to its account

ISO 20022 Direct Debit Transaction Flow

The following table describes the point where the payment status report appears in the flow of ISO 2022 direct debit transactions between Oracle Receivables, Payments, and Oracle General Ledger.

Step Receivables Payments General Ledger

1

Receivables creates a batch of ISO 20022 direct debit receipts.

N/A

N/A

2

Using the Auto-Remittance Batch process, Receivables submits the ISO 20022 direct debit receipts to Payments for processing.

N/A

N/A

3

N/A

Payments creates a settlement batch using an ISO 20022 SEPA or CGI settlement format and transmits the ISO 20022 direct debit collection message to your bank or payment system.

N/A

4

N/A

Your bank or payment system acknowledges receipt of the ISO 20022 direct debit settlement batch by sending you a payment status report, which is formatted as an XML message and follows the Customer Payment Status Report (pain.002.001.03) format.

N/A

5

N/A

To retrieve acknowledgments from your bank or payment system, you can schedule and run, typically once a day, the Retrieve Funds Capture acknowledgment process, which is a link in the Tasks pane of the Funds Capture work area, Overview page.

N/A

6

N/A

You can view the results of the Funds Capture Acknowledgment process in the Funds Capture Processes section of the Funds Capture work area, Overview page by clicking View Output.

If View Output indicates Successful, the ISO20022 direct debit settlement or settlement batch transaction was accepted by your bank or payment system and the payment processing status is reflected in the Status column in the Search Results section on the Manage Settlements or Manage Settlement Batches page.

If View Output indicates Rejected, the ISO20022 direct debit settlement or settlement batch transaction was rejected by your bank or payment system and the payment processing status is reflected in the Status column in the Search Results section on the Manage Settlements or Manage Settlement Batches page.

Payments notifies Receivables of the accepted or rejected ISO 20022 direct debit transactions.

N/A

7

Receivables updates the status of its receipts according to the payment status information it receives from Payments.

If the ISO 20022 direct debit transactions are rejected, the receipt amounts are unapplied and register as funds outstanding.

N/A

If the ISO 20022 direct debit transactions are accepted, the funds are accounted for in Oracle Fusion General Ledger.

Mapping of ISO 20022 Reason Codes to Payments Status and Error Codes

When you receive an acknowledgment file from your bank or payment system, it can have accepted or rejected transactions. The batch status, therefore, can be accepted, rejected, or partially accepted.

The rejection reasons that can appear in an acknowledgment file correspond to Payments status and error codes on the following levels:

  • Batch level mapping

  • Transaction level mapping

Batch Level Mapping

The following table lists the ISO 20022 batch level rejection code that can appear in an acknowledgment file that is received from your bank or payment system, along with the corresponding Payments status code.

ISO Reason Code ISO Reason Code Name SEPA Reason IBY Batch Status (IBY_BATCHES_ALL.STATUS) IBY Status (IBY_TRXN_SUMMARIES_ALL.STATUS)

FF01

InvalidFileFormat

Operation/Transaction code incorrect, invalid file format

Usage: To be used to indicate an invalid file format

1 (Transmission Error)

101 (Batch Transmission Error)

Transaction Level Mapping

The following table lists the ISO 20022 transaction level rejection codes that can appear in an acknowledgment file that is received from your bank or payment system, along with the corresponding Payments status codes.

ISO Reason Code ISO Reason Code Name SEPA Reason IBY Status (IBY_TRXN_SUMMARIES_ALL. STATUS)

AC01

IncorrectAccountNumber

Account identifier incorrect (invalid IBAN)

5 (Payment System Error)

AC04

ClosedAccountNumber

Account closed

19 (Invalid Bank Account)

AC06

BlockedAccount

Account blocked

Account blocked for Direct Debit by the Debtor

5 (Payment System Error)

AG01

TransactionForbidden

Direct debit forbidden on this account for regulatory reasons

5 (Payment System Error)

AG02

InvalidBankOperationCode

Operation/Transaction code incorrect, invalid file format

Usage: To be used to indicate an incorrect operation/transaction code

5 (Payment System Error)

AM04

InsufficientFunds

Insufficient funds

17 (Insufficient Funds)

AM05

Duplication

Duplicate collection

Ignore. The original transactions should be acknowledged correctly.

BE01

InconsistentWithEndCustomer

Debtor's name does not match with the account holder's name.

5 (Payment System Error)

FF01

InvalidFileFormat

Operation/Transaction code incorrect, invalid file format

Usage: To be used to indicate an invalid file format

5 (Payment System Error)

MD01

NoMandate

No Mandate

5 (Payment System Error)

MD02

MissingMandatoryInformationInMandate

Mandate data missing or incorrect

5 (Payment System Error)

MD07

EndCustomerDeceased

Debtor deceased

5 (Payment System Error)

MS02

NotSpecifiedReasonCustomerGenerated

Refusal by the Debtor

5 (Payment System Error)

MS03

NotSpecifiedReasonAgentGenerated

Reason not specified

5 (Payment System Error)

RC01

BankIdentifierIncorrect

Bank identifier incorrect (invalid BIC)

5 (Payment System Error)

RR01

MissingDebtorAccountOrIdentification

Regulatory reason

5 (Payment System Error)

RR02

MissingDebtorNameOrAddress

Regulatory reason

5 (Payment System Error)

RR03

MissingCreditorNameOrAddress

Regulatory reason

5 (Payment System Error)

RR04

RegulatoryReason

Regulatory reason

5 (Payment System Error)

SL01

DueToSpecificServiceOfferedByDebtorAgent

Specific Service offered by the Debtor Bank

5 (Payment System Error)

Note: The reason codes are stored in IBY_TRXN_SUMMARIES_ALL.BEPCODE table.

SEPA (Single Euro Payment Area) is a system that provides a standardized process for credit transfers, an improved debit system, and a cheaper way for individuals and firms to make transactions within European member countries or regions. The SEPA direct debit message format, which is based on ISO 20022 message guidelines, supports logical grouping of transactions within a settlement batch. A logical grouping refers to the number of settlement batches and transactions that are allowed in a transmission file. A settlement batch is a group of transactions, typically credit card settlements or credits, which are grouped, formatted, and transmitted to a payment system together in a file. Settlement batches are generally processed by a processor-model payment system.

For the SEPA direct debit message format, Oracle Fusion Payments supports the following three-level XML message structure:

  • Level 1: Group header

  • Level 2: Payment information

  • Level 3: Direct debit transaction information

The following logical groupings are allowed in each transmission file:

  • Mixed Grouping: Each file contains several settlement batches. Each settlement batch contains several transactions.

    A group is created with the least common attributes. For example, if there are three transactions with the same debtor but different mandates sequence types, such as first, recurring, or one-off, then Payments creates three separate groups. However, if two of the transactions have same mandate sequence type, then two groups are created.

  • Grouped: Each file contains only one settlement batch. The settlement batch contains several transactions.

  • Single: Each file contains several settlement batches. Each settlement batch contains only one transaction.

Note: Payments only supports mixed grouping per the SEPA requirements.

Level 1 - Group Header

The group header level of the SEPA direct debit message format contains settlement batch information that maps to a row in the IBY_BATCHES_ALL table. The group header is mandatory and repetitive. Repetitive means that one or more blocks of group header information can be included in a SEPA direct debit message format file.

The group header contains elements such as the following:

  • Message identification

  • Creation date and time

  • Number of transactions

  • Control sum

  • Initiating party

Level 2 - Payment Information

Payment information is the middle level of the SEPA direct debit message format. It contains attributes common to a group of transactions. Transactions are grouped at the payment information level only if selected in the funds capture process profile. Otherwise, the payment information level doesn't exist in the SEPA direct debit message.

The payment information level is mandatory and repetitive. Repetitive means that one or more blocks of payment information can be included in a SEPA direct debit message format file. The payment information level contains elements related to the credit side of the transaction, such as the following:

  • Payment method

  • Number of transactions

  • Group identifier

  • Creditor legal entity

  • Creditor business unit

  • Creditor's bank account details

  • Internal bank account

  • Currency

  • Charge bearer

  • Creditor identification number

  • Settlement date

  • Sequence type

  • Service level

  • Local instrument

  • Category purpose

  • Charge bearer

  • Collection date

  • Creditor details

Note: The preceding elements always appear in the SEPA direct debit message format.

Both SEPA and CGI (Common Global Implementation) are initiatives that promote wider acceptance of ISO20022 as the common XML payments standard used between businesses and banks. They can differ, however, in element definition, depending on whether or not a debit authorization is used.

The following table describes differences between the SEPA and CGI direct debit messages as they relate to the definition of certain message elements, which is determined by the existence or nonexistence of a debit authorization.

Element SEPA and CGI Direct Debit Messages with a Debit Authorization CGI Direct Debit Messages without a Debit Authorization

Creditor

Creditor (First Party Legal Entity) per the debit authorization.

Creditor (First Party Legal Entity) related to remittance bank account used on the invoice.

Ultimate Creditor

Creditor (First Party Legal Entity) per the invoice if different than debit authorization.

Creditor (First Party Legal Entity) per the invoice.

When you select payment grouping on the Create Funds Capture Process Profile page, the transactions are grouped within the settlement batch based on the values of the selected parameters. The logical grouping elements, however, are either all enabled or all disabled, depending on whether or not you select the Enable grouping option in the Payment Grouping Rules section on the Create Funds Capture Process Profile page. The logical grouping elements are the same for SEPA, as well as for CGI.

Level 3 - Direct Debit Transaction Information

Direct debit transaction information is the level of the SEPA direct debit message format that contains an individual transaction for each settlement batch. Each individual transaction maps to a row in the IBY_TRXN_SUMMARIES_ALL table. The direct debit transaction information level is mandatory and repetitive. Repetitive means that one or more blocks of direct debit transaction information can be included in a SEPA direct debit message format file.

The direct debit transaction information level contains elements such as the following:

  • Payment identifier details

  • Payment amount

  • Debit authorization details

  • Ultimate creditor

  • Debtor

  • Debtor's bank account

  • Purpose code

  • Remittance information

Note: Some of the preceding elements appear conditionally in the SEPA direct debit message format.

The batch booking option on the Create Funds Capture Process Profile page determines whether the batch booking element is set in the SEPA direct debit message. If you select the batch booking option, it applies to all transaction groups of the payment file.

Validations for ISO 20022 SEPA and CGI Direct Debit Settlement Messages

Oracle Fusion Payments provides two BI Publisher templates and two corresponding settlement formats for the Single Euro Payments Area (SEPA) and Common Global Implementation (CGI) versions of ISO 20022 direct debit settlement messages. Payments attaches validations to the ISO 20022 settlement formats for SEPA and CGI to verify that required data is present in the settlement message formats.

The following table describes the validations that are attached to the ISO 20022 SEPA and CGI settlement formats by Payments.

20022 SEPA and CGI Settlement Formats Supported by Payments

Validation Description Single Euro Payments Areas Core Direct Debit 5.0 (pain.008.001.02) ISO20022 Direct Debit Common Global Implementation 2.0 (pain.008.001.02)

Debit authorization presence:

  • Debit authorization must be present on the transaction.

Note: For SEPA transactions, the debit authorization is required, but for CGI it's not required.

Yes

No

Active debit authorization:

  • Verifies that the direct debit authorization is active and that the transaction date is greater than the debit authorization signing date and less than the debit authorization cancellation date.

  • Ensures that a one-off debit authorization is never used more than once.

Yes

Yes

Verifies that the following required fields are present on a debit authorization:

  • Authorization Reference Identifier

  • Authorization Signing Date

  • Creditor Legal Entity

  • Creditor Identifier

Yes

Yes

Verifies the following data:

  • Internal bank branch country exists.

  • Customer's bank branch country exists.

Yes

Yes

Payments supports the following additional SEPA validations:

  • Verifies that the Customer Bank Account IBAN is not null.

  • Verifies that the Customer Bank Branch BIC is not null.

  • Verifies that the Internal Bank Account IBAN is not null.

  • Verifies that the Internal Bank Branch BIC is not null.

  • Verifies that internal bank branch country exists.

  • Verifies that customer's bank branch country exists.

  • Verifies that the settlement currency is euro.

  • Verifies that the customer bank account is in the SEPA zone.

  • Verifies that the Creditor Identifier structure is as follows:

    • Position 1-2 filled with the ISO country code.

    • Position 3-4 filled with the check digit according to ISO 7064 Mod 97-10.

    • Position 5-7 filled with the Creditor Business Code. If not used, then filled with ZZZ.

    • Position 8 onward is filled with the country-specific part of the identifier as a national identifier of the Creditor, as defined by the National Community.

Yes

No

Payments supports the following additional CGI validations:

  • Verifies that either the Customer Bank Branch BIC or the Customer Bank Branch Number is not null.

  • Verifies that either the Internal Bank Branch BIC or the Internal Bank Branch Number is not null.

No

Yes

Verifies the following data that is required for the ISO 20022 direct debit format:

  • Local Instrument is not null.

  • Service Level is not null.

Yes

Yes

Match payment system account attributes:

  • If the transaction has no payee legal entity name, then validate the payment system account setting ISO20022_IP_NAME.

  • If the transaction has no payee legal entity registration number, then validate either ISO20022_IP_BICORBEI or ISO20022_IP_OTHERID payment system account settings.

Yes

Yes

Set Up a Customer Bank Account

If you want to receive payments from your customers by EFT from their bank accounts, you can set up customer bank accounts.

To set up a customer bank account, perform the following steps:

  • Find your existing customer.

  • Create a customer bank account.

  • Provide additional customer bank account information.

  • Optionally, add joint bank account owners.

  • Optionally, specify intermediary accounts

Finding Your Existing Customer

Navigator > Receivables > Billing link > Overview page > Tasks pane > Customers section > Manage Customers link > Manage Customers page.

  1. In the Search section, enter your customer's name in the Organization Name field or your customer's account number in the Account Number field and click Search. Your customer's details appear in the Search Results section.

  2. In the Search Results section, select the row that shows your customer's organization name.

Creating a Customer Bank Account

Determine whether you want to create a customer bank account at the customer level or at the customer site level.

To create a customer bank account, perform the following steps:

  1. To create a customer bank account at the:

    • Customer level, go to step 2.

    • Customer site level, go to step 3.

  2. Click the customer Account Number link in the Account Number column in the Customer Name: Accounts section.

    The Edit Account: Customer Name page appears. Go to Step 4 and continue.

  3. Click the applicable Site Number link in the Site Number column in the Customer Name: Sites section.

    The Edit Site: Customer Name page appears.

  4. Select the Payment Details tab.

  5. Select the Bank Accounts subtab.

  6. Click Create.

    The Create Bank Account page appears.

  7. From the Country choice list, select the country in which the customer bank account resides. Validation of the bank account is based on the country for which you create the bank account.

    If the country of the customer bank account and the country of the bank account's branch through which the payment is made is the same, then the payment is considered a domestic payment.

    If the country of the customer bank account and the country of the bank account's branch through which the payment is made is not the same, then the payment is considered an international payment.

  8. In the Account Number field, enter the bank account number.

  9. From the Bank Name choice list, select the bank at which the customer bank account resides.

  10. From the Branch choice list, select the branch where the bank account resides.

    You can create a customer bank account for receiving domestic payments by check without specifying a bank or branch. To receive electronic international payments, however, you must specify both a bank and a branch.

  11. To receive international payments from a customer bank account, select Allow international payments.

    Tip: Allow international payments can be selected only when you provide the name of the bank and the branch.
  12. Enter the IBAN (International Bank Account Number) in the IBAN field if you are setting up a customer bank account in a European country.

    Note: Validation of the IBAN is based on the country for which the customer bank account is set up.
  13. From the Currency choice list, select the currency in which payments are received.

    If you select a currency, then the customer bank account is used to pay invoices in that currency only. If you don't select a currency, then the customer bank account is considered multicurrency and is used to pay invoices in any currency.

Providing Additional Customer Bank Account Information

To enter additional information regarding the customer bank account you are creating, perform the following steps on the Create Bank Account page in the Additional Information section.

  1. In the Account Suffix field, enter the value that appears at the end of the bank account number, if applicable.

    Note: An account suffix is required in some countries.
  2. From the Conversion Rate Agreement Type choice list, select the type of conversion rate agreement you have with the customer.

  3. In the Conversion Rate field, enter the conversion rate for which one currency can be exchanged for another.

  4. In the Conversion Rate Agreement Number field, enter the number of the conversion rate agreement with the customer that specifies the currency in which payments are made.

  5. In the Check Digits field, enter one or multiple digits.

    Note: Only a few countries require check digits.
  6. In the Secondary Account Reference field, you can optionally enter additional account information.

  7. In the Agency Location Code field, enter the eight-digit value that identifies a Federal agency as the customer.

Optionally, Adding Joint Bank Account Owners

To optionally add other customers to the customer bank account as joint bank account owners, perform the following steps on the Create Bank Account page in the Account Owners section.

  1. In the Account Owner field, select a joint bank account owner from the list.

  2. In the From Date field, select a starting date for the joint bank account owner.

    If the customer wants to share the bank account with another party, then there are multiple owners of the bank account. For multiple bank account ownership, you must specify one owner as the primary owner. The primary owner is the customer for whom you are creating the bank account.

    A joint bank account scenario, for example, might be where two business units of the same company are conducting business in a foreign country and they want to use a common bank account for receiving and making payments.

  3. To specify the primary bank account owner among multiple owners, click the green check mark and then click the Primary field in the applicable account owner row.

    The check mark appears in the row you selected.

  4. To add a row from which to select another joint bank account owner, click the green plus.

Optionally, Specifying Intermediary Accounts

You can specify intermediary bank accounts for this customer on the Create Bank Account page in the Intermediary Accounts section. Intermediary bank accounts are used if there are restrictions on the transfer of funds between two countries. You can specify an intermediary bank account to assist in the transfer of funds between the originator's bank and the beneficiary's bank.

How You Update Bank, Branch, and Bank Account Numbers on External Bank Accounts

You can now edit the bank account number of external bank accounts in these modules:

  • Suppliers

  • Customers

  • Expenses

  • Payroll

  • Bill Management

  • Higher Education

  • Human Capital Management

On the simplified bank account page, you can also update the bank and branch if you created the bank account with the Oracle Cash Management profile option named Use Existing Banks and Branches set to Yes. When you update the bank and branch, you must select the same profile option.

How You Create and Edit a SEPA Debit Authorization

A SEPA debit authorization is a paper or electronic document that authorizes you, as a SEPA-based creditor, or payee, to collect payments throughout the SEPA region by debiting your SEPA-based customer's, payer's or debtor's, bank account. As the creditor, you or your bank, as agreed to by you and your customer, initiate the collection of funds from your customer's account. In turn, your customer instructs its bank to transfer funds directly to your bank.

Note: Both you and your customer must hold bank accounts within the SEPA region.

To initiate collection, SEPA countries require banks to use the ISO 20022 XML message standards, known as SEPA data formats, which are legally binding between banks. Similarly, Oracle recommends that you use the SEPA formats for initiating payments. Banks can, however, continue to accept other formats from their customers for the initiation of SEPA payments.

In the Create or Edit Debit Authorization dialog box, you can perform the following tasks:

  • Enter or edit debtor details

  • Enter or edit creditor details

  • Enter or edit authorization details

  • View history

Navigation to the Create Debit Authorization dialog box: Receivables > Billing > Manage Customers link > Manage Customers page > Search on Bank Account Number > Site link > Bank Account tab > Payment Instruments section.

Enter or Edit Debtor Details

SEPA debit authorizations require both you and your customer to specify the following identifiers for your bank accounts and bank:

  • IBAN (International Bank Account Number): An alphanumeric sequence that conforms to the ISO 20022 standard for uniquely identifying an international bank account number. It contains the routing information required to transfer a payment from one bank to another.

  • BIC (Bank Identifier Code): A universal method of identifying financial institutions to facilitate the automated processing of telecommunication messages in banking and related financial environments.

For SEPA direct debits, all transactions are in euro. If your accounts or those of your customer are in any other currency, the funds for the SEPA direct debits must be converted to euro.

Enter or Edit Creditor Details

You must provide your unique creditor identification number in the XML message for SEPA direct debits and when you create or edit a debit authorization.

The creditor identification number:

  • Is issued by your bank

  • Identifies you as the creditor on the paper SEPA debit authorization

  • Remains constant

  • Proves that you can initiate a SEPA direct debit

  • Varies in length between countries

  • Contains a maximum of 35 characters

The creditor identification number remains the same over time to enable your customer and his bank to return to you for refunds, complaints, or to confirm the existence of a SEPA debit authorization when you present a SEPA direct debit collection notification.

Enter or Edit Debit Authorization Details

When you create a SEPA debit authorization, you can select a transaction type of Recurring or One-off.

  • Recurring direct debits: Your customer authorizes regular direct debits that you initiate.

  • One-off direct debits: Your customer authorizes collection of only one direct debit.

    Note: A one-off SEPA debit authorization cannot be used for any subsequent transactions.

You can also specify the intended frequency of collection against a debit authorization. Frequency can range from daily to annually.

Another optional attribute is the final collection date, which is the intended date of the last collection against a debit authorization.

SEPA debit authorizations are versioned as they are updated. The application assigns a 1 to the first version of a debit authorization. Version 1 increases by one due to a change in:

  • A debtor bank account

  • A creditor legal entity

  • A creditor identification number

  • An authorization reference identifier

If any of the preceding values change, a reason for the change to the SEPA debit authorization is required in the Edit Debit Authorization dialog box.

SEPA debit authorizations are date-specific. The following rules apply:

  • You can specify both a final collection date and a cancellation date.

  • A canceled SEPA debit authorization cannot be reenabled.

  • A SEPA debit authorization automatically expires when 36 months elapse after the last initiated direct debit.

View History

In the History section, you can see all the past versions of the SEPA debit authorization.

ISO 20022 is the platform proposed by the International Organization for Standardization (ISO) to develop all financial messages. This topic provides Payments data mapping information for SEPA and CGI implementations of the ISO 20022 direct debit message.

The ISO 20022 direct debit message structure contains the following blocks of message elements:

  • Group header message elements

  • Payment information message elements

  • Direct debit transaction information message elements

Group Header Message Elements

The following table lists the group header message elements and Payments data mapping information for SEPA and CGI implementations of the ISO direct debit message.

Message Element <XML Tag> ISO Element Number SEPA Implementation Mapping CGI Implementation Mapping

Group Header

<GrpHdr>

1.0

Set of characteristics shared by all individual transactions included in the message.

Same as SEPA

Message Identification

<MsgId>

1.1

Settlement Batch Number

Tag Structure:

MsgId>543</MsgId>

Same as SEPA

Creation Date Time

<CreDtTm>

1.2

File generation system date

Tag Structure:

<CreDtTm>20100406T23:56:55</CreDtTm>

Same as SEPA

Authorization

<Authstn>

1.3

AOS element. Not supported

Not supported

Number Of Transactions

<NbOfTxs>

1.6

Sum of number of transactions in file

Tag Structure:

<NbOfTxs>1</NbOfTxs>

Same as SEPA

Control Sum

<CtrlSum>

1.7

Total of the payment amounts

Tag Structure:

<CtrlSum>15027.4</CtrlSum>

Same as SEPA

Initiating Party

<InitgPty>

1.8

Tag Structure:

<InitgPty>

<Nm>SEPA_INIT_NM</Nm>

<Id>

<OrgId>

<Othr>

<Id>SEPA_INT_IDNT</Id>

<Issr>SEPA_INIT_ISUR</Issr>

</Othr>

</OrgId>

</Id>

</InitgPty>

Same as SEPA

Name

<Nm>

9.1.0

Mapped with the values defined in Legal Entity.

Mapping:

Name INITIATING_PARTY_NAME

Same as SEPA

Postal Address

<PstlAdr>

9.1.1

AOS element. Not used

Not supported for CGI. [AOS element that can be supported for free in future.]

Identification

<Id>

9.1.12

Not Applicable

Same as SEPA

Organization Identification

Not Applicable

9.1.13

Not supported

Payment System Identifier setting "ISO20022 Organization Identification."

Private Identification

Not Applicable

Not Applicable

Not supported

Not Used

Country of Residence

<CtryOfRes>

9.1.33

AOS element. Not used

Not supported for CGI. [AOS element that can be supported for free in future.]

Forwarding Agent

<FwdgAgt>

1.9

AOS element. Not used

Not Used

Payment Information Message Elements

The following table lists payment information message elements and Payments data mapping information for SEPA and CGI implementations of the ISO direct debit message.

Message Element <XML Tag> ISO Element Number SEPA Implementation Mapping proposal CGI Implementation Mapping proposal )

Payment Information

<PmtInf>

2.0

The Payment Information block is mandatory and repetitive. It is the logical grouping element. It contains, among others, elements related to the Credit side of the transaction, such as Creditor or PaymentTypeInformation and DirectDebitTransactionInformation which contains, among others, elements related to the Debit side of the transaction, such as Debtor or RemittanceInformation.

Same as SEPA

Payment Information Identification

<PmtInfId>

2.1

System generated Settlement Group ID. This is a system wide unique key.

Tag structure:

<PmtInfId>543_1</PmtInfId>

Same as SEPA

Payment Method

<PmtMtd>

2.2

DD

Tag structure:

<PmtMtd>DD</PmtMtd>

Same as SEPA

Batch Booking

<BtchBookg>

2.3

Value from FCPP

Tag structure:

<BtchBookg>true</BtchBookg>

Same as SEPA

Number of Transactions

<NbOfTxs>

2.4

Number of transactions in the payment information block

Tag structure:

<NbOfTxs>1</NbOfTxs>

Same as SEPA

Control Sum

<CtrlSum>

2.5

Sum of all the transactions in the payment information block

Tag structure:

<CtrlSum>1156.34</CtrlSum>

Same as SEPA

Payment Type Information

<PmtTpInf>

2.6

Not Applicable

Same as SEPA

Instruction Priority

<InstrPrty>

2.7

AOS element. Not supported

Not supported

Service Level

<SvcLvl>

2.8

Not Applicable

Same as SEPA

Code

<Cd>

2.9

SEPA

Tag Structure:

<SvcLvl>

<Cd>SEPA</Cd>

</SvcLvl>

CGI

Tag Structure:

<SvcLvl>

<Cd>XXXX</Cd>

</SvcLvl>

Proprietary

<Prtry>

2.10

AOS element. Not supported

Not supported

Local Instrument

<LclInstrm>

2.11

Not Applicable

Same as SEPA

Code

<Cd>

2.12

Can be set up at the payer level (primary source) or FCPP (secondary source). The only values are CORE and B2B

Tag structure:

<LclInstrm>

<Cd>CORE</Cd>

</LclInstrm>

Can be set up at the payer level (primary source) or FCPP (secondary source). Values are as per the external codes list.

Tag Structure:

<LclInstrm>

<Cd>XXXX</Cd>

</LclInstrm>

Proprietary

<Prtry>

2.13

AOS element. Not supported.

Not supported.

Sequence Type

<SeqTp>

2.14

Depending on the type of mandate the following values are supported:

If recurrent mandate FRST/RCUR/FNAL

If one off mandate OOFF

Tag Structure:

<SeqTp>OOFF</SeqTp>

Depending on the type of mandate the following values are supported:

If recurrent mandate FRST/RCUR/FNAL

If one off mandate OOFF

Tag Structure:

<SeqTp>OOFF</SeqTp>

Category Purpose

<CtgyPurp>

2.15

SUPP

Tag structure:

<CtgyPurp>

<Cd>SUPP</Cd>

</CtgyPurp>

Leave Blank

At least one bank (JPMC) does not populate Category Purpose.

Tag structure:

<CtgyPurp>

<Cd></Cd>

</CtgyPurp>

The choice of SUPP is based on AR Transaction Class. Transaction Class contains only Invoice, Credit Memo, Debit Memo, and the last two don't fit any ISO purpose codes.

Alternately, this could come from AR Transaction Type. However, there is no easy way to map those to ISO Purpose codes without AR enhancement.

Requested Collection Date

<ReqColltnDt>

2.18

Settlement Date

Tag structure:

<ReqdColltnDt>20100406</ReqdColltnDt>

Settlement Date

Tag structure: <ReqdColltnDt>20100406</ReqdColltnDt>

Creditor

<Cdtr>

2.19

Name: Legal Entity Name on the Debit Authorization

Postal Address: First two lines of address of Legal Entity

Identification: Not supported

Country: Country of Legal Entity

Tag structure:

<Cdtr>

<Nm>Vision Operations</Nm>

<PstlAdr>

<Ctry>US</Ctry>

<AdrLine>475 Park Avenue</AdrLine>

</PstlAdr>

</Cdtr>

Same as SEPA

Name

<Nm>

9.1.0

Not Applicable

Same as SEPA

Postal Address

<PstlAdr>

9.1.1

Not Applicable

Same as SEPA

Address Type

Not Applicable

9.1.2

AOS element. Not supported.

Same as SEPA

Address Line

Not Applicable

9.1.11

AOS element that can be supported for free.

Primary address of the legal entity selected on the mandate.

Street Name

Not Applicable

9.1.5

AOS element that can be supported for free.

Same as SEPA

Building Number

Not Applicable

9.1.6

AOS element that can be supported for free.

Same as SEPA

Post Code

Not Applicable

9.1.7

AOS element that can be supported for free.

Primary address of the legal entity selected on the mandate.

Town Name

Not Applicable

9.1.8

AOS element that can be supported for free.

Primary address of the legal entity selected on the mandate.

Country Subdivision

Not Applicable

9.1.9

AOS element. Not supported.

Primary address of the legal entity selected on the mandate.

Country

Not Applicable

9.1.10

Not Applicable

Same as SEPA

Identification

Not Applicable

9.1.12

AOS element that can be supported for free.

Same as SEPA

Country of Residence

<CtryOfRes>

9.1.33

AOS element. Not supported.

Primary address of the legal entity selected on the mandate.

Creditor Account

<CdtrAcct>

2.20

IBAN of the Internal Bank Account of the creditor will be mapped to this field

Tag structure:

<CdtrAcct>

<Id>

<IBAN>IT60X0542811101000000123456</IBAN>

</Id>

<Ccy>EUR</Ccy>

</CdtrAcct>

Same as SEPA

Identification

<Id>

1.1.0

Not Applicable

Same as SEPA

Type

<Tp>

1.1.8

AOS element that can be supported for free.

Same as SEPA

Currency

<Ccy>

1.1.11

Not Applicable

Same as SEPA

Name

<Nm>

1.1.12

AOS element that can be supported for free.

Same as SEPA

Creditor Agent

<CdtrAgt>

2.21

BIC of the internal bank branch of the bank account attached to the mandate

Tag structure:

<CdtrAgt>

<FinInstnId>

<BIC>BOFABE3X</BIC>

</FinInstnId>

</CdtrAgt>

BIC of the internal bank branch of the bank account attached to the mandate, as well as the branch number.

Creditor Agent Account

<CdtrAgtAcct>

2.11

AOS element. Not supported.

Same as SEPA

Ultimate Creditor

<UltmtCdtr>

2.23

Not supported at this level. Mapping provided in Direct debit transaction information block.

Same as SEPA

Name

<Nm>

9.1.0

Not supported at this level.

Same as SEPA

Postal Address

<PstlAdr>

9.1.1

AOS element. Not supported.

Passed only when Ultimate Creditor (UltCdtr) is populated.

Identification

<Id>

9.1.12

Not supported at this level.

Same as SEPA

Organization Identification

Not Applicable

9.1.13

Not supported at this level.

Same as SEPA

Private Identification

Not Applicable

9.1.21

Not supported at this level.

Same as SEPA

Country of Residence

<CtryOfRes>

9.1.33

AOS element. Not supported.

Not supported.

Charge Bearer

<ChrBr>

2.24

SLEV

Tag structure:

<ChrgBr>SLEV</ChrgBr>

Payer Bank Charge Bearer

Charges Account

<ChrgsAcct>

2.25

AOS element. Not supported

Not Used

Charges Account Agent

<ChrgsAcctAgt>

2.26

AOS element. Not supported

Not Used

Creditor Scheme Identification

<CdtrSchmeId>

2.27

Identification Creditor Identifier on the Debit Authorization populated by Identification.

This data can be present at payment information or direct debit transaction information level.

Tag structure:

<CdtrSchmeId>

<Id>

<PrvtId>

<Othr>

<Id>1234</Id>

<SchmeNm>

<Prtry>SEPA</Prtry>

</SchmeNm>

</Othr>

</PrvtId>

</Id>

</CdtrSchmeId>

Same as SEPA

Name

<Nm>

9.1.0

AOS element. Not supported

Same as SEPA

Postal Address

<PstlAdr>

9.1.1

AOS element. Not supported

Same as SEPA

Identification

<Id>

9.1.12

Not supported in favor of Private Identifier

Same as SEPA

Private Identification

<PrvtId>

9.1.21

Tax identifier of the creditor legal entity selected on the mandate.

Tag structure:

<PrvtId>

<Othr>

<Id>XXXX</Id>

</Othr>

</PrvtId>

Same as SEPA

Other

<Othr>

9.1.27

Not supported in favor of Private Identifier

Same as SEPA

Direct Debit Transaction Information Message Elements

The following table lists the direct debit transaction information message elements and Payments data mapping information for SEPA and CGI implementations of the ISO direct debit message.

Message Element <XMLTag> ISO Element Number SEPA Implementation Mapping proposal CGI Implementation Mapping proposal

Direct Debit Transaction Information

<DrctDbtTxInf>

2.28

Set of elements used to provide information on the individual transactions included in the message.

Set of elements used to provide information on the individual transactions included in the message.

Payment Identification

<PmtId>

2.29

The instruction and the end to end identification are part of payment identification

Tag Structure:

<PmtId>

<InstrId>AR110086</InstrId>

<EndToEndId>AR110086</EndToEndId>

</PmtId>

See Mapping

The instruction and the end to end identification are part of payment identification

Tag Structure:

<PmtId>

<InstrId>AR110086</InstrId>

<EndToEndId>AR110086</EndToEndId>

</PmtId>

See Mapping

Instruction Identification

<InstrId>

2.30

PSON number on the receipt

Same as SEPA

End To End Identification

<EndToEndId>

2.31

PSON number on the receipt

Same as SEPA

Payment Type Information

<PmtTpInf>

2.32

Not Applicable

Same as SEPA

Instruction Priority

<InstrPrty>

2.33

AOS element. Not supported

Not supported

Service Level

<SvcLvl>

2.34

Not Applicable

Same as SEPA

Code

<Cd>

2.35

SEPA

Tag Structure:

<SvcLvl>

<Cd>SEPA</Cd>

</SvcLvl>

CGI

Tag Structure:

<SvcLvl>

<Cd>XXXX</Cd>

</SvcLvl>

Proprietary

<Prtry>

2.36

AOS element. Not supported

Not supported

Local Instrument

<LclInstrm>

2.37

Not Applicable

Same as SEPA

Code

<Cd>

2.38

Can be set up at the payer level (primary source) or FCPP (secondary source). The only values are CORE and B2B

Tag structure:

<LclInstrm>

<Cd>CORE</Cd>

</LclInstrm>

Can be set up at the payer level (primary source) or FCPP (secondary source). Values are as per the external codes list.

Tag Structure:

<LclInstrm>

<Cd>XXXX</Cd>

</LclInstrm>

Proprietary

<Prtry>

2.39

AOS element. Not supported.

Not supported.

Sequence Type

<SeqTp>

2.40

Depending on the type of mandate the following values are supported:

If recurrent mandate FRST/RCUR/FNAL

If one off mandate OOFF

Tag Structure:

<SeqTp>OOFF</SeqTp>

Depending on the type of mandate the following values are supported:

If recurrent mandate FRST/RCUR/FNAL

If one off mandate OOFF

Tag Structure:

<SeqTp>OOFF</SeqTp>

Category Purpose

<CtgyPurp>

2.41

SUPP

Tag structure:

<CtgyPurp>

<Cd>SUPP</Cd>

</CtgyPurp>

Leave Blank

At least one bank (JPMC) does not populate Category Purpose.

Tag structure:

<CtgyPurp>

<Cd></Cd>

</CtgyPurp>

Instructed Amount

<InstdAmt>

2.44

Transaction amount and currency

Tag structure:

<InstdAmt Ccy="EUR">15027.4</InstdAmt>

Transaction amount and currency

Tag structure:

<InstdAmt Ccy="EUR">15027.4</InstdAmt>

Charge Bearer

<ChrgBr>

2.45

SLEV

Tag structure:

<ChrgBr>SLEV</ChrgBr>

Payer Bank Charge Bearer

Direct Debit Transaction

<DrctDbtTx>

2.46

Tag structure:

<DrctDbtTx>

<MndtRltdInf>

<MndtId>AR SEPA 95.1</MndtId>

<DtOfSgntr>20100406</DtOfSgntr>

<AmdmntInd>true</AmdmntInd>

<AmdmntInfDtls>

<OrgnlMndtId>M1.1.1</OrgnlMndtId>

<OrgnlCdtrSchmeId>

<Nm>Vision Operations</Nm>

<Id>

<PrvtId>

<Othr>

<Id>DE98ZZZ09999999999</Id>

<SchmeNm>

<Prtry>SEPA</Prtry>

</SchmeNm>

</Othr>

</PrvtId>

</Id>

</OrgnlCdtrSchmeId>

<OrgnlDbtrAcct>

<Id>

<IBAN>GB52CHAS60924235582306</IBAN>

</Id>

</OrgnlDbtrAcct>

<OrgnlDbtrAgt>

<FinInstnId>

<Othr>

<Id>SMNDA</Id>

</Othr>

</FinInstnId>

</OrgnlDbtrAgt>

</AmdmntInfDtls>

</MndtRltdInf>

<CdtrSchmeId>

<Id>

<PrvtId>

<Othr>

<Id>1234</Id>

<SchmeNm>

<Prtry>SEPA</Prtry>

</SchmeNm>

</Othr>

</PrvtId>

</Id>

</CdtrSchmeId>

</DrctDbtTx>

Same as SEPA

Mandate Related Information

<MndtRltInf>

2.47

 

Only added if a debit authorization exists.

Mandate Identification

<MndtId>

2.48

Unique Mandate Reference Id

Unique Mandate Reference Id

Date Of Signature

<DtOfSgntr>

2.49

Date on which the debtor has signed the direct debit mandate.

Date on which the debtor has signed the direct debit mandate.

Amendment Indicator

<AmdmntInd>

2.50

True/False

True/False

Amendment Information Details

<AmdmntInfDtls>

2.51

Not Applicable

Same as SEPA

Original Mandate Identification

<OrgnlMndtId>

2.52

Original Mandate Reference Number in the mandate.

Same as SEPA

Original Creditor Scheme Identification

<OrgnlCdtrSchmeId>

2.53

Not Applicable

Same as SEPA

Name

<Nm>

9.1.0

Not supported in favor of Private Identifier

Same as SEPA

Postal Address

<PstlAdr>

9.1.1

AOS element. Not supported.

Not supported.

Identification

<Id>

9.1.12

Not supported in favor of Organization Identifier

Same as SEPA

Organization Identification

Not Applicable

9.1.13

Payment System Account parameters > value for ISO20022 Creditor Scheme Identification.

Note that this provides the current creditor scheme as the payment system account has no way to track historical data. Per BofA and JPMC, this value should not change.

Same as SEPA

Private Identification

<PrvtId>

9.1.21

Not supported in favor of Organization Identifier

Same as SEPA

Other

<Othr>

9.1.27

Not supported in favor of Private Identifier

Same as SEPA

Country of Residence

<CtryOfRes>

9.1.33

AOS element. Not supported

Same as SEPA

Original Creditor Agent

<OrgnlCdtrAgt>

2.54

AOS element. Not supported

Same as SEPA

Original Creditor Agent Account

<OrgnlCdtrAgtAcct>

2.55

AOS element. Not supported

Same as SEPA

Original Debtor

<OrgnlDbtr>

2.56

AOS element. Not supported

Same as SEPA

Original Debtor Account

<OrgnlDbtrAcct>

2.57

Customer Bank Account IBAN on the Original Debit Authorization is passed in the IBAN

Customer Bank Account IBAN on the Original Debit Authorization is passed in the IBAN

Bank Account Currency

Bank Account Name.

If IBAN is not provided, populate the regular bank account number in the "Othr" tag.

Original Debtor Agent

<OrgnlDbtrAgt>

2.58

Not captured on debit authorization

Same as SEPA

Original Debtor Agent Account

<OrgnlDbtrAgtAcct>

2.59

AOS element. Not supported

Not Used

Original Final Collection Date

<OrgnlFnlColltnDt>

2.60

AOS element. Not supported

Not Used

Original Frequency

<OrgnlFrqcy>

2..61

AOS element. Not supported

Not Used

Electronic Signature

<ElctrncSgntr>

2.62

Not Supported.

Not Supported in V2

First Collection Date

<FrstColltnDt>

2.63

AOS element. Not supported

Date of the settlement for which the mandate was first used.

Final Collection Date

<FnlColltnDt>

2.64

AOS element. Not supported

Mandate Final Collection Date

Frequency

<Frqcy>

2.65

AOS element. Not supported

Mandate Frequency

Creditor Scheme Identification

<CdtrSchmeId>

2.66

See Identification.

See Identification.

Name

<Nm>

9.1.0

AOS element. Not supported

Not Supported.

Postal Address

<PstlAdr>

9.1.1

AOS element. Not supported

Not Used

Identification

<Id>

9.1.12

Not supported, in favor of Organization Identification

Same as SEPA

Organization Identification

Not Applicable

9.1.13

Payment System Account parameters > value for ISO20022 Creditor Scheme Identification.

Same as SEPA

Private Identification

<PrvtId>

9.1.21

Not supported, in favor of Organization Identification

Not Supported.

Other

<Othr>

9.1.27

Not supported, in favor of Private Identification

Same as SEPA

Country of Residence

<CtryOfRes>

9.1.33

AOS element. Not supported

Not Supported.

Prenotification Identification

<PreNtfctnId>

2.67

This element is not supported.

AOS element. Not supported

Prenotification Date

<PreNtfctnDt>

2.68

This element is not supported.

AOS element. Not supported

Ultimate Creditor

<UltmtCdtr>

2.69

Name Invoice Legal Entity Name

Identification Populate

Legal entity registration number by other in OrganizationIdentification

Tag description:

<UltmtCdtr>

<Nm>Vision Operations</Nm>

<Id>

<OrgId>

<Othr>

<Id>SYS11100</Id>

</Othr>

</OrgId>

</Id>

</UltmtCdtr>

Mapping: Ultimate Creditor BICOrBEI/Ultimate Creditor Other ID from PSA settings. Else Populate the LE registration number of Invoice LE.

Name

<Nm>

9.1.0

Not Applicable

Same as SEPA

Postal Address

<PstlAdr>

9.1.1

Conditional

AOS element that can be supported for free.

Identification

<Id>

9.1.12

Not Applicable

Same as SEPA

Organization Identification

Not Applicable

9.1.13

AOS element. Not supported

Not Supported.

Private Identification

Not Applicable

9.1.21

AOS element. Not supported

Not Supported.

Country of Residence

<CtryOfRes>

9.1.33

AOS element. Not supported

Not Supported.

Debtor Agent

<DbtrAgt>

2.70

BIC of the branch of Customer Bank Account by FinancialInstitutionIdentification

Tag structure:

<DbtrAgt>

<FinInstnId>

<BIC>BOFABE3X</BIC>

</FinInstnId>

</DbtrAgt>

BIC of the internal bank branch of the bank account attached to the mandate, as well as the branch number.

Debtor Agent Account

<DbtrAgtAcct>

2.71

AOS element. Not supported

Not used.

Debtor

<Dbtr>

2.72

Name Customer Name

Address Customer Address

Identification Populate

BIC of the bank branch of customer bank account in OrganizationIdentification

Tag structure:

<Dbtr>

<Nm>AR SEPA Customer</Nm>

<PstlAdr>

<Ctry>US</Ctry>

<AdrLine>Hyderabad</AdrLine>

</PstlAdr>

<Id>

<OrgId>

<BIC>BOFABE3X</BIC>

</OrgId>

</Id>

</Dbtr>

Same as for SEPA.

Name Customer Name

Address Customer Address

Identification Populate

BIC of the bank branch of customer bank account in OrganizationIdentification

Tag structure:

<Dbtr>

<Nm>AR SEPA Customer</Nm>

<PstlAdr>

<Ctry>US</Ctry>

<AdrLine>Hyderabad</AdrLine>

</PstlAdr>

<Id>

<OrgId>

<BIC>BOFABE3X</BIC>

</OrgId>

</Id>

</Dbtr>

Name

<Nm>

9.1.0

Not Applicable

Same as SEPA

Postal Address

<PstlAdr>

9.1.1

Not Applicable

Same as SEPA

Address Type

Not Applicable

9.1.2

AOS element. Not supported

Not Supported.

Country

Not Applicable

9.1.10

Not Applicable

Same as SEPA

Address Line

Not Applicable

9.1.11

Not Applicable

Same as SEPA

Street Name

Not Applicable

9.1.5

AOS element. Not supported

Not Supported.

Building Numb

Not Applicable

9.1.6

AOS element. Not supported

Not Supported.

Post Code

Not Applicable

9.1.7

AOS element. Not supported

Not Supported.

Town Name

Not Applicable

9.1.8

AOS element. Not supported

Not Supported.

Country Subdivision

Not Applicable

9.1.9

AOS element. Not supported

Not Supported.

Identification

<Id>

9.1.12

Not Applicable

Same as SEPA

Organization Identification

Not Applicable

9.1.13

Not used in favor of Private Identification

Same as SEPA

Private Identification

Not Applicable

9.1.21

Not Applicable

Same as SEPA

Country of Residence

<CtryOfRes>

9.1.33

AOS element. Not supported.

Not supported.

Debtor Account

<DbtrAcct>

2.73

Customer Bank Account IBAN is populated by IBAN

Tag Structure:

<DbtrAcct>

<Id>

<IBAN>

IT60X0542811101000000123456

</IBAN>

</Id>

</DbtrAcct>

For CGI, we can pass the bank account number in other tag in addition to IBAN.

Ultimate Debtor

<UltmtDbtr>

2.74

Not supported Bill-to Customer is the same as the Customer/Payer used as Debtor.

Same as SEPA

Instruction for Creditor Agent

<InstrForCdtrAgt>

2.75

AOS element. Not supported.

Not supported.

Purpose

<Purp>

2.76

Not Applicable

Same as SEPA

Code

<Cd>

2.77

SUPP is passed during formatting.

Tag Structure:

<Purp>

<Cd>SUPP</Cd>

</Purp>

Purpose Code from the Payer. If null, from the FCPP.

Proprietary

<Prtry>

2.78

AOS element. Not supported.

Not supported.

Regulatory Reporting

<RgltryRptg>

2.79

AOS element. Not supported.

Not supported.

Tax

<Tax>

2.80

AOS element. Not supported.

Not supported.

Related Remittance Information

<RltdRmtInf>

2.81

AOS element. Not supported.

Not supported.

Remittance Information

<RmtInf>

2.88

Not Applicable

Same as SEPA

Unstructured

<Ustrd>

2.89

Not used in favor of Structured element

Same as SEPA

Structured

<Strd>

2.90

We populate the invoice number in the reference.

<RmtInf>

<Strd>

<CdtrRefInf>

<Tp>

<CdOrPrtry>

<Cd>SCOR</Cd>

</CdOrPrtry>

</Tp>

<Ref>23184</Ref>

</CdtrRefInf>

</Strd>

</RmtInf>

In the case of grouped invoices, populate one STRD element per invoice.

Referred Document Information

<RfrdDocInf>

2.91

AOS element. Not supported.

Not supported.

Referred Document Amount

<RfrdDocAmt>

2.99

AOS element. Not supported.

Not supported.

Creditor Reference Information

<CdtrRefInf>

2.110

Not Applicable

Same as SEPA

Creditor Reference Type

<CdtrRefTp>

2.111

Not Applicable

Same as SEPA

Code

<Cd>

2.113

CINV representing Commercial Invoice

Same as SEPA

Proprietary

<Prtry>

2.114

AOS element. Not supported.

Not supported.

Issuer

<Issr>

2.115

Not Applicable

Same as SEPA

Creditor Reference

<CdtrRef>

2.116

AR Transaction Number(s) comma delimited if multiple invoices are included on one receipt

In the case of grouped invoices, populate one STRD element per invoice.

Supplier

<Invcr>

2.117

AOS element. Not supported.

Not supported.

Invoiced

<Invcee>

2.118

AOS element. Not supported.

Not supported.

Additional Remittance Information

<AddtlRmtInf>

2.119

AOS element. Not supported.

Not supported.

Update of a Settlement Batch from Stuck to Success

When you set up a funds capture process profile, you can specify whether you want to receive funds capture acknowledgments from your bank. To set up funds capture acknowledgments, you specify an Inbound Response Format in the Settlement Response Processing section on the Formats tab of the funds capture process profile.

However, if your bank doesn't support funds capture acknowledgments, and you mistakenly specify an Inbound Response Format in the Settlement Response Processing section anyway, then a successful settlement batch is set to an intermediary status that waits for an acknowledgment that won't arrive. You can't move such transactions from an intermediary status to a Success or Reject status in Oracle Payments.

But you can move a settlement batch and its transactions from an intermediary status to a Success status under certain conditions. When you submit the Retrieve Funds Capture Acknowledgments process, the settlement batch and its transactions update from an intermediary status to Success only if:

  • You select a reference number from the Settlement Batch Reference choice list.

  • The funds capture processing type on the funds capture process profile is Bank Account

  • These formats aren't specified in the Formats tab of the funds capture process profile:

    • Settlement section: Inbound Response Format

    • Settlement Response Processing section: Outbound Format and Inbound Response Format

  • A funds capture acknowledgment isn't attached to the transmission configuration.

Retrieval of Funds Capture Acknowledgment Files Using a Wildcard

You can retrieve multiple funds capture acknowledgment files from your bank instead of a single file by using a wildcard in the file name. First, you must opt in to the applicable feature. Second, create a transmission configuration using the protocol named Secure File Transfer Retrieval Protocol for Static File Names. Then, on the Create Transmission Configuration page in the Value field for the Remote File Name parameter, you can enter an asterisk in the file name as a wildcard character. By entering the asterisk, you can retrieve multiple acknowledgment files from your bank in a single attempt.

For example, suppose you have two files:

  • PAY_ACK_01012019.xml

  • PAY_ACK_02012019.xml

To retrieve both files in one attempt, enter PAY_ACK_*.xml in the Value field of the Remote File Name parameter on the Create Transmission Configuration page.

To retrieve funds capture acknowledgment files from your bank, you have the option of using either static file names, dynamic file names with asterisks, or both. After you opt in to the applicable feature, you can connect with banks that support both static file names and dynamic file names.

  1. In the Offerings work area, select the Financials offering.

  2. Click Opt In Features.

  3. On the Opt In: Financials page, click the Features icon, or pencil, for Payments.

  4. On the Edit Features: Payments page, select the Enable check box for the feature named Retrieve Funds Capture Acknowledgment Files Using a Wildcard Search.

  5. Click Done.

Reports for Manage Funds Capture

Funds Capture Accompanying Letters

This topic includes details about the Funds Capture Accompanying Letter.

Overview

The Funds Capture Accompanying Letter is a predefined funds capture report that is manually delivered to your payment system or bank. The report accompanies a settlement batch file and summarizes its contents

The following figure illustrates an example of the Funds Capture Accompanying Letter.

This figure illustrates an example of the Funds
Capture Accompanying Letter.

Key Insights

The following table lists the difference between the formal Funds Capture Accompanying Letter report name and the process name.

Report Name Process Name Output

Funds Capture Accompanying Letter Formats

Create Settlement Batch Accompanying Letter

.PDF file

Generation of the Funds Capture Accompanying Letter

To generate the Funds Capture Accompanying Letter from within Oracle Fusion Payments, complete these steps:

  1. In the Setup and Maintenance work area, go to the following:

    Navigate: Navigator > Setup and Maintenance > Search: Tasks pane: Manage Funds Capture Process Profiles > Go to Task > Select Processing Type > Create button.

    • Offering: Financials

    • Functional Area: Customer Payments

    • Task: Manage Funds Capture Process Profiles

  2. On the Manage Funds Capture Process Profiles page, select a processing type from the Select Processing Type choice list and click Create.

  3. On the Create Funds Capture Process Profile page, Formats tab, Settlement section, select options for the Outbound Format, Inbound Response Format, and the Accompanying Letter Format.

  4. Sign in as a manager.

  5. From the Accounts Receivables work area, click the Funds Capture icon.

  6. Click the Tasks icon.

  7. Click the Settlement Batch Accompanying Letter link.

  8. The parameters page for the Funds Capture Accompanying Letter appears.

  9. From the Settlement Batch Reference choice list, select the applicable settlement batch reference number and click Submit. A confirmation message displays with a process ID.

    Tip: Write down or remember the process ID.
  10. Navigate:Navigator > Tools > Scheduled Processes link.

  11. In the Process ID field on the Scheduled Processes page, enter the process ID and click Search. The result displays in the Search Results section.

  12. Select the resulting row in the Search Results section to display additional details on the page.

  13. In the Log and Output section, click the 1 more link to display the Attachments dialog box. You can now see the <process ID> .PDF output file.

Report Parameters

The following table describes the process parameter.

Name Description

Settlement Batch Reference

Application-assigned reference number for the settlement batch.

Frequently Asked Questions

The following table lists frequently asked questions and provides the answers about the Funds Capture Accompanying Letter.

FAQ Answer

How do I find this report?

You can find the Funds Capture Accompanying Letter in the Log and Output section. Click the 1 more link to display the Attachments dialog box. You can now see the .PDF output file.

Who uses this report?

  • Financial Manager

  • Financial Specialist

When do I use this report?

The Funds Capture Accompanying Letter is used when you want to summarize the contents of a settlement batch and manually send the summary and the settlement batch to the payment system or bank.

What can I do with this report?

You can:

  • Manually deliver the Funds Capture Accompanying Letter to your payment system or bank, along with the settlement batch.

What type of report is this?

Oracle Business Intelligence Publisher

This topic includes details about the Funds Capture Payer Notification report.

Overview

The Funds Capture Payer Notification report is a predefined funds capture report that can be faxed, emailed as a PDF attachment, printed, or mailed to customers after a settlement or settlement batch is transmitted to your payment system or bank. The report informs customers of a funds capture transaction that will charge their credit card or bank account.

This image illustrates an example of the Funds Capture Payer Notification report.

This figure illustrates an example of the Funds
Capture Payer Notification report.

Key Insights

This table lists the the formal Funds Capture Payer Notification report name and the process name that's used to manually generate the report.

Report Name Process Name Output

Funds Capture Payer Notification Formats

Send Receipt of Payment Notifications

PDF file if the delivery option is Printed, emailed as a PDF attachment if the delivery option is Email with .pdf as attachment, faxed if the delivery option is Fax, or as HTML in the body of the email if the delivery option is Email.

Email Delivery of the Funds Capture Payer Notification Report

To enable customers to receive the Funds Capture Payer Notification report by email, complete these steps:

  1. In the Setup and Maintenance work area, select:

    • Offering: Financials

    • Functional Area: Customer Payments

    • Task: Manage Funds Capture Process Profiles

  2. On the Manage Funds Capture Process Profiles, from the Select Processing Type choice list, select a processing type.

  3. Click Create.

  4. On the Funds Capture Process Profile page, Formats tab, Notification to Payer section, from the Format choice list, select the Receipt of Payment Notification format.

  5. From the Delivery Method choice list, select Email.

  6. Sign in as an Oracle Receivables user.

  7. Click the Billing icon.

  8. On the Billing Tasks pane, click the Create Customer link and create a customer, a customer address, and a customer site.

  9. On the Account Site page, select the Payment Details tab.

  10. In the Receipt of Payment Notification Preferences section, from the Debit Advice Delivery Method choice list, optionally select Email with .pdf as attachment. This option lets you attach the Funds Capture Payer Notification report to an email as a PDF attachment. If you select the Email option, the Funds Capture Payer Notification report is sent as HTML in the body of the email.

  11. In the Debit Advice Email ID field, enter a valid email.

  12. In the Setup and Maintenance work area, select:

    • Offering: Financials

    • Functional Area: Customer Payments

    • Task: Manage Internal Payees

  13. On the Manage Internal Payees page, click the Create icon.

  14. On the Create Internal Payee page, Notification to Payer section, enter a valid email in the From Email field and the subject that you want to see in the notification email in the Subject field.

Generation of the Funds Capture Payer Notification Report

To generate the Funds Capture Payer Notification report from within Oracle Payments, complete these steps:

  1. From the Accounts Receivable work area, click the Funds Capture icon.

  2. Click the Tasks icon.

  3. Click the Send Receipt of Payment Notifications link. The parameters page for the Send Receipt of Payment Notifications appears.

  4. Select applicable parameters and click Submit. A confirmation message displays with a process ID.

    Tip: Write down or remember the process ID.
  5. Navigate: Navigator > Tools > Scheduled Processes link.

  6. In the Process ID field on the Scheduled Processes page, enter the process ID and click Search. The result displays in the Search Results section.

  7. Select the resulting row in the Search Results section to display additional details on the page.

  8. In the Log and Output section, click the 1 more link to display the Attachments dialog box. You can now see the <process ID> PDF output file.

Report Parameters

This table describes the process parameters.

Name Description

Settlement Batch Reference

Payments-assigned reference number of the settlement batch.

From Settlement Date

Starting date within a date range of settlement transactions.

To Settlement Date

Ending date within a date range of settlement transactions.

From Payment System Order Number

Order number generated by Payments, which identifies the first settlement transaction to the payment system.

To Payment System Order Number

Order number generated by Payments, which identifies the last settlement transaction to the payment system.

Allow Sending Replacement Copy

The inclusion of settlements in the Funds Capture Payer Notification report that were included in a previous report if, for example, the customer requests a duplicate copy of the Funds Capture Payer Notification report.

Frequently Asked Questions

The following table lists frequently asked questions and provides answers about the Funds Capture Payer Notification report.

FAQ Answer

How do I find this report?

You can find the Funds Capture Payer Notification report in the Output section. Click the 1 more link to display the Attachments dialog box. You can now see the PDF output file.

Who uses this report?

  • Financial Manager

  • Financial Specialist

When do I use this report?

The Funds Capture Payer Notification report is used when you want to inform the customer of a funds capture transaction that will charge the customer's credit card or bank account. By informing customers of expected debits to their bank accounts, they can maintain sufficient balances so that payments aren't rejected.

It is considered a best practice to inform your customers that funds capture transactions will charge their credit card or bank account.

What can I do with this report?

You can:

  1. Generate and schedule the Funds Capture Payer Notification report.

  2. Send the Funds Capture Payer Notification report to customers by email, US mail, or fax.

What type of report is this?

Oracle Business Intelligence Publisher

FAQs for Manage Funds Capture

You can experience inconsistent data between applications. You may also unintentionally create holds or charges on credit cards for amounts not owed by the card holder.

Using the transaction testing functionality, you can initiate transactions without source product interaction to test the setup of Oracle Fusion Payments and the payment system connectivity. Transactions initiated from Payments, rather than the source product, are not recorded in any source product. This functionality is a valuable testing and diagnostic tool, but it can create inconsistent data between applications if used incorrectly in a live environment.

Caution: On a live instance of Payments, it is strongly recommended that you disable the transaction testing functionality and unassign it from the payment administrator.

What's the difference between credit card payments made with a CVN or without a CVN?

Credit card payments made with a 3 or 4-digit Card Verification Number (CVN) code that is on the front or back of the card improves transaction security and prevents fraud. When the cardholder isn't present in person, merchants often ask for the code so they can secure transactions occurring online, by mail, fax, or over the phone. The code results in an electronic authorization request to verify the authenticity of the card. The merchant receives a reply message as to whether or not the card and the code match. Merchants who send the CVN with their credit card authorizations may also accrue lower transaction costs than those who don't.

Note: CVN capture during transaction authorization is currently not allowed. However, you may provide CVN during credit card token creation.

Credit card payments made online, by mail, fax, or over the phone without a CVN requested by the merchant, present a greater risk to the merchant because the card isn't verified as authentic by the reply message to the electronic authorization request. Additionally, in some territories and countries, credit card authorization is rejected without the CVN code.

Credit card payments made with required entry of a 3 or 4-digit Card Verification Number (CVN) necessitates the performance of two prerequisite setups. In the Setup and Maintenance work area, use the following: Offering: Financials, Functional Area: Customer Payments, Task: Manage Funds Capture Payment Methods. On the Manage Funds Capture Payment Methods page, select a payment method and click the Edit icon. In the Edit Funds Capture Payment Method dialog box, select the Require security code entry check box. On the Manage System Security Options page, enable tokenization in the Credit Card Data subsection. After this, when you save a transaction type of Invoice with a CVN required, the application creates an immediate authorization and receipt number for the invoice. Following the Payment Card Industry Data Security Standard (PCI DSS) security standards, the CVN isn't stored, even temporarily, in the application.

Note: CVN capture during transaction authorization is currently not allowed. However, you may provide CVN during credit card token creation.

Credit card payments made without required entry of a CVN, follow the usual process where you create a transaction type of Invoice, submit the Create Automatic Receipts process, and an authorization is created during automatic receipt creation.

When do customers use the simplified payment UI?

Oracle Payments Cloud provides a simplified, shared transaction extension component for payments by credit card or bank account. This simplified UI is used by products that integrate with Payments, such as Oracle Fusion Bill Management and Oracle Student Cloud. These products are used by self-service users, such as customers or students who require a modern UI to pay for products or services by credit card or bank account. As part of order booking or invoice payment processes, users enter their credit card or bank account data, which is stored by the application in a secured manner. A bank account is stored encrypted, whereas a credit card is first tokenized and then the token is stored instead of the credit card number.

When you create and save an external bank account in the majority of the European, Middle Eastern, and Caribbean countries where the IBAN (International Bank Account Number) is used according to SWIFT (Society for Worldwide Interbank Financial Telecommunication) guidelines, the bank account number automatically derives from the IBAN and populates the Account Number field.