The Payments module is a payment engine
designed to work with multiple Oracle E-Business Suite products in
order to facilitate the receipt of, issuance of, and management of,
customer receipts and batched supplier payments.
Below snapshot shows seeded applications that integrate with the Payment Modules
As
the central payment engine, Oracle Payments processes transactions,
such as invoice payments from Oracle Payables, bank account transfers
from Oracle Cash Management, and settlements against credit cards and
bank accounts from Oracle Receivables. Oracle Payments provides the
infrastructure needed to connect these applications and others with
third party payment systems and financial institutions.
The centralization of payment processing in Oracle Payments offers many benefits to deploying companies. Companies can efficiently centralize the payment process across multiple organizations, currencies, and regions. Better working capital management can be achieved by providing cash managers visibility into cash inflows and outflows.
Additionally, a full audit trail and control is supported through a single point of payment administration.
Oracle Payments is integrated with financial institutions and payment systems for receipt and payment processing, known as funds capture and funds disbursement, respectively.
Funds capture refers to the electronic retrieval of funds, typically by a payment system on behalf of the deploying company, from payers, such as customers, who owe debts to the deploying company. The payer, in this case, provides Oracle Payments with pertinent payment information, such as a credit card, debit card, or bank account number.
Funds disbursement, on the other hand, is the process of paying funds owed to creditors, such suppliers.
Oracle Payments supports the following electronic payment methods for funds capture payments:
The centralization of payment processing in Oracle Payments offers many benefits to deploying companies. Companies can efficiently centralize the payment process across multiple organizations, currencies, and regions. Better working capital management can be achieved by providing cash managers visibility into cash inflows and outflows.
Additionally, a full audit trail and control is supported through a single point of payment administration.
Oracle Payments is integrated with financial institutions and payment systems for receipt and payment processing, known as funds capture and funds disbursement, respectively.
Funds capture refers to the electronic retrieval of funds, typically by a payment system on behalf of the deploying company, from payers, such as customers, who owe debts to the deploying company. The payer, in this case, provides Oracle Payments with pertinent payment information, such as a credit card, debit card, or bank account number.
Funds disbursement, on the other hand, is the process of paying funds owed to creditors, such suppliers.
Oracle Payments supports the following electronic payment methods for funds capture payments:
- credit cards
- purchase cards
- PINless debit cards
- bank account transfers
Oracle Payments supports several payment methods for funds disbursement payments, including:
- checks
- wires
- electronic funds transfers"
General Features of the Payments Module (IBY)
The following sections describe the general features of Oracle Payments.
Advanced and Highly Configurable Formatting Framework
Financial institutions and payment systems require compliance with specific payment formats to disburse or capture funds. A large part of the effort and cost involved in establishing a relationship with a payment system is ensuring that a valid, correctly formatted payment file or message can be produced. To minimize this effort, Oracle Payments provides a formatting solution based on standard XML technology.
Formats are created as templates in Oracle XML Publisher and applied to an XML data file produced by Oracle Payments. These templates can be created or modified with minimal effort, using a standard text editor, such as Microsoft Word. Consequently, when a payment system or financial institution requires a change to its format, you can easily and quickly make the change.
Special consideration has been given to the complexity of creating fixed position and delimited formats. Oracle XML Publisher's eText feature is used for these format types. eText allows the format layout to be presented in an understandable tabular structure.
Oracle Payments offers an extensive library of payment formats that support various types of payment files and messages. EFT disbursements, printed checks, ACH debits, bills receivable remittances, and credit card authorizations and settlements are all supported. Deploying companies can use any format in this library. If a format is required, but it is not provided, it is easy to copy a similar format template and use it as the basis for creating a new format. This feature greatly speeds implementation and testing, as well as reduces implementation costs.
Flexible Validation Model
In payment processing, it is critical to ensure that payment messages and files sent to third party payment systems and financial institutions are both valid and correctly formatted. If this does not occur, the payment process is slowed and a cost is incurred to resolve the issue. To achieve straight through processing, Oracle Payments introduces a flexible way to ensure that payment-related validations are implemented.
Oracle Payments provides an extensive library of payment validations that are associated with the supported payment formats. Payment validations are implemented using a flexible framework that allows you to add new validation rules. Deploying companies can choose between using the prepackaged library of validations, using newly added validations, or using a combination of prepackaged and newly added validation rules.
The timing of validation execution also has flexibility. Payment validation rules can be assigned early or late in the payment process. Alternatively, a combination of early and late validation rule assignment can be used. You have flexibility in assigning validation rules to support your business model. For example, assigning and executing validation rules early in the payment process may be best for a decentralized payment environment. On the other hand, validation execution later in the process may be optimal in a shared service environment, where payment specialists can resolve any validation failures.
Secure Payment Data Repository
Oracle Payments serves as a payment data repository on top of the Trading Community Architecture (TCA) data model. The TCA model holds party information. Oracle Payments stores all of the party's payment information and its payment instruments, such as credit cards and bank accounts. This common repository for payment data provides data security by allowing central encryption management and masking control of payment instrument information.
Electronic Transmission Capability
Oracle Payments provides secured electronic payment file and payment message transmission, as well as transmission result processing. All previously existing electronic transmission features in Oracle Payments, Oracle Payables, and Oracle Globalizations are obsolete and have been replaced by the central Oracle Payments engine.
The following industry-standard transmission protocols are supported:
Advanced and Highly Configurable Formatting Framework
Financial institutions and payment systems require compliance with specific payment formats to disburse or capture funds. A large part of the effort and cost involved in establishing a relationship with a payment system is ensuring that a valid, correctly formatted payment file or message can be produced. To minimize this effort, Oracle Payments provides a formatting solution based on standard XML technology.
Formats are created as templates in Oracle XML Publisher and applied to an XML data file produced by Oracle Payments. These templates can be created or modified with minimal effort, using a standard text editor, such as Microsoft Word. Consequently, when a payment system or financial institution requires a change to its format, you can easily and quickly make the change.
Special consideration has been given to the complexity of creating fixed position and delimited formats. Oracle XML Publisher's eText feature is used for these format types. eText allows the format layout to be presented in an understandable tabular structure.
Oracle Payments offers an extensive library of payment formats that support various types of payment files and messages. EFT disbursements, printed checks, ACH debits, bills receivable remittances, and credit card authorizations and settlements are all supported. Deploying companies can use any format in this library. If a format is required, but it is not provided, it is easy to copy a similar format template and use it as the basis for creating a new format. This feature greatly speeds implementation and testing, as well as reduces implementation costs.
Flexible Validation Model
In payment processing, it is critical to ensure that payment messages and files sent to third party payment systems and financial institutions are both valid and correctly formatted. If this does not occur, the payment process is slowed and a cost is incurred to resolve the issue. To achieve straight through processing, Oracle Payments introduces a flexible way to ensure that payment-related validations are implemented.
Oracle Payments provides an extensive library of payment validations that are associated with the supported payment formats. Payment validations are implemented using a flexible framework that allows you to add new validation rules. Deploying companies can choose between using the prepackaged library of validations, using newly added validations, or using a combination of prepackaged and newly added validation rules.
The timing of validation execution also has flexibility. Payment validation rules can be assigned early or late in the payment process. Alternatively, a combination of early and late validation rule assignment can be used. You have flexibility in assigning validation rules to support your business model. For example, assigning and executing validation rules early in the payment process may be best for a decentralized payment environment. On the other hand, validation execution later in the process may be optimal in a shared service environment, where payment specialists can resolve any validation failures.
Secure Payment Data Repository
Oracle Payments serves as a payment data repository on top of the Trading Community Architecture (TCA) data model. The TCA model holds party information. Oracle Payments stores all of the party's payment information and its payment instruments, such as credit cards and bank accounts. This common repository for payment data provides data security by allowing central encryption management and masking control of payment instrument information.
Electronic Transmission Capability
Oracle Payments provides secured electronic payment file and payment message transmission, as well as transmission result processing. All previously existing electronic transmission features in Oracle Payments, Oracle Payables, and Oracle Globalizations are obsolete and have been replaced by the central Oracle Payments engine.
The following industry-standard transmission protocols are supported:
- FTP
- HTTP
- HTTPs
- AS/2
Flexible Support for Various Business Payment Models
Companies model their business units in various ways to obtain performance improvements and cost savings. Oracle Payments can be configured to support a variety of payment models. It can operate in a completely decentralized model where it is part of accounts payable or collection administration within each business unit. If your company has centralized financial activities in a shared service center, Oracle Payments also works to efficiently support the shared service center model.
Oracle Payments' flexibility also provides support to companies that wish to use a payment factory model. A payment factory allows operating units to maintain their own accounts payable and other payment administrative functions. The role of the payment factory is to handle communication and transactions with the deploying company's banking partners. Invoice selection can be done in Oracle Payables within a single operating unit. Then a payment factory administrator using Oracle Payments can consolidate payments from different operating units into a single payment file for transmission and settlement, thereby reducing transaction costs.
Oracle Payments supports Multi-Org Access Control throughout its processes to build payments and create payment files, as well as in the dashboard pages, which are provided for you to monitor and manage the payment process. Multi-Org Access Control enables you to efficiently process business transactions by processing and reporting on data that resides in an unlimited number of operating units, within a single applications responsibility. Data security is maintained using security profiles, which are defined for a list of operating units and data access privileges."
Companies model their business units in various ways to obtain performance improvements and cost savings. Oracle Payments can be configured to support a variety of payment models. It can operate in a completely decentralized model where it is part of accounts payable or collection administration within each business unit. If your company has centralized financial activities in a shared service center, Oracle Payments also works to efficiently support the shared service center model.
Oracle Payments' flexibility also provides support to companies that wish to use a payment factory model. A payment factory allows operating units to maintain their own accounts payable and other payment administrative functions. The role of the payment factory is to handle communication and transactions with the deploying company's banking partners. Invoice selection can be done in Oracle Payables within a single operating unit. Then a payment factory administrator using Oracle Payments can consolidate payments from different operating units into a single payment file for transmission and settlement, thereby reducing transaction costs.
Oracle Payments supports Multi-Org Access Control throughout its processes to build payments and create payment files, as well as in the dashboard pages, which are provided for you to monitor and manage the payment process. Multi-Org Access Control enables you to efficiently process business transactions by processing and reporting on data that resides in an unlimited number of operating units, within a single applications responsibility. Data security is maintained using security profiles, which are defined for a list of operating units and data access privileges."
Payments
functionality that is common to both the Funds Capture and the Funds
Disbursements sides of Oracle Payments is the following:
- access control
- APIs
- servlets
- transmission
- security
Understanding Access Control
Access control is an Oracle Payments feature that enables you to control user access in viewing and/or updating data. It is primarily used to secure transaction data and is controlled by the user's security profile. Access control in Oracle Payments that is controlled by permissions on multiple organizations is known as "Multiple Organization Access Control" (MOAC). MOAC is setup using profiles in Oracle HRMS (Human Resource Management System), where you specify an organization or a hierarchy of organizations to which the user has access. The profile is then assigned to the user, responsibility, or other level.
Access control is an Oracle Payments feature that enables you to control user access in viewing and/or updating data. It is primarily used to secure transaction data and is controlled by the user's security profile. Access control in Oracle Payments that is controlled by permissions on multiple organizations is known as "Multiple Organization Access Control" (MOAC). MOAC is setup using profiles in Oracle HRMS (Human Resource Management System), where you specify an organization or a hierarchy of organizations to which the user has access. The profile is then assigned to the user, responsibility, or other level.
Overview
Companies model their business units in various ways to maximize performance and cost savings. Oracle Payments can be configured to support a variety of payment models. It can work in a completely decentralized model, where each organization within the company handles its own financial activities. Alternatively, if a company decides to centralize its financial activities in a shared service center, Oracle Payments can efficiently support the shared service center model also.
Additionally, Oracle Payments provides support to companies that wish to use the payment factory model. The payment factory model enables operating units to maintain their own accounts payable and other payment administrative functions. The payment factory handles communication and transactions with the deploying company's banking partners. Invoice selection occurs in Oracle Payables within a single operating unit. Then a payment factory administrator uses Oracle Payments to consolidate payments from different operating units into a single payment file for transmission and settlement, thereby reducing transaction costs.
Payment Function
A payment function is the type of payment made or captured by a source product. Each document payable has a payment function. For example, Oracle Payables supports the payment functions of making payments to suppliers and others. Different applications have different payment functions. In Oracle Payments, you can limit users to certain payment functions.
Multi-Organization Access Control (MOAC)
Oracle Payments supports Multi-Organization Access Control (MOAC). MOAC is a subfeature of Access Control that enables you to define multiple organizations and the relationships among them within a single installation of Oracle Applications. These
organizations can be operating units, business groups, legal entities, sets of books, or inventory organizations.
The primary advantage of MOAC is that you can take action on documents in different operating units without logging into different responsibilities. Data security is maintained using security profiles that are defined for a list of operating units for which specific users are given data access privileges.
Access Control in Read-Only Pages
In read-only pages, you can only view documents or payments for which you have access. That is, the data you see displayed is that to which you have access. Conversely, you are unable to view documents or payments that belong to an organization or payment function to which you do not have access. However, payment process requests, payment instructions, and funds settlement batches can contain data from multiple organizations and are not organization-specific. In these cases, if you have access to an organization that owns data in the request, instruction, or settlement batch, you will be able to see them. But within that request, instruction, or settlement batch, you will only be able to see the transaction data owned by the organizations to which you have access.
Access Control in Action Pages
Action pages are those pages where you take any kind of action on documents payable, payments, payment process requests, payment instructions, funds settlement transactions, or settlement batches. This includes printing checks, correcting validation errors, or taking other actions in the Funds Capture and Funds Disbursement Dashboards. You can only act on an entity if you have access to everything within the entity.
For example, if a payment instruction includes payments for Organization 1 and Organization 2, and you only have access to Organization 1, you will be unable to go to any action page for the payment instruction. That is, if you only have partial access to the data in an object, you are unable to access that object. In this event, a message indicating that you do not have full access to the object is shown.
Access Control in Disbursement System Options Setup Page
In the Disbursement System Options setup page, you can view and update organization-level system options only for those organizations to which you have access. Oracle Payments restricts what you can see and update, in that you only see that for which you have access.
Access Control in all Other Setup Pages
In all other setup pages, Oracle Payments does not restrict you from what you can see and update, regardless of access control.
Access Control in Payment Process Concurrent Programs
The following concurrent programs are restricted by your access to organizations:
Companies model their business units in various ways to maximize performance and cost savings. Oracle Payments can be configured to support a variety of payment models. It can work in a completely decentralized model, where each organization within the company handles its own financial activities. Alternatively, if a company decides to centralize its financial activities in a shared service center, Oracle Payments can efficiently support the shared service center model also.
Additionally, Oracle Payments provides support to companies that wish to use the payment factory model. The payment factory model enables operating units to maintain their own accounts payable and other payment administrative functions. The payment factory handles communication and transactions with the deploying company's banking partners. Invoice selection occurs in Oracle Payables within a single operating unit. Then a payment factory administrator uses Oracle Payments to consolidate payments from different operating units into a single payment file for transmission and settlement, thereby reducing transaction costs.
Payment Function
A payment function is the type of payment made or captured by a source product. Each document payable has a payment function. For example, Oracle Payables supports the payment functions of making payments to suppliers and others. Different applications have different payment functions. In Oracle Payments, you can limit users to certain payment functions.
Multi-Organization Access Control (MOAC)
Oracle Payments supports Multi-Organization Access Control (MOAC). MOAC is a subfeature of Access Control that enables you to define multiple organizations and the relationships among them within a single installation of Oracle Applications. These
organizations can be operating units, business groups, legal entities, sets of books, or inventory organizations.
The primary advantage of MOAC is that you can take action on documents in different operating units without logging into different responsibilities. Data security is maintained using security profiles that are defined for a list of operating units for which specific users are given data access privileges.
Access Control in Read-Only Pages
In read-only pages, you can only view documents or payments for which you have access. That is, the data you see displayed is that to which you have access. Conversely, you are unable to view documents or payments that belong to an organization or payment function to which you do not have access. However, payment process requests, payment instructions, and funds settlement batches can contain data from multiple organizations and are not organization-specific. In these cases, if you have access to an organization that owns data in the request, instruction, or settlement batch, you will be able to see them. But within that request, instruction, or settlement batch, you will only be able to see the transaction data owned by the organizations to which you have access.
Access Control in Action Pages
Action pages are those pages where you take any kind of action on documents payable, payments, payment process requests, payment instructions, funds settlement transactions, or settlement batches. This includes printing checks, correcting validation errors, or taking other actions in the Funds Capture and Funds Disbursement Dashboards. You can only act on an entity if you have access to everything within the entity.
For example, if a payment instruction includes payments for Organization 1 and Organization 2, and you only have access to Organization 1, you will be unable to go to any action page for the payment instruction. That is, if you only have partial access to the data in an object, you are unable to access that object. In this event, a message indicating that you do not have full access to the object is shown.
Access Control in Disbursement System Options Setup Page
In the Disbursement System Options setup page, you can view and update organization-level system options only for those organizations to which you have access. Oracle Payments restricts what you can see and update, in that you only see that for which you have access.
Access Control in all Other Setup Pages
In all other setup pages, Oracle Payments does not restrict you from what you can see and update, regardless of access control.
Access Control in Payment Process Concurrent Programs
The following concurrent programs are restricted by your access to organizations:
Create Payment Instructions: Funds Disbursement. The program will only pick up those payments for which you have permission to take action.
Create Settlement Batches: Funds Capture. The program will only pick up those transactions for which you have permission.
Create Settlement Batches: Funds Capture. The program will only pick up those transactions for which you have permission.
Understanding Oracle Payments APIs
Oracle Payments provides two types of APIs to simplify the integration of existing or new applications with Oracle Payments for payment processing.
Oracle Applications APIs:
Oracle Applications use these APIs to integrate with Oracle Payments
for funds capture and funds disbursement. These are internal to Oracle
Applications.
Electronic Commerce APIs: Third-party applications can use these APIs to integrate their applications with Oracle Payments for funds settlement transactions. The third-party application can be a stand-alone application that communicates with Oracle Payments via Java APIs or PL/SQL APIs.
Payment System Integration: You can integrate with payment systems by creating or updating XML Publisher templates, transmission configurations, and payment system servlets. The templates are used to translate payment data into a payment system's format. Transmission configurations contain the details of transmission to payment systems and servlets manage the actual transmission process. Oracle Payments provides the Payment System Integration Model to interface with payment gateways and payment processors.
Electronic Commerce APIs: Third-party applications can use these APIs to integrate their applications with Oracle Payments for funds settlement transactions. The third-party application can be a stand-alone application that communicates with Oracle Payments via Java APIs or PL/SQL APIs.
Payment System Integration: You can integrate with payment systems by creating or updating XML Publisher templates, transmission configurations, and payment system servlets. The templates are used to translate payment data into a payment system's format. Transmission configurations contain the details of transmission to payment systems and servlets manage the actual transmission process. Oracle Payments provides the Payment System Integration Model to interface with payment gateways and payment processors.
Understanding Oracle Payments Servlets
Oracle Payments consists of the following servlets:
Oracle Payments consists of the following servlets:
- ECServlet
The
ECServlet provides an interface to the Oracle Payments engine to
process payment-related funds capture operations such as authorization.
This servlet is primarily used for the PL/SQL APIs provided by Oracle
Payments.
- Payment system servlets
Payment
system servlets take payment files, as formatted by Oracle Payments,
and transmit them to payment systems according to transmission
configurations set up in Oracle Payments. Oracle Payments bundles
payment system servlets developed by Oracle and/or interfaces with
servlets developed by its payment system partners. The payment systems
communicate with the payment acquirers or banks to process payment
transactions. Oracle Payments includes payment system servlets for
Paymentech, First Data (North), and Concord EFSnet. Some payment
systems, such as
VeriSign, have built their own Oracle Payment servlets.
VeriSign, have built their own Oracle Payment servlets.
- Field-installable servlets
Oracle
Payment supports field-installable servlets. These payment system
servlets are not bundled with Oracle Payments. This feature allows a
payee to acquire a new, additional, or upgraded payment system servlet
and configure it in the same way as the payment system servlets bundled
with Oracle Payments. The ability to add field-installable servlets
provides payment flexibility and allows new releases of Oracle Payments
and the payment systems to be independent of each other. It also
enables users of source products to customize the payment system for
their specific needs and regions.
Field-installable payment system servlets for Oracle Payments are available from Oracle's payment system partners, or can be custom built.
Field-installable payment system servlets for Oracle Payments are available from Oracle's payment system partners, or can be custom built.
Understanding Transmission
To transmit data to or from a payment system, you need a transmission protocol and a transmission configuration. First, you must have a transmission protocol, which defines the method of transmission. Transmission configurations, which specify concrete transmission details, must be associated with one transmission protocol.
To illustrate, Oracle Payments supports a generic transmission protocol for flat files called File Transfer Protocol for Static File Names. This protocol is a generic method to electronically transmit data, whereas FTP to Paymentech is a specific transmission configuration that specifies how to transmit data to a specific location using FTP as the method.
On the funds capture side, the transmission protocol and configuration are associated with the funds capture process profile, whereas on the funds disbursement side, the transmission configuration is associated with the payment process profile.
Transmission Protocol
Oracle Payments seeds transmission protocols, which are used by all funds capture process profiles and may be used by payment process profiles. These common seeded protocols, such as FTP, are comprised of the following:
Oracle Payments seeds transmission protocols, which are used by all funds capture process profiles and may be used by payment process profiles. These common seeded protocols, such as FTP, are comprised of the following:
- a code entry point, which the payment system servlet uses to accomplish transmission
- a list of parameters, such as network address and port, for which the transmission configuration must supply values
- transmission protocol entry points, which are independent of payment servlets and may be invoked from the Oracle Payments engine
You can view the seeded transmission protocols in Oracle Payments setup pages.
Transmission Configuration
Each transmission protocol has parameters that require values. The values defined for the parameters comprise the transmission configuration for the transmission protocol.
For example, the payment system, Paymentech, may require a Socket IP Address of X and a Socket Port number of Y, among other values. Together XY, and the other values, represent Transmission Configuration A for a given transmission protocol.
Transmission Configuration
Each transmission protocol has parameters that require values. The values defined for the parameters comprise the transmission configuration for the transmission protocol.
For example, the payment system, Paymentech, may require a Socket IP Address of X and a Socket Port number of Y, among other values. Together XY, and the other values, represent Transmission Configuration A for a given transmission protocol.
Understanding Oracle Payments Security
Oracle Payments stores and processes highly sensitive financial data. To ensure proper security of this data, the Oracle Payments has advanced security features. Oracle Payments has several features to ensure the security and privacy of your data.
This section explains the security features of Oracle Payments and describes the setup required to properly utilize these features.
Multiple Organization Access Control
MOAC (Multi-Organization Access Control) is part of the Oracle Payments security feature. For information on MOAC, see Multi-Organization Access Control (MOAC) [above].
Payment Instrument Encryption
Payment Instrument Encryption is an advanced Oracle Payments security feature that enables Oracle Applications to encrypt credit card data. This feature assists with your compliance with the cardholder data protection requirements of the Payment Card Industry (PCI) Data Security Standard and with Visa's Cardholder Information Security Program (CISP). The Visa program is based on the PCI Data Security Standard. When the feature is enabled, credit card and bank account numbers for external third parties, such as customers, suppliers, or students are encrypted.
MOAC (Multi-Organization Access Control) is part of the Oracle Payments security feature. For information on MOAC, see Multi-Organization Access Control (MOAC) [above].
Payment Instrument Encryption
Payment Instrument Encryption is an advanced Oracle Payments security feature that enables Oracle Applications to encrypt credit card data. This feature assists with your compliance with the cardholder data protection requirements of the Payment Card Industry (PCI) Data Security Standard and with Visa's Cardholder Information Security Program (CISP). The Visa program is based on the PCI Data Security Standard. When the feature is enabled, credit card and bank account numbers for external third parties, such as customers, suppliers, or students are encrypted.
Note: Other products such as iExpenses do store internal credit card numbers in Oracle Payments' tables.
Adoption
of the Payment Instrument Encryption feature should be part of the
implementation of a complete security policy, which is specific to your
organization.
For
example, your security policy should include a regular schedule to
rotate keys to secure your payment instrument data. For general
guidelines on securing Oracle E-Business Suite applications products,
see the Oracle My Oracle Support Note 189367.1: Best Practices for Securing Oracle E-Business Suite.
Oracle Payments Engine to Oracle Payments Servlet Communication
Oracle Payments architecture lets you install the payment system servlet in a machine outside the firewall. If you have installed either Oracle Payments (or its components) or the source product in a distributed environment, Oracle recommends configuring SSL between Oracle Payments and the payment system components. You can create an Oracle Wallet to store certificates and credential information to support authentication of the engine, in this case a client of the servlet, by the server running the servlet. You can specify the wallet location and password using FND profiles. You can configure the server where the servlet is running to request client certificates (on the engine side).
Oracle Payments retrieves the certificates from the Oracle Wallet and sends the certificates to the server for authentication. Oracle Payments also supports basic authentication of the payment system by the servlet.
These security features are recommended to guard against unauthorized access to data and Oracle Payments services. Oracle iAS web server (Apache Server) provides several types of authentication that you can use to secure servers, listeners, and servlets.
Firewall Protection
Oracle strongly recommends that you install Oracle Payments and the payment system servlets on a machine inside the firewall.
Secure Socket Layer
If either Oracle Payments (or its components) or the source product is installed in a distributed environment, Oracle recommends enabling SSL communication between Oracle Payments and the payment system components.
Basic Authentication for Payment Systems
For setting up security for basic authentication between Oracle Payments and payment system servlets, you must perform some tasks both in the Oracle Payments setup user interface and in the Apache Server administration tool. While configuring Oracle Payments for a particular payment system, you must assign the payment system user name and password in the payment system configuration screens. You must assign the same user name and password in the Apache Server that runs the payment system
servlets.
For details on setting up basic authentication in Apache Server, see the Apache Server documentation.
IP Address Restriction
In addition to using the merchant user name and password, you can restrict access to Oracle Payments and payment systems through IP address restriction. By using IP address restriction, a feature of the Apache Server, you can specify one or both of the
following parameters:
Oracle Payments architecture lets you install the payment system servlet in a machine outside the firewall. If you have installed either Oracle Payments (or its components) or the source product in a distributed environment, Oracle recommends configuring SSL between Oracle Payments and the payment system components. You can create an Oracle Wallet to store certificates and credential information to support authentication of the engine, in this case a client of the servlet, by the server running the servlet. You can specify the wallet location and password using FND profiles. You can configure the server where the servlet is running to request client certificates (on the engine side).
Oracle Payments retrieves the certificates from the Oracle Wallet and sends the certificates to the server for authentication. Oracle Payments also supports basic authentication of the payment system by the servlet.
These security features are recommended to guard against unauthorized access to data and Oracle Payments services. Oracle iAS web server (Apache Server) provides several types of authentication that you can use to secure servers, listeners, and servlets.
Firewall Protection
Oracle strongly recommends that you install Oracle Payments and the payment system servlets on a machine inside the firewall.
Secure Socket Layer
If either Oracle Payments (or its components) or the source product is installed in a distributed environment, Oracle recommends enabling SSL communication between Oracle Payments and the payment system components.
Basic Authentication for Payment Systems
For setting up security for basic authentication between Oracle Payments and payment system servlets, you must perform some tasks both in the Oracle Payments setup user interface and in the Apache Server administration tool. While configuring Oracle Payments for a particular payment system, you must assign the payment system user name and password in the payment system configuration screens. You must assign the same user name and password in the Apache Server that runs the payment system
servlets.
For details on setting up basic authentication in Apache Server, see the Apache Server documentation.
IP Address Restriction
In addition to using the merchant user name and password, you can restrict access to Oracle Payments and payment systems through IP address restriction. By using IP address restriction, a feature of the Apache Server, you can specify one or both of the
following parameters:
- The IP addresses of all trusted hosts (machines from which the web server should accept transaction requests for Oracle Payments)
- The IP addresses of some non-trusted hosts (machines from which the web server should refuse transaction requests for Oracle Payments)
If
a request is from a machine on the trusted list, Oracle Payments
processes the requested transaction. If the request is from a machine on
the non-trusted list, Apache Server denies the request and prevents
Oracle Payments from processing it.
Through IP address restriction, you can limit access to all operations from non-trusted machines.
For more information about IP address restriction, including how to specify trusted hosts, see Apache Server documentation.
Other Security Related Information
Through IP address restriction, you can limit access to all operations from non-trusted machines.
For more information about IP address restriction, including how to specify trusted hosts, see Apache Server documentation.
Other Security Related Information
- Separate HTTP ports for site administration and Oracle Payments administration increases security.
Funds Capture Features
Funds
capture features support the process to electronically receive funds
owed deploying companies by debtors, such as customers.
Oracle Payments supports authorization and settlement of funds against
credit cards and PINless debit cards, refunds to credit cards,
electronic funds transfers from bank accounts, and formatting of bills
receivable.
Note: Oracle Receivables retains the functionality of lockbox processing and electronic upload of remittance messages.
Flexible Payment Methods
Businesses and their customers require flexible payment methods when paying for goods and services. Oracle Payments supports credit cards, purchase cards (levels 2 and 3), PINless debit cards, funds capture electronic funds transfers, and the transmission of bills receivable transactions.
Oracle Payments processes credit card validation, authorization, and funds capture.
Credit card validation can be done independently of authorization. This helps the merchant save transaction fees by preempting authorization requests on invalid credit cards. Oracle Payments also processes funds capture for credit card transactions that have been manually authorized over the telephone, which is a requirement for certain businesses.
Oracle Payment's support for funds capture electronic fund transfers (EFT) and bills receivable transmissions enables you to eliminate paper-based transactions, thus reducing administrative manual processing and errors. You will also receive funds faster with EFT than with traditional paper checks.
PINless Debit Card Transactions
Oracle Payments supports PINless debit card funds capture transactions. Sometimes referred to as Debit Bill Pay, this payment method is allowed by the debit networks in certain industries, including utilities, telecom, cable/satellite, government, education, and financial services.
Direct Debits
Online validation for electronic funds transfers is supported by Oracle Payments through APIs. The validation service is provided by some payment systems to perform validity checks on the payer bank account to be debited. Typically this service verifies that the bank account number is valid and not cited for fraudulent payment activity.
Oracle Payments extends its support of electronic funds transfer by adding third party certifications for Paymentech and Concord EFSnet.
Credit Card Security Features
Credit Card Encryption is an advanced security feature within Oracle Payments that enables Oracle Applications to encrypt credit card data. You can access this credit card security feature setup easily by selecting the Oracle Payments Payment Administrator responsibility and then clicking the System Security Management link. Oracle Payments consolidates the varying levels of credit card security support within different products of the Oracle E-Business Suite so that setup and management of address verifications, capture of card security codes, and masking of credit card numbers, ensures a
consistent implementation of credit card security functions throughout the funds capture process.
Note: Any internal credit card numbers, such as company-owned or employee credit cards, are not impacted by the Credit Card Encryption feature.
Businesses and their customers require flexible payment methods when paying for goods and services. Oracle Payments supports credit cards, purchase cards (levels 2 and 3), PINless debit cards, funds capture electronic funds transfers, and the transmission of bills receivable transactions.
Oracle Payments processes credit card validation, authorization, and funds capture.
Credit card validation can be done independently of authorization. This helps the merchant save transaction fees by preempting authorization requests on invalid credit cards. Oracle Payments also processes funds capture for credit card transactions that have been manually authorized over the telephone, which is a requirement for certain businesses.
Oracle Payment's support for funds capture electronic fund transfers (EFT) and bills receivable transmissions enables you to eliminate paper-based transactions, thus reducing administrative manual processing and errors. You will also receive funds faster with EFT than with traditional paper checks.
PINless Debit Card Transactions
Oracle Payments supports PINless debit card funds capture transactions. Sometimes referred to as Debit Bill Pay, this payment method is allowed by the debit networks in certain industries, including utilities, telecom, cable/satellite, government, education, and financial services.
Direct Debits
Online validation for electronic funds transfers is supported by Oracle Payments through APIs. The validation service is provided by some payment systems to perform validity checks on the payer bank account to be debited. Typically this service verifies that the bank account number is valid and not cited for fraudulent payment activity.
Oracle Payments extends its support of electronic funds transfer by adding third party certifications for Paymentech and Concord EFSnet.
Credit Card Security Features
Credit Card Encryption is an advanced security feature within Oracle Payments that enables Oracle Applications to encrypt credit card data. You can access this credit card security feature setup easily by selecting the Oracle Payments Payment Administrator responsibility and then clicking the System Security Management link. Oracle Payments consolidates the varying levels of credit card security support within different products of the Oracle E-Business Suite so that setup and management of address verifications, capture of card security codes, and masking of credit card numbers, ensures a
consistent implementation of credit card security functions throughout the funds capture process.
Note: Any internal credit card numbers, such as company-owned or employee credit cards, are not impacted by the Credit Card Encryption feature.
Encryption
Use of the Credit Card Encryption feature assists with your compliance with the cardholder data protection requirements of the Payment Card Industry (PCI) Data Security Standard and with Visa's Cardholder Information Security Program (CISP). The Visa program is based on the PCI Data Security Standard. When the feature is enabled, credit card numbers for external third party payers, such as customers or students, are encrypted.
Masking
When Credit Card Encryption is enabled, masking functionality differs between Oracle Applications. For example, in Oracle Receivables and Oracle Service Contracts, when Credit Card Encryption is enabled, credit card numbers are masked in the following format with the last four digits displayed: XXXXXXXXXXXX1234, whereas, in Oracle Order Management, a changed profile option no longer controls masking of credit card numbers.
Your Company's Security Policy
Adoption of the Credit Card Encryption feature should be part of the implementation of a complete security policy, specific to your organization. For example, your security policy should include a regular schedule to rotate keys to secure your credit card data.
For general guidelines on securing Oracle E-Business Suite applications products, see My Oracle Support Note 189367.1: Best Practices for Securing Oracle E-Business Suite, .
Use of the Credit Card Encryption feature assists with your compliance with the cardholder data protection requirements of the Payment Card Industry (PCI) Data Security Standard and with Visa's Cardholder Information Security Program (CISP). The Visa program is based on the PCI Data Security Standard. When the feature is enabled, credit card numbers for external third party payers, such as customers or students, are encrypted.
Masking
When Credit Card Encryption is enabled, masking functionality differs between Oracle Applications. For example, in Oracle Receivables and Oracle Service Contracts, when Credit Card Encryption is enabled, credit card numbers are masked in the following format with the last four digits displayed: XXXXXXXXXXXX1234, whereas, in Oracle Order Management, a changed profile option no longer controls masking of credit card numbers.
Your Company's Security Policy
Adoption of the Credit Card Encryption feature should be part of the implementation of a complete security policy, specific to your organization. For example, your security policy should include a regular schedule to rotate keys to secure your credit card data.
For general guidelines on securing Oracle E-Business Suite applications products, see My Oracle Support Note 189367.1: Best Practices for Securing Oracle E-Business Suite, .
Supports Both Processor and Gateway Model Payment Systems
Oracle Payments support for both processor and gateway models enables customers to choose the payment processing options that suit their business.
Processor and gateway model payment systems can be integrated with Oracle Payments for credit cards, PINless debit cards, and bank account transfers, using the product's format and transmission model. Oracle Payments payment system integration model has extensible fields that can be used in a custom implementation with payment systems that require additional information. This extensibility can be particularly useful for international implementations of Oracle Payments.
In addition, Oracle Payments supports out-of-the-box integration with leading third party payment systems. These payment systems include Paymentech, First Data Merchant Services, and Concord EFS. Other payment systems, such as Verisign, offer their own out-of-the-box integrations with Oracle Payments.
Routing to Multiple Payment Systems for Funds Capture
Oracle Payments supports multiple payment processing systems operating simultaneously for funds capture transactions and provides a powerful routing system that gives businesses and merchants control over funds capture transaction processing.
Payment requests are routed to payment processing systems based on flexible business rules defined by the merchant. For example, you can route payment transactions based on the type of transaction or amount of payment
Centralized Configuration
Oracle Payments offers a centralized, configurable funds capture processing setup. This ensures an implementation that supports consistent and seamless funds capture processing. The configurable funds capture processing setup can be grouped into the following areas:
Payee Configuration:
A payee is defined for one or more operating units in the deploying
company that processes payments. The payee setup provides various
options for payment processing and links operating units to the payee.
Routing Rules Configuration: Routing rules can be configured to specify how a transaction is processed. For example, this setup determines the payment system to which a transaction is sent.
Funds Capture Processing Rules Configuration: Oracle Payments holds funds capture processing rules in an entity called the Funds Capture Process Profile. You can configure as many funds capture process profiles as you need for your payment processes. Each profile contains the configuration for formatting and transmitting authorization messages and settlement files. Additionally, specifying rules for aggregating settlements into batches, limiting the number or amount of settlements in a batch, notifying payers of settlements, and processing acknowledgements can be easily configured.
Routing Rules Configuration: Routing rules can be configured to specify how a transaction is processed. For example, this setup determines the payment system to which a transaction is sent.
Funds Capture Processing Rules Configuration: Oracle Payments holds funds capture processing rules in an entity called the Funds Capture Process Profile. You can configure as many funds capture process profiles as you need for your payment processes. Each profile contains the configuration for formatting and transmitting authorization messages and settlement files. Additionally, specifying rules for aggregating settlements into batches, limiting the number or amount of settlements in a batch, notifying payers of settlements, and processing acknowledgements can be easily configured.
Payment Processing User Interface
Oracle Payments offers a user interface, known as the funds capture dashboard, for managing the funds capture process. The funds capture dashboard provides an overview of the payment process status. This results in greater insight into rejections received from payment systems and into process failures, such as communication errors.
Library of Payment Formats
All payment formats used by E-Business Suite applications for the funds capture process have been consolidated as Oracle XML Publisher templates and are used by Oracle Payments. These formats include Oracle Globalizations' direct debits, bills receivable, and Oracle Receivables' remittance formats.
Scheduled Payments
Oracle Payments processes payment requests when requested or via an offline scheduled process, based on the type of payment request and payment system. A scheduling program enables Oracle Payments to process gateway-bound payments in an offline mode when a source product requests it. When an E-Business application calls Oracle Payments to make an offline payment request, the payment information is stored in Oracle Payments and picked up by the scheduling program so that the payment gets settled by the due date (or settlement date). At the same time, Oracle Payments handles processor-model payment requests as required by most processors:
Oracle Payments offers a user interface, known as the funds capture dashboard, for managing the funds capture process. The funds capture dashboard provides an overview of the payment process status. This results in greater insight into rejections received from payment systems and into process failures, such as communication errors.
Library of Payment Formats
All payment formats used by E-Business Suite applications for the funds capture process have been consolidated as Oracle XML Publisher templates and are used by Oracle Payments. These formats include Oracle Globalizations' direct debits, bills receivable, and Oracle Receivables' remittance formats.
Scheduled Payments
Oracle Payments processes payment requests when requested or via an offline scheduled process, based on the type of payment request and payment system. A scheduling program enables Oracle Payments to process gateway-bound payments in an offline mode when a source product requests it. When an E-Business application calls Oracle Payments to make an offline payment request, the payment information is stored in Oracle Payments and picked up by the scheduling program so that the payment gets settled by the due date (or settlement date). At the same time, Oracle Payments handles processor-model payment requests as required by most processors:
- online requests for authorizations, and
- batched offline requests for follow-up operations
Payer Notifications of Settlement
Oracle Payments has consolidated notification letters from Oracle Globalizations into an Oracle XML Publisher format. These notification letters are generated and sent when a payer's bank account is debited to capture funds for payment. The Oracle XML Publisher format supports notification for all types of automatic funds capture settlements supported by Oracle Payments, including card payments or bank account transfers. The notification process enables you to configure how a notification is to be delivered to a payer: via e-mail, fax, or printing and sending manually. These notifications help deploying companies better support their payment relationships with customers or other payers.
Oracle Payments has consolidated notification letters from Oracle Globalizations into an Oracle XML Publisher format. These notification letters are generated and sent when a payer's bank account is debited to capture funds for payment. The Oracle XML Publisher format supports notification for all types of automatic funds capture settlements supported by Oracle Payments, including card payments or bank account transfers. The notification process enables you to configure how a notification is to be delivered to a payer: via e-mail, fax, or printing and sending manually. These notifications help deploying companies better support their payment relationships with customers or other payers.
Funds Disbursement Features
Oracle Payments' funds disbursement features support the process to pay funds owed to creditors, such as suppliers.
Oracle Payments supports functionality to achieve straight through
processing of electronic funds transfers and the ability to format and
manage check or other payment document printing.
Flexible Disbursement Process
The Oracle Payments disbursement engine enables you to greatly simplify your procedures for managing complex payment processes that span multiple payment methods, formats, check stocks, transmission protocols, currencies, organizations, and bank accounts.
The Oracle Payments funds disbursement process enables users of Oracle Payables and other products to focus on the invoice selection process before submitting the documents payable to Oracle Payments for payment processing. This is achieved by splitting the payment build process into two processes. The first process creates payments by grouping documents according to various rules, such as the payment method and currency. The second process then aggregates payments into payment instruction files, formats the files, and handles additional processing, such as printing and transmission. This aggregation process can be done for payments created from multiple document selections and submissions to Oracle Payments.
With Oracle Payments, accounts payable managers can simplify their processes by submitting fewer invoice selection batches, with each one spanning multiple payment methods, formats, bank accounts, and payment currencies. Invoices can be selected for payment based on business reasons, such as maximizing discounts. Additionally, payment administrators can lower the cost of the disbursement process by creating check runs and EFT payment files that span multiple invoice selection batches and multiple organizations.
Electronic Payment Processing
Oracle Payments offers end-to-end electronic payment processing that includes validation, aggregation, formatting, and secure transmission of payments to financial institutions and payment systems. Straight through processing results in lower costs associated with the disbursement process. The formatting framework, flexible validation model, and electronic transmission capability greatly minimizes any need for writing payment customizations.
Configurability for Funds Disbursement Processing
Oracle Payments offers flexible setup to configure funds disbursement processing. Flexible setup ensures an implementation that best supports a controlled and efficient disbursement flow. Configuration options are available in the following areas:
Flexible Disbursement Process
The Oracle Payments disbursement engine enables you to greatly simplify your procedures for managing complex payment processes that span multiple payment methods, formats, check stocks, transmission protocols, currencies, organizations, and bank accounts.
The Oracle Payments funds disbursement process enables users of Oracle Payables and other products to focus on the invoice selection process before submitting the documents payable to Oracle Payments for payment processing. This is achieved by splitting the payment build process into two processes. The first process creates payments by grouping documents according to various rules, such as the payment method and currency. The second process then aggregates payments into payment instruction files, formats the files, and handles additional processing, such as printing and transmission. This aggregation process can be done for payments created from multiple document selections and submissions to Oracle Payments.
With Oracle Payments, accounts payable managers can simplify their processes by submitting fewer invoice selection batches, with each one spanning multiple payment methods, formats, bank accounts, and payment currencies. Invoices can be selected for payment based on business reasons, such as maximizing discounts. Additionally, payment administrators can lower the cost of the disbursement process by creating check runs and EFT payment files that span multiple invoice selection batches and multiple organizations.
Electronic Payment Processing
Oracle Payments offers end-to-end electronic payment processing that includes validation, aggregation, formatting, and secure transmission of payments to financial institutions and payment systems. Straight through processing results in lower costs associated with the disbursement process. The formatting framework, flexible validation model, and electronic transmission capability greatly minimizes any need for writing payment customizations.
Configurability for Funds Disbursement Processing
Oracle Payments offers flexible setup to configure funds disbursement processing. Flexible setup ensures an implementation that best supports a controlled and efficient disbursement flow. Configuration options are available in the following areas:
Payment Methods:
Each document to be paid, such as an invoice, requires the
specification of a payment method to indicate how it will be handled in
the funds disbursement process. Payment methods can be defined as
broadly or as narrowly as appropriate. Rules can be defined to specify
when payment methods can be used on documents and how to default payment
methods on documents when they are created.
Processing Rules: The payment method on a document is linked to user-defined funds disbursement processing rules configured in Oracle Payments. Oracle Payments holds these funds disbursement processing rules in an entity called the Payment Process Profile. You can configure as many payment process profiles as you need for your payment processes. Each payment process profile contains rules for building documents into payments, aggregating payments into payment instruction files, and formatting payment instruction files. Processing rules for printing checks, transmitting electronic files, generating separate remittance advice notifications, and other options can be easily configured.
Processing Rules: The payment method on a document is linked to user-defined funds disbursement processing rules configured in Oracle Payments. Oracle Payments holds these funds disbursement processing rules in an entity called the Payment Process Profile. You can configure as many payment process profiles as you need for your payment processes. Each payment process profile contains rules for building documents into payments, aggregating payments into payment instruction files, and formatting payment instruction files. Processing rules for printing checks, transmitting electronic files, generating separate remittance advice notifications, and other options can be easily configured.
Payment Processing User Interface [Form]
Oracle Payments provides a funds disbursement dashboard for managing the funds disbursement process. The funds disbursement dashboard allows payment administrators to manage every aspect of the process across multiple organizations from a central location in the application. This benefits companies by providing full visibility of a payment as it moves through the financial supply chain. Additionally, the single location for monitoring the payment process also helps streamline process management.
Payment administrators can use the funds disbursement dashboard to monitor the payment process and ensure that it is running smoothly. If any problems arise during the process, they are highlighted in a pending actions region. This is also the place where notification of any required actions is shown. Actions may be required based on the configuration choices made during implementation. The funds disbursement dashboard enables the payment administrator to navigate to the appropriate area to take corrective or required action, based on the pending issue selected.
Payment administrators can take the following actions from the funds disbursement dashboard:
Oracle Payments provides a funds disbursement dashboard for managing the funds disbursement process. The funds disbursement dashboard allows payment administrators to manage every aspect of the process across multiple organizations from a central location in the application. This benefits companies by providing full visibility of a payment as it moves through the financial supply chain. Additionally, the single location for monitoring the payment process also helps streamline process management.
Payment administrators can use the funds disbursement dashboard to monitor the payment process and ensure that it is running smoothly. If any problems arise during the process, they are highlighted in a pending actions region. This is also the place where notification of any required actions is shown. Actions may be required based on the configuration choices made during implementation. The funds disbursement dashboard enables the payment administrator to navigate to the appropriate area to take corrective or required action, based on the pending issue selected.
Payment administrators can take the following actions from the funds disbursement dashboard:
- review validation errors
- review and optionally modify proposed payments
- transmit payment files or retry failed file transmission processes
- initiate check printing and record printing results
User-Friendly Check Printing Process
Oracle Payments enables you to easily initiate check printing, recover from printing errors, and record print results.
In Oracle Cash Management, check stock can be set up as prenumbered or numbering can be printed as part of the check format, which is common for blank checks. Oracle Payments uses this setup to present the payment administrator with the appropriate print actions for different check stock types. The funds disbursement dashboard guides the payment administrator to each printing action that can be performed.
Global Features in Oracle Payments
Oracle Payments provides country-specific payment features. These global features are available in all deployments of Oracle Payments without any limitation by geography, while still enabling you to configure processing by region, where appropriate.
Most of the global payment features support the funds disbursement process. For example, Oracle Payments enable you to:
Oracle Payments enables you to easily initiate check printing, recover from printing errors, and record print results.
In Oracle Cash Management, check stock can be set up as prenumbered or numbering can be printed as part of the check format, which is common for blank checks. Oracle Payments uses this setup to present the payment administrator with the appropriate print actions for different check stock types. The funds disbursement dashboard guides the payment administrator to each printing action that can be performed.
Global Features in Oracle Payments
Oracle Payments provides country-specific payment features. These global features are available in all deployments of Oracle Payments without any limitation by geography, while still enabling you to configure processing by region, where appropriate.
Most of the global payment features support the funds disbursement process. For example, Oracle Payments enable you to:
- provide payment-level text messages for the payee
- conditionally report payments to a country central bank
- specify payment codes required by a financial institution for instructions on transaction handling, payers of bank charges, and statutory payment reasons
- configure the payment process to place formatted payment files in secure file directories
Library of Payment Formats
All payment formats used by Oracle E-Business Suite applications for the funds disbursement process have been consolidated as Oracle XML Publisher templates and are used by Oracle Payments. These formats include all those previously supported in Oracle Payables, Oracle U.S. Federal Financials, and Oracle Global Financials.
The following industry standard payment formats are supported for use by all products that integrate with Oracle Payments:
All payment formats used by Oracle E-Business Suite applications for the funds disbursement process have been consolidated as Oracle XML Publisher templates and are used by Oracle Payments. These formats include all those previously supported in Oracle Payables, Oracle U.S. Federal Financials, and Oracle Global Financials.
The following industry standard payment formats are supported for use by all products that integrate with Oracle Payments:
- EDIFACT PAYMUL
- ANSI X12 820
- U.S. NACHA
Remittance Advice Reporting
Oracle Payments supports remittance advice reporting and notifying a payee of the remittance detail when a payment is made. The notification process enables you to set conditions for producing remittance advice. Configuration is also supported to set how the remittance advice is to be delivered to a payee: via e-mail, fax, or printing and sending manually. All of these features enable you to better support your payment relationships with suppliers or other payees.
Oracle Payments supports remittance advice reporting and notifying a payee of the remittance detail when a payment is made. The notification process enables you to set conditions for producing remittance advice. Configuration is also supported to set how the remittance advice is to be delivered to a payee: via e-mail, fax, or printing and sending manually. All of these features enable you to better support your payment relationships with suppliers or other payees.
No comments:
Post a Comment