<!doctypehtml><html class=no-js lang=en><meta charset=utf-8><title>
   Oracle Payments User's Guide
  </title><meta content=IE=edge http-equiv=X-UA-Compatible><meta content=width=device-width,initial-scale=1.0,maximum-scale=1 name=viewport><meta content=all name=robots><meta content="Oracle® Payments User's Guide"name=dcterms.title><meta content=E13415-04 name=dcterms.identifier><meta content=IBYUG name=dcterms.isVersionOf><meta content=E18727-01 name=partno><link href=../../index.htm rel=Start title=Home type=text/html><link href=../../dcommon/html/cpyr.htm rel=Copyright title=Copyright type=text/html><script src=../../dcommon/js/headfoot.js></script><script src=../../nav/js/doccd.js></script><link href=toc.htm rel=Contents title=Contents type=text/html><link href=T456136T456138.htm rel=Prev title=Previous type=text/html><link href=T456136T484669.htm rel=Next title=Next type=text/html><link href=http://purl.org/dc/terms/ rel=schema.dcterms><link href=../../dcommon/css/fusiondoc.css rel=stylesheet><link href=../../dcommon/css/header.css rel=stylesheet><link href=../../dcommon/css/footer.css rel=stylesheet><link href=../../dcommon/css/fonts.css rel=stylesheet><link href=../../dcommon/css/foundation.css rel=stylesheet><link href=../../dcommon/css/codemirror.css rel=stylesheet><link href=../../nav/css/html5.css rel=stylesheet title=Default><link href=../../dcommon/css/respond-480-tablet.css rel=stylesheet><link href=../../dcommon/css/respond-768-laptop.css rel=stylesheet><link href=../../dcommon/css/respond-1140-deskop.css rel=stylesheet><script src=../../dcommon/js/modernizr.js></script><script src=../../dcommon/js/codemirror.js></script><script src=../../dcommon/js/jquery.js></script><script src=../../dcommon/js/foundation.min.js></script><script src=//s7.addthis.com/js/300/addthis_widget.js#pubid=ra-53addf516e0e58a5></script><script src=../../dcommon/js/jqfns.js></script><script src=../../dcommon/js/ohc-inline-videos.js></script><script>window.ohcglobal || document.write('<script src="/en/dcommon/js/global.js">\x3C/script>')</script><body><a class="accessibility-top skipto"href=#BEGIN tabindex=0> Go to main content </a><header></header><div class=row id=CONTENT><div class="IND large-9 medium-8 columns"><a id=BEGIN name=BEGIN> </a><span id=PAGE style=display:none;> 5/11 </span><h1>Understanding Oracle Payments</h1><h2><a name=4142490> </a> <a id=T456143> </a> <b> Overview of Oracle Payments <a id=ibyunstibyovervu name=ibyunstibyovervu> </a> </b></h2><p><a id=d0e685 name=d0e685> </a> <a id=d0e690 name=d0e690> </a> <a id=ibyunderpayments name=ibyunderpayments> </a> Oracle Payments is a product in the Oracle E-Business Suite of applications, which serves as a funds capture and funds disbursement engine for other Oracle applications. 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.<p>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.<p>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 as suppliers.<p>Oracle Payments supports the following types of electronic payments for funds capture payments:<ul><li><p>credit cards</p><li><p>purchase cards</p><li><p>PINless debit cards</p><li><p>bank account transfers</p></ul><p>Oracle Payments supports several payment methods for funds disbursement payments, including:<ul><li><p>checks</p><li><p>wires</p><li><p>electronic funds transfers</p></ul><h2><a name=4142491> </a> <a id=T456144> </a> <b> Understanding Funds Capture <a id=ibyunstibyfc name=ibyunstibyfc> </a> </b></h2><p><a id=d0e735 name=d0e735> </a> <a id=d0e740 name=d0e740> </a> This section presents functionality and terms that are relevant to the funds capture process.<h2><a name=4142492> </a> <a id=T456145> </a> <b> Understanding Payment Methods (Funds Capture) <a id=ibyunstibypaymmeths name=ibyunstibypaymmeths> </a> </b></h2><p><a id=d0e753 name=d0e753> </a> <a id=d0e758 name=d0e758> </a> On the funds capture side of Oracle Payments, a payment method is the medium by which a third party payer chooses to remit payment to the first party payee. For example, a customer remits payment for a product or service to the deploying company. Oracle Payments supports the following types of payment methods for automated funds capture processing:<ul><li><p>bank account transfers</p><li><p>credit cards</p><li><p>PINless debit cards</p><li><p>bills receivable remittances</p></ul><p>Oracle Payments enables flexible setup of funds capture payment methods as follows:<ul><li><p>You can define unique payment methods for bank account transfers.</p><li><p>Oracle Payments seeds a single payment method for credit card and PINless debit cards.</p></ul><h2><a name=4142493> </a> <a id=T456146> </a> <b> Understanding Offline and Online Payments <a id=ibyunstibyoffonlpayms name=ibyunstibyoffonlpayms> </a> </b></h2><p><a id=d0e793 name=d0e793> </a> <a id=d0e798 name=d0e798> </a> This section includes the following topics:<ul><li><p>Understanding Offline and Online Payments</p><li><p>Online Payment Processing</p><li><p>Offline Payment Processing</p></ul><h3><a id=T456205> </a> <b> Understanding Offline and Online Payments </b></h3><p>Oracle Payments supports two models of payment processing for credit, purchase, and PINless debit cards as follows:<ul><li><p>Online Payment Processing</p><li><p>Offline Payment Processing</p></ul><p>Funds capture bank account transfers always occur offline.<p>The types of operations that you can process online depends on the payment system type you have chosen, gateway or processor model and your operation model, host based or terminal based.<p>For processor model payment systems, authorization operations must be online and settlement operations are offline and batched. For gateway payment systems, both authorization and settlement operations can be online.<h4><a id=T456206> </a> <b> Online Payment Processing <a id=d0e838 name=d0e838> </a> </b></h4><p>Online payment processing is the model in which a transaction is immediately forwarded to the payment system. The results from the payment system are immediately returned to the source product. Online transactions are supported for credit, purchase, and PINless debit cards. Online validation transactions are supported for Electronic Funds Transfer.<h4><a id=T456207> </a> <b> Offline Payment Processing <a id=d0e847 name=d0e847> </a> </b></h4><p>Offline payment processing is the model in which transactions are not immediately forwarded to payment systems. When a source product submits a transaction in a scheduled mode, if the payment is predated, or if the transaction is a settlement destined for a processor model payment system, the payment information is saved in the Oracle Payments database and is sent to the payment system at a later time.<p>The offline method uses concurrent programs that submit offline operations at regular intervals. The programs browse the stored transactions, send transactions to the payment systems, and update the source products. The Submit Offline Operations concurrent program is used to submit individual offline transactions to gateway model payment systems and the Create Settlement Batches concurrent program is used to submit batches of transactions to processor model payment systems.<h2><a name=4142497> </a> <a id=T456147> </a> <b> Understanding Credit Card Transactions <a id=ibyunstibycctrans name=ibyunstibycctrans> </a> <a id=ibycreditcardtrans name=ibycreditcardtrans> </a> </b></h2><p><a id=d0e861 name=d0e861> </a> <a id=d0e866 name=d0e866> </a> Among funds capture payments, Oracle Payments handles credit card, PINless debit card, purchase card, and EFT transactions. This section explains the process flow for a typical credit card transaction.<h3><a id=T456208> </a> <b> Traditional Credit Card Transactions <a id=d0e877 name=d0e877> </a> </b></h3><p>Traditional credit card transaction processing involves a third party payer, a first party payee, an issuing bank, an acquiring bank, a payment processor, and, optionally, a payment gateway. The payment gateway or payment processor that Oracle Payments interacts with directly is called a payment system for simplicity.<p>A credit card transaction consists of two phases: authorization and settlement. A typical flow might occur as follows:<ul><li><p>Authorization</p> <p>The third party payer purchases goods or services and sends credit card information as part of an order or invoice to the first party payee.</p> <p>The first party payee accepts the order and sends an authorization request to the payment processor through Oracle Payments and, optionally, a payment gateway.</p> <p>The payment processor matches the information with a database maintained by the issuing bank to determine if the customer has enough available credit to cover the transaction. If so, then the payment processor reserves the funds and sends back an authorization code.</p><li><p>Settlement</p> <p>The first party payee delivers goods to the customer and needs to settle the transaction, that is, capture the funds reserved in the authorization. Settlement may occur at the same time as authorization. Settling transactions may include batch administration.</p> <p>The first party payee issues capture, void, return, credit, and settlement batch functions to the payment processor through Oracle Payments and optionally, the payment gateway.</p> <p>The payment processor settles the payment with the issuing bank and causes the funds to transfer to the acquiring bank.</p></ul><h3><a id=T456209> </a> <b> Voice Authorization <a id=d0e909 name=d0e909> </a> <a id=d0e914 name=d0e914> </a> </b></h3><p>Sometimes credit card processing networks decline transactions with a referral message indicating that the merchant must call the cardholder's issuing bank to complete the transaction. The payment information in such cases is submitted over the phone. If the transaction is approved, the merchant is provided with an authorization code for the transaction. To facilitate follow-on transactions through Oracle Payments for this voice authorization (for example, capture or void), Oracle Payments provides voice authorization support for gateway model and processor model payment systems.<p>The credit card expiration date is always the last day of the month (that is the reason only the month and year values are sufficient to specify the credit card expiration date). So, even though the card expiration date was specified as 7-Jul-2009, it gets rounded to 31-Jul-2009.<h2><a name=4142500> </a> <a id=T456148> </a> <b> Understanding Purchase Cards <a id=ibyunstibypurcards name=ibyunstibypurcards> </a> </b></h2><p><a id=d0e929 name=d0e929> </a> <a id=d0e934 name=d0e934> </a> <a id=d0e939 name=d0e939> </a> A purchase card is a type of credit card that is issued by an organization to its employees. The card is generally used by the employees for purchasing corporate supplies and services. Payments are made by the corporate buyer to the card issuer.<p>Purchase cards, also known as procurement cards, are a special type of credit card that possess more features, capabilities, and controls than standard consumer credit, or charge, cards. Purchase cards are issued by an organization, known as the buyer, and used by its employees. Payments are made directly by the corporate buyer to the card issuer. With credit cards, payments are made by the individual buyer, who may be an agent of a corporate buyer, to the card issuer.<p>A merchant receives payment a few days after submitting a transaction and the buyer pays the issuing bank for the aggregate amount of purchases made during the billing period. Purchase cards provide merchants with a mechanism to eliminate the costly paper process of providing and collecting funds for outstanding invoices.<h3><a id=T456212> </a> <b> Purchase Card Data Levels <a id=d0e954 name=d0e954> </a> <a id=d0e959 name=d0e959> </a> </b></h3><p>For a purchase card, three levels of data can be captured and sent by a merchant to the buyer organization through the payment system. They are:<h4><a id=T456213> </a> <b> Level I: </b></h4><p>Level I transaction data consists of only basic data. A standard credit card transaction provides level I data to the payment system. The buyer cannot derive any special benefits from purchase card usage if the merchant passes only level I data.<h4><a id=T456214> </a> <b> Level II: </b></h4><p>Level II transaction data consists of data such as tax amount and order number in addition to level I data.<h4><a id=T456215> </a> <b> Level III: </b></h4><p>Level III line item detail provides specific purchase information such as item description, quantity, unit of measure and price. This information is very useful to the buyer to help streamline accounting and business practices and to merge payment data with electronic procurement systems. Data in the table below is only indicative. The actual fields are payment system-dependent.<p><strong> <span> Note: </span> </strong> Oracle Payments supports Level III data for both payment processors and gateway model payment systems.<p>This table lists information on data that is passed by Oracle Payments in each level.<table summary="table is summarized in text"border=1 cellpadding=4 cellspacing=0><caption>Information on Data that is Passed by Oracle Payments in Each Level</caption><tbody><tr bgcolor=#E0E0E0 class=HEADER valign=center><th scope=col><b> Data </b><th scope=col><b> Level 1 </b><th scope=col><b> Level 2 </b><th scope=col><b> Level 3 </b><tr valign=top><td>Card Number<td>X<td>X<td>X<tr valign=top><td>Card Holder Name<td>X<td>X<td>X<tr valign=top><td>Card Expiration Date<td>X<td>X<td>X<tr valign=top><td>Card Holder Billing Address<td>X<td>X<td>X<tr valign=top><td>Currency Code<td>X<td>X<td>X<tr valign=top><td>Tax Amount<td> <td>X<td>X<tr valign=top><td>Transaction/Order Number<td> <td>X<td>X<tr valign=top><td>Ship from Postal Code<td> <td>X<td>X<tr valign=top><td>Destination Postal Code<td> <td>X<td>X<tr valign=top><td>Discount Amount<td> <td> <td>X<tr valign=top><td>Freight Amount<td> <td> <td>X<tr valign=top><td>Duty Amount<td> <td> <td>X<tr valign=top><td>Line Item Information<td> <td> <td>X</table><h3><a id=T456216> </a> <b> Processing Purchase Card Transactions <a id=d0e1170 name=d0e1170> </a> <a id=d0e1175 name=d0e1175> </a> </b></h3><p>The transaction phases in a purchase card transaction are the same as in a credit card transaction. The phases are authorization and settlement. See <a href=T456136T456139.htm#ibycreditcardtrans> Understanding Credit Card Transactions </a> for more information about transaction phases.<p>Oracle Payments automatically recognizes purchase cards based on a set of seeded card number ranges. Oracle Payments passes additional information to the payment system during the settlement or settlement batch operation and through Gateway online requests. Authorization and other settlement operations carry the same information for purchase cards as they do for credit cards.<p>The business flow differs on the buyer's side and for the payment system, but not for the merchant except for the additional information that is passed.<h2><a name=4142509> </a> <a id=T456149> </a> <b> Understanding Funds Capture Bank Account Transfers <a id=ibynstibyfcbkaccttrans name=ibynstibyfcbkaccttrans> </a> </b></h2><p><a id=d0e1195 name=d0e1195> </a> <a id=d0e1200 name=d0e1200> </a> <a id=d0e1205 name=d0e1205> </a> Oracle Payments supports funds capture bank account transfers for both business-to-consumer and business-to-business models. The funds capture bank transfer functionality facilitates electronic transfer of payment amounts from a customer's bank account to the payee's bank account. Online validations are online and real-time, while actual funds transfer transactions are offline. In addition to standard direct debits, Oracle Payments supports remittance of bills receivable instruments. Source products use Oracle Payments as their interface to payment systems that provide connectivity to appropriate clearing house networks.<p><strong> <span> Note: </span> </strong> Oracle Payments has standard integration with Oracle Receivables for direct-debit and bills receivable remittance.<h3><a id=T456217> </a> <b> Electronic Funds Transfer (EFT) Online Validations <a id=d0e1219 name=d0e1219> </a> <a id=d0e1224 name=d0e1224> </a> <a id=d0e1229 name=d0e1229> </a> </b></h3><p>EFT online validations are a real time service provided by some payment systems to validate the third party payer bank account to be used in an EFT transaction. EFT online validations service ensures that the third party payer's bank account instrument exists and that there is no fraud alert against that bank account. Electronic funds transfer transactions are not real time. It is generally not possible, therefore, to ensure that the bank account is still open and has sufficient funds. EFT online validation assists with validity checking as follows:<ul><li><p>The validation step is an optional step for EFT transactions. It can be performed any number of times.</p><li><p>The validation is performed in real time.</p><li><p>The EFT online validation response message shares the same message standard with the credit card authorization response message for processor model type payment systems.</p> <p><strong> <span> Note: </span> </strong> EFT online validation is only offered for United States ACH and not for all payment systems. EFT online validation does not reserve funds or check if the account has sufficient funds.</p></ul><h2><a name=4142511> </a> <a id=T456150> </a> <b> Understanding PINless Debit Card Transactions <a id=ibyunstibypinldebcdtrans name=ibyunstibypinldebcdtrans> </a> </b></h2><p><a id=d0e1255 name=d0e1255> </a> <a id=d0e1260 name=d0e1260> </a> PINless debit card transactions are a type of payment method offered by some payment systems to first party payees in selected industries that are traditionally viewed as recurring billers. PINless debit card transactions, like bank account transfers, facilitate electronic transfer of payment amounts from a customer's bank account to the payee's bank account. In the case of PINless debit cards, however, the payer uses a card, as in a credit card transaction. The payer initiates the debit card payment process without providing a PIN. The first party payee authenticates the payers and assumes 100% liability for the transaction and any subsequent adjustments.<p>The transaction is sent to the debit networks for processing. Currently, three debit networks support PINless debit card payments: Star, NYCE, and Pulse.<p>Authorization and capture of PINless debit card transactions are handled in a single step by all payment systems. After authorizing the PINless debit card transaction, no modification to the transaction can be made. After the payment request is approved, the payer's account is debited in real time. Any dispute, error, or modification associated with the transaction can be handled offline between the payer and the first party payee.<p>The settlement step for PINless debit card transactions is flexible. While some payment systems, such as Paymentech, require this step to complete the transaction, other payment systems do not support this step. PINless debit card transactions, however, share the same batch with credit card and purchase card transactions. The payment system differentiates and settles transactions accordingly. <a id=d0e1274 name=d0e1274> </a><h3><a id=T456218> </a> <b> Process Flow for Gateway-Model Payment System <a id=d0e1282 name=d0e1282> </a> <a id=d0e1287 name=d0e1287> </a> </b></h3><p>Most gateway model payment systems handle PINless debit card transactions in a single step. After receiving the authorization request, the payment system will send the transaction to the debit network. The payer's account is debited after the authorization request is approved. The first party payee's account is credited sometime later. PINless debit card transactions are different from the process flow of credit card transactions where the authorization and fund capture are separated into two steps.<h3><a id=T456219> </a> <b> Process Flow for Processor-Model Payment System <a id=d0e1298 name=d0e1298> </a> <a id=d0e1303 name=d0e1303> </a> </b></h3><p>For most processor model payment systems, the flow for PINless debit cards is identical as that for payment gateways. However, some processor model payment systems, such as Paymentech, require an additional settlement step to complete the transaction. The first party payer's account will be credited after settlement and the fund transfer is said to be completed.<h2><a name=4142514> </a> <a id=T456151> </a> <b> Understanding Funds Disbursement <a id=ibyunstibyfundsdisbm name=ibyunstibyfundsdisbm> </a> </b></h2><p><a id=d0e1316 name=d0e1316> </a> <a id=d0e1321 name=d0e1321> </a> This section includes information on the following topics:<ul><li><p>Understanding Payment Methods (Funds Disbursement)</p><li><p>Understanding Payment Process Profiles</p><li><p>Understanding Documents Payable</p><li><p>Understanding Payments</p><li><p>Understanding Payment Instructions</p><li><p>Understanding Payment Process Requests</p></ul><h2><a name=4142515> </a> <a id=T456152> </a> <b> Understanding Payment Methods (Funds Disbursement) <a id=ibyunstibypaymethfd name=ibyunstibypaymethfd> </a> </b></h2><p><a id=d0e1353 name=d0e1353> </a> <a id=d0e1358 name=d0e1358> </a> On the funds disbursement side of Oracle Payments, a payment method is a payment attribute on a document payable. The payment method indicates the medium by which a first party payer makes a payment to a third party payee. Payment methods also include other information used during the early stages of payment processing, such as validations and rules that determine how payment methods can be assigned to documents payable. Examples of funds disbursement payment methods include the following:<ul><li><p>checks printed in-house by the payer</p><li><p>checks outsourced to the bank for printing</p><li><p>electronic funds transfers, through ACH in the United States or BACS in the United Kingdom</p><li><p>wires</p></ul><p>Oracle Payments seeds some payment methods, but also enables you to define your own as well.<p>A source product user, such as an Oracle Payables clerk, must select a payment method when entering a document payable, such as an invoice. The source product uses Oracle Payments setup to default payment methods onto each document payable and to restrict the user's choice of payment methods to encourage efficient payment processing.<h2><a name=4142516> </a> <a id=T456153> </a> <b> Understanding Payment Process Profiles <a id=ibyunstibypayprocprofs name=ibyunstibypayprocprofs> </a> </b></h2><p><a id=d0e1388 name=d0e1388> </a> <a id=d0e1393 name=d0e1393> </a> A payment process profile is a payment attribute assigned to documents payable, which specifies handling of the documents payable, payments, and payment instructions by Oracle Payments. Payment process profiles include several types of information, including specifications for payment instruction formatting and transmission.<p>Payment process profiles can be assigned to documents payable either by the source product user or by the Oracle Payments payment administrator. The selection of valid payment process profiles is determined by the payment process profile's usage rules, which are created in Oracle Payments setup. Usage rules for payment process profiles can be based on payment method, payment currency, first party organization, or internal bank account.<p>Payments are built from documents payable that have the same payment process profile, among other attributes. Payment instructions are built from payments that have the same payment process profile, among other attributes. Therefore, the payment process profile is available to specify Oracle Payments behavior at every step of the payment process.<h2><a name=4142517> </a> <a id=T456154> </a> <b> Understanding Documents Payable <a id=ibyunstibydocspayable name=ibyunstibydocspayable> </a> </b></h2><p><a id=d0e1410 name=d0e1410> </a> <a id=d0e1415 name=d0e1415> </a> A document payable is a transaction in a source product that is sent to Oracle Payments for payment. An example of a document payable in Oracle Payables is an invoice. During the payment process, documents payable are grouped together into actual payments.<h2><a name=4142518> </a> <a id=T456155> </a> <b> Understanding Payments <a id=ibyunstibypayments name=ibyunstibypayments> </a> </b></h2><p><a id=d0e1428 name=d0e1428> </a> <a id=d0e1433 name=d0e1433> </a> A payment is a single transfer of funds from one person or organization to another via printed payment document or electronic transmission. The diagram below shows how payments are processed by the Create Payment Instructions program, which places payments with the same payment process profile in the same payment instruction.<p><b> Processing Payments <a id=ibyprocpaymentsfig name=ibyprocpaymentsfig> </a> </b><p><img alt="the picture is described in the document text"height=433 src=./img/iby_ug_payminstcre.gif width=757><h2><a name=4142520> </a> <a id=T456156> </a> <b> Understanding Payment Instructions <a id=ibyunstibypayminstruc name=ibyunstibypayminstruc> </a> </b></h2><p><a id=d0e1453 name=d0e1453> </a> <a id=d0e1458 name=d0e1458> </a> A payment instruction contains one or more payments, along with aggregate payment information, and is created by running the Create Payment Instructions program. Depending on your setup, a payment instruction can be converted into a payment file to be printed onto payment documents, such as checks, or into a payment file that is transmitted to a payment system or financial institution for further processing and disbursement. To see the relationship between payment instructions and payments, see the figure entitled <a href=T456136T456139.htm#ibyprocpaymentsfig> Processing Payments </a> .<p>Each payment instruction that is electronically transmitted to a payment system or financial institution is associated with a payment file. This payment file contains data that instructs the payment system or financial institution how to make the payment. The following information is typically included in electronically transmitted payment files:<ul><li><p>number of payments to be made</p><li><p>amount of each payment</p><li><p>first party payer and third party payee bank account information</p><li><p>name of payees</p></ul><p>When the Payment Instruction amount exceeds the maximum amount mentioned in the Payment Process Profile setup, multiple payment instructions are created and the payments does not stop.<p>The payment instructions are generated based on payment instruction creation rules. Different payment instructions are created when payments have different values for a grouping parameter.<p>The logical reference ID should be unique and it should not repeat in same payment instruction nor in another payment instruction, even with a different payment reference number and amount.<h2><a name=4142521> </a> <a id=T456157> </a> <b> Understanding Payment Process Requests <a id=ibyunstibyppr name=ibyunstibyppr> </a> </b></h2><p><a id=d0e1495 name=d0e1495> </a> <a id=d0e1500 name=d0e1500> </a> A payment process request is a request created by a source product for Oracle Payments payment services. The payment process request, which originates in the source product during the documents payable selection process, contains one or more documents payable to be paid, along with information that allows Oracle Payments and the source product to identify the request and optional payment processing instructions. The source product may submit payment process requests to Oracle Payments via user action or concurrent program.<p>Once the payment process request is submitted to Oracle Payments, the Build Payments program validates the documents payable, groups the documents payable into payments according to document attributes and payment process profile grouping rules, and then validates the payments. Only documents payable that have the same payment process profile, payment method, and payment format can be grouped into the same payment.<h2><a name=4168609> </a> <a id=T459458> </a> <b> Understanding the Payment Process <a id=ibyunpaymentprocess name=ibyunpaymentprocess> </a> </b></h2><p><a id=d0e1515 name=d0e1515> </a> <a id=d0e1520 name=d0e1520> </a> The Payment Process starts when a source product, such as Payables, needs to pay documents payable, such as invoices. The source product user groups the documents payable into a payment process request and submits the request to Oracle Payments. Within Oracle Payments, the Build Payments program takes the submitted documents payable, validates them, groups them into payments, and then validates the payments. Each payment consists of one or more documents payable. Next, the Create Payment Instructions program groups the payments into payment instructions, and then validates the payment instructions. Each payment represents a check that will be printed or a single electronic funds transfer transaction, depending on the type of processing selected. Each payment instruction results in one payment file that contains pertinent information on one or more payments, such as payment amount and an account to be credited or debited. In the case of electronic payments, the payment file includes the payment instructions in a format required by the financial institution. To actually make payments, you print checks or electronically transmit the payment instruction to an external payment system or to a financial institution.<p>The figure below depicts the high-level Payment Process.<p><img alt="the picture is described in the document text"height=256 src=./img/iby_ug_paymbld.gif width=703></div></div><noscript><p>Scripting on this page enhances content navigation, but does not change the content in any way.</p></noscript><script>$(document).foundation();</script>