ipayment_trm

Oracle� iPaymentTechnical ReferenceManual RELEASE 11i

April 2000

Oracle� iPayment Technical Reference ManualRelease 11i

To order this book, ask for Part No. A83676–01

Copyright � 2000. Oracle Corporation. All rights reserved.

Major Contributors:

Contributors:

This Technical Reference Manual (TRM) in any form, software or printed matter, contains proprietary information of Oracle Corporation; it isprovided under an Oracle Corporation agreement containing restrictions on use and disclosure and is also protected by copyright, patent, andother intellectual property law. Restrictions applicable to this TRM include, but are not limited to: (a) exercising either the same degree of care tosafeguard the confidentiality of this TRM as you exercise to safeguard the confidentiality of your own most important Confidential Information ora reasonable degree of care, whichever is greater; (b) maintaining agreements with your employees and agents that protect the ConfidentialInformation of third parties such as Oracle Corporation and instructing such employees and agents of these requirements for this TRM; (c)restricting disclosure of this TRM to those of your employees who have a ”need to know” consistent with the purposes for which this TRM wasdisclosed to you; (d) maintaining this TRM at all times on your premises; (e) not removing or destroying any proprietary or confidential legendsor markings placed upon this TRM in whatever form, software or printed matter; and (f) not reproducing or transmitting this TRM in any form orby any means, electronic or mechanical, for any purpose, without the express written permission of Oracle Corporation. You should not use thisTRM in any form, software or printed matter, to create software that performs the same or similar functions as any Oracle Corporation products. The information in this TRM is subject to change without notice. If you find any problems in the TRM in any form, software or printed matter,please report them to us in writing. Oracle Corporation does not warrant that this TRM is error–free. This TRM is provided to customer ”as–is”with no warranty of any kind. This TRM does not constitute Documentation as that term is defined in Oracle’s agreements.

Reverse engineering of the Programs (software and documentation) associated with this TRM are prohibited. The Programs associated with thisTRM are not intended for use in any nuclear, aviation, mass transit, medical, or other inherently dangerous applications. It shall be licensee’sresponsibility to take all appropriate fail–safe, back–up, redundancy and other measures to ensure the safe use of such applications if thePrograms are used for such purposes, and Oracle disclaims liability for any damages caused by such use of the Programs.

Program Documentation is licensed for use solely to support the deployment of the Programs and not for any other purpose.

Restricted Rights LegendThis TRM and the Programs associated with this TRM delivered subject to the DOD FAR Supplement are ’commercial computer software’ anduse, duplication and disclosure of the TRM and the Programs associated with this TRM shall be subject to the licensing restrictions set forth in theapplicable Oracle license agreement. Otherwise, this TRM and the Programs associated with this TRM delivered subject to the FederalAcquisition Regulations are ’restricted computer software’ and use, duplication and disclosure of the TRM and the Programs associated with thisTRM shall be subject to the restrictions in FAR 52.227–14, Rights in Data –– General, including Alternate III (June 1987). Oracle Corporation, 500Oracle Parkway, Redwood City, CA 94065.

Oracle is a registered trademark, and iPayment, CASE*Exchange, Enabling the Information Age, Hyper*SQL, NLS*Workbench, Oracle7, Oracle8,Oracle 8i, Oracle Access, Oracle Application Object Library, Oracle Discoverer, Oracle Financials, Oracle Quality, Oracle Web Customers, OracleWeb Employees, Oracle Work in Process, Oracle Workflow, PL/SQL, Pro*Ada, Pro*C, Pro*COBOL, Pro*FORTRAN, Pro*Pascal, Pro*PL/I,SmartClient, SQL*Connect, SQL*Forms, SQL*Loader, SQL*Menu, SQL*Net, SQL*Plus, and SQL*Report are trademarks or registered trademarksof Oracle Corporation. Other names may be trademarks of their respective owners.

T

CAUTION

his Technical Reference Manual in any form –– software orprinted matter –– contains proprietary, confidential information

that is the exclusive property of Oracle Corporation. If you do nothave a valid contract with Oracle for the use of this Technical ReferenceManual or have not signed a non–disclosure agreement with Oraclecovering this Technical Reference Manual, then you received thisdocument in an unauthorized manner and are not legally entitled topossess or read it.

Use, duplication, and disclosure are subject to restrictions stated inyour contract with Oracle Corporation.

vContents

Oracle Proprietary, Confidential Information––Use Restricted by Contract

Contents

Chapter 1 Introduction 1 – 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 2 High–Level Design 2 – 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of High–Level Design 2 – 2. . . . . . . . . . . . . . . . . . . . . . . . . . . Database Diagrams 2 – 8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Public Table List 2 – 11. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Public View List 2 – 15. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Internal View List 2 – 16. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Module List 2 – 17. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Chapter 3 Detailed Design 3 – 1. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Overview of Detailed Design 3 – 2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Table and View Definitions 3 – 3. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

vi Oracle iPayment Technical Reference Manual


C H A P T E R

1T

1 – 1Introduction


Introduction

he Oracle iPayment Technical Reference Manual provides theinformation you need to understand the underlying structure of

Oracle iPayment. After reading this manual, you should be able toconvert your existing applications data, integrate your existingapplications with Oracle iPayment, and write custom reports for OracleiPayment, as well as read data that you need to perform other tasks.

This chapter introduces you to the Oracle iPayment Technical ReferenceManual, and explains how to use it.

1 – 2 Oracle iPayment Technical Reference Manual


Introduction

At Oracle, we design and build applications using Oracle Designer, oursystems design technology that provides a complete environment tosupport developers through all stages of a systems life cycle. Becausewe use a repository–based design toolset, all the information regardingthe underlying structure and processing of our applications is availableto us online. Using Oracle Designer, we can present this information toyou in the form of a technical reference manual.

This Oracle iPayment Technical Reference Manual contains detailed,up–to–date information about the underlying structure of OracleiPayment. As we design and build new releases of Oracle iPayment,we update our Oracle Designer repository to reflect our enhancements.As a result, we can always provide you with an Oracle iPaymentTechnical Reference Manual that contains the latest technical informationas of the publication date. Note that after the publication date we mayhave added new indexes to Oracle iPayment to improve performance.

About this Manual

This manual describes the Oracle Customer Relationship Management(CRM) Applications Release 11i data model, as used by OracleiPayment; it discusses the database we include with a fresh install ofOracle CRM Release 11i. If you have not yet upgraded to Release 11i,your database may differ from the database we document in this book.

You can contact your Oracle representative to confirm that you havethe latest technical information for Oracle iPayment. You can also useOracleMetaLink which is accessible through Oracle’s Support WebCenter (http://www.oracle.com/support/elec_sup).

Finding the Latest Information

The Oracle iPayment Technical Reference Manual contains the latestinformation as of the publication date. For the latest information weencourage you to use OracleMetaLink which is accessible throughOracle’s Support Web Center (http://www.oracle.com/support/elec_sup).

1 – 3Introduction


Audience

The Oracle iPayment Technical Reference Manual provides usefulguidance and assistance to:

• Technical End Users

• Consultants

• Systems Analysts

• System Administrators

• Other MIS professionals

This manual assumes that you have a basic understanding ofstructured analysis and design, and of relational databases. It alsoassumes that you are familiar with Oracle Application Object Libraryand Oracle iPayment. If you are not familiar with the above products,we suggest that you attend one or more of the training classes availablethrough Oracle Education (see: Other Information Sources: page1 – 7).

How This Manual is Organized

This manual contains two major sections, High–Level Design andDetailed Design.

High–Level Design

This section, Chapter 2, contains database diagrams and lists eachdatabase table and view that Oracle iPayment uses. This chapter alsohas a list of modules.

Detailed Design

This section, Chapter 3, contains a detailed description of the OracleiPayment database design, including information about each databasetable and view you might need for your custom reporting or other datarequirements.



How to Use This Manual

The Oracle iPayment Technical Reference Manual is a single, centralizedsource for all the information you need to know about the underlyingstructure and processing of Oracle iPayment. For example, you can usethis manual when you need to:

• Convert existing application data

• Integrate your Oracle iPayment application with your otherapplications systems

• Write custom reports

• Define alerts against Oracle Applications tables

• Configure your Oracle Self–Service Web Applications

• Create views for decision support queries using query tools

• Create business views for Oracle Discoverer

You need not read this manual cover to cover. Use the table of contentsand index to quickly locate the information you need.

How Not To Use This Manual

Do not use this manual to plan modifications

You should not use this manual to plan modifications to OracleiPayment. Modifying Oracle iPayment limits your ability to upgrade tofuture releases of your Oracle iPayment application. In addition, itinterferes with our ability to give you the high–quality support youdeserve.

We have constructed Oracle iPayment so that you can customize it tofit your needs without programming, and you can integrate it withyour existing applications through interface tables. However, shouldyou require program modifications, you should contact our supportteam (see: Other Information Sources: page 1 – 7). They can put youin touch with Oracle Services, the professional consulting organizationof Oracle. Their team of experienced applications professionals canmake the modifications you need while ensuring upward compatibilitywith future product releases.

1 – 5Introduction


Do not write data into non–interface tables

Oracle reserves the right to change the structure of Oracle Applicationstables, and to change the meaning of, add, or delete lookup codes anddata in future releases. Do not write data directly into or change datain non–interface tables using SQL*Plus or other programming toolsbecause you risk corrupting your database and interfering with ourability to support you.

Moreover, this version of the Oracle iPayment Technical Reference Manualdoes not contain complete information about the dependenciesbetween Oracle iPayment applications tables. Therefore, you shouldwrite data into only those tables we identify as interface tables. If youwrite data into other non–interface tables, you risk violating your dataintegrity since you might not fulfill all the data dependencies in yourOracle iPayment application.

You are responsible for the support and upgrade of the logic within theprocedures that you write, which may be affected by changes betweenreleases of Oracle Applications.

Do not rely on upward compatibility of the data model

Oracle reserves the right to change the structure of Oracle iPaymenttables, and to change the meaning of, add, or delete lookup codes andother data in future releases. We do not guarantee the upwardcompatibility of the Oracle iPayment data model. For example, if youwrite a report that identifies concurrent requests that end in Errorstatus by selecting directly from Oracle Application Object Librarytables, we do not guarantee that your report will work properly afteran upgrade.

About Oracle Application Object Library

The Oracle iPayment Technical Reference Manual may contain referencesto tables that belong to Oracle Application Object Library. OracleApplication Object Library is a collection of pre–built applicationcomponents and facilities for building Oracle Applications andextensions to Oracle Applications. Oracle Application CodingStandards use the Oracle Application Object Library and containsshared components including but not limited to –– forms, subroutines,concurrent programs and reports, database tables and objects,messages, menus, responsibilities, flexfield definitions and online help.

☞



Attention: Oracle does not support any customization ofOracle Application Object Library tables or modules, not evenby Oracle consultants. (Oracle Application Object Librarytables generally have names beginning with FND_%.)

Accordingly, this manual does not contain detailed informationabout most Oracle Application Object Library tables used byOracle iPayment.

A Few Words About Terminology

The following list provides you with definitions for terms that we usethroughout this manual:

Relationship

A relationship describes any significant way in which two tables maybe associated. For example, rows in the Journal Headers table mayhave a one–to–many relationship with rows in the Journal Lines table.

Database Diagram

A database diagram is a graphic representation of application tablesand the relationships between them.

Module

A module is a program or procedure that implements one or morebusiness functions, or parts of a business function, within anapplication. Modules include forms, concurrent programs and reports,and subroutines.

Application Building Block

An application building block is a set of tables and modules (forms,reports, and concurrent programs) that implement closely–relateddatabase objects and their associated processing. Said another way, anapplication building block is a logical unit of an application.

QuickCodes

QuickCodes let you define general purpose, static lists of values forwindow fields. QuickCodes allow you to base your program logic onlookup codes while displaying user–friendly names in a list of values

1 – 7Introduction


window. QuickCodes simplify name and language changes by lettingyou change the names your end users see, while the codes in yourunderlying programs remain the same.

Form

A form is a module comprised of closely related windows that are usedtogether to perform a task. For example, the Enter Journals form inOracle General Ledger includes the Enter Journals window, the Batchwindow, and the More Actions window among others. The EnterJournals window is the main window, and from it, you can use buttonsto navigate to other windows in the form. The form name usuallycorresponds to the main window in the form, and is frequently awindow you open directly from the Navigator.

Other Information Sources

Installation and System Administration

Training

Oracle Education offers a complete set of training courses to help youand your staff master Oracle CRM Applications. We can help youdevelop a training plan that provides thorough training for both yourproject team and your end users. We will work with you to organizecourses appropriate to your job or area of responsibility.

Training professionals can show you how to plan your trainingthroughout the implementation process so that the right amount ofinformation is delivered to key people when they need it the most. Youcan attend courses at any one of our many Educational Centers, or youcan arrange for our trainers to teach at your facility. In addition, wecan tailor standard courses or develop custom courses to meet yourneeds.

Support

From on–site support to central support, our team of experiencedprofessionals provides the help and information you need to keepOracle iPayment working for you. This team includes your TechnicalRepresentative, Account Manager, and Oracle’s large staff ofconsultants and support specialists with expertise in your business



area, managing an Oracle server, and your hardware and softwareenvironment.

1 – 9Introduction


About Oracle

Oracle Corporation develops and markets an integrated line ofsoftware products for database management, applicationsdevelopment, decision support, and office automation, as well asOracle Applications, an integrated suite of more than 75 softwaremodules for financial management, supply chain management,manufacturing, project systems, human resources, and sales andservice management.

Oracle products are available for mainframes, minicomputers, personalcomputers, network computers, and personal digital assistants,allowing organizations to integrate different computers, differentoperating systems, different networks, and even different databasemanagement systems, into a single, unified computing and informationresource.

Oracle is the world’s leading supplier of software for informationmanagement, and the world’s second largest software company.Oracle offers its database, tools, and applications products, along withrelated consulting, education, and support services, in over 145countries around the world.

Thank You

Thanks for using Oracle iPayment and this technical reference manual!

We appreciate your comments and feedback. After the Table ofContents of this manual is a Reader’s Comment Form that you can useto explain what you like or dislike about Oracle iPayment or thistechnical reference manual. Mail your comments to the followingaddress or call us directly at (650) 506–7000.

Oracle CRM Applications Content Development ManagerOracle Corporation500 Oracle ParkwayRedwood Shores, California 94065 U.S.A.

C H A P T E R

2T

2 – 1High–Level Design


High–Level Design

his chapter presents a high–level design for Oracle iPayment thatsatisfies the business needs we specify during Strategy and

Analysis. It contains database diagrams for Oracle iPaymentapplication building blocks, lists of database tables and views, and alist of modules.



Overview of High–Level Design

During High–Level Design, we define the application components(tables, views, and modules) we need to build our application. Wespecify what application components should do without specifying thedetails of how they should do it.

You can refer to this High–Level Design chapter to quickly acquaintyourself with the tables, views, and modules that comprise OracleiPayment applications. And, you can prepare yourself to understandthe detailed design and implementation of Oracle iPayment.

Database Diagrams

The Database Diagrams section graphically represents all OracleiPayment applications tables and the relationships between them,organized by building block.

Use this section to quickly learn what tables each Oracle iPaymentapplication building block uses, and how those tables interrelate. Then,you can refer to the Table and View Definitions sections of Chapter 3for more detailed information about each of those tables.

Table Lists

The Table List sections list the Oracle iPayment applications tables.Because a product might not include at least one table for each type,this Technical Reference Manual might not include each of thefollowing sections.

Public Tables

Use the Public Table List section to quickly identify the tables you aremost interested in. Then, you can refer to the Table and ViewDefinitions sections of Chapter 3 for more detailed information aboutthose tables.

In addition, this manual may contain full documentation for one ormore of the following Application Object Library tables: FND_DUAL,FND_CURRENCIES, and FND_COMMON_LOOKUPS.



Internal Tables

This section includes a list of private, internal tables used by OracleiPayment; we do not provide additional documentation for thesetables.

View Lists

The View List sections list the Oracle iPayment views, with one sectionfor each type of view. Because a product might not include at least oneview for each type, this Technical Reference Manual might not includeeach of the following sections.

Use this section to quickly identify the views you are most interestedin. Then, you can refer to the Table and View Definitions sections ofChapter 3 for more detailed information about those views.

Public Views

This section lists views that may be useful for your custom reporting orother data requirements. The list includes a description of the view,and the page in Chapter 3 that gives detailed information about thepublic view.

Web Views

This section lists views that you may need to configure yourSelf–Service Web applications. The list includes a description of theview, and the page in Chapter 3 that gives detailed information aboutthe web view.

Forms and Table Views

This section lists supplementary views that are not essential to theRelease 11i data model, but simplify coding or improve performancefor Oracle Developer.

Internal Views

This section includes each private, internal view that Oracle iPaymentuses.



Multiple Reporting Currency Views

This list includes views that were created to support the MultipleReporting Currencies feature.

Module List

The Module List section briefly describes each of the Oracle iPaymentapplications modules. This section lists forms, reports, and concurrentprograms.

A form is a module comprised of closely related windows that are usedtogether to perform a task. For example, the Enter Journals form inOracle General Ledger includes the Enter Journals window, the Batchwindow, and the More Actions window. The Enter Journals window isthe main window, and from it, you can use buttons to navigate to otherwindows in the form. The form name usually corresponds to the mainwindow in the form, and is frequently a window you can open directlyfrom the Navigator.

The Reports and Concurrent Programs lists include processes you cansubmit from the Submit Requests window or other windows, as well asprocesses that are submitted automatically by Oracle iPayment. Useyour user’s guide to learn more about reports and concurrentprocesses.



Database Diagramming Conventions

We use the following notational conventions in our database diagrams:

Figure 2 – 1Database DiagramConventions

Mandatory and Optional Foreign Keys

A value entered in the column in the foreign keymust match a value in the primary key column.

��

��

��

�

��

��

��

�

��&��$

"�' !��&&$��'&�

��&�"!��

��'$%�(��"$��!��)

�$�

��%��$�

��&��%�%��&�"!

��&��$'��!��&"$

"$��!��)�"!%&$��!&

��'�%��!�&��"$��!��) '%&� �&��&��#$� �$)��)

�$� �$)��)��"�' !��

��!��&"$)��"�' !��

Server Model Diagram Elements and Notation

A value entered in the column in the foreign keymust match either a value in the primary key column,or else it must be null.



Tables – are the basic unit of storage in the database. A hand symbolpreceding the title in the table’s title bar indicates that the table is notowned by this application but shared with another.

Foreign key constraint – is a type of referential integrity constraint forchecking the integrity of data entered in a specific column or set ofcolumns. This specified column or set of columns is known as theforeign key.

Delete rule indicator – determines the action to be taken when anattempt is made to delete a related row in a join table. A line throughthe foreign key constraint, as shown on the above diagram, indicatesthat this action is restricted.

Arcs – specify that, for any given row in a table, a value must beentered in one of the arc columns. The remaining columns within thearc must be null.



Database Diagrams

This section graphically represents most of the significant OracleiPayment tables and the relationships between them, organized bybuilding block. Use this section to quickly learn what tables eachOracle iPayment application building block uses, and how these tablesinterrelate. Then, you can refer to the Table and View Definitionssections of Chapter 3 for more detailed information about each of thosetables.

This section contains a database diagram for each of the followingOracle iPayment application building blocks:

• Diagram 1: IBY Payment Processing

• Diagram 2: IBY Risk Management

Some tables, especially important reference tables, appear in more thanone database diagram. When several building blocks use a table, weshow that table in each appropriate database diagram.

IBY Payment Processing



IBY Risk Management



Public Table List

This section lists each public database table that iPAYMENT uses andprovides a brief description of each of those tables. The page reference isto the table description in Chapter 3.

Note that ”public” tables are not necessarily intended for write access bycustom code; Oracle Corporation supports write access using onlystandard Oracle Applications forms, reports, and programs, or any SQLwrite access to tables explicitly documented as API tables. For moreinformation, see the How Not To Use This Manual section of this book’sIntroduction.

iPAYMENT uses the following Public tables:

Table Name Description

FND_LOOKUP_VALUES QuickCode values

IBY_ACCPPMTMTHD IBY_ACCPPMTMTHD contains a list of all the paymentinstrument methods that are accepted by a iPayment. (Seepage 3 – 8)

IBY_ACCTTYPE IBY_ACCTTYPE contains a list of various account typessupported. For example for bank account, the accounttypes could be Checking, Savings etc, for Credit Card, theaccount types could be Visa, MasterCard, Discoveretc...(See page 3 – 9)

IBY_ACTIVITY IBY_ACTIVITY stores scheduler related activities. (See page3 – 11)

IBY_BANKACCT IBY_BANKACCOUNTstores bank account relatedinformation of the customer(payer) or payee. (See page3 – 13)

IBY_BATCHES_ALL IBY_BATCHES holds the information about batchoperations for SSL credit card transactions. A terminalbased merchant will need to have batch operations. Thestatus of the payees batch will be contained in this table.(See page 3 – 14)

IBY_BEPINFO IBY_BEPINFO has a row for every BEP(Back End PaymentSystem) configured in system. A BEP is a payment providersuch as Cybercash, Verifone etc (See page 3 – 18)



IBY_BEPKEYS IBY_BEPKEYS contains a list of all the keys that identifies apayee or payer with a Back End Payment System. (See page3 – 20)

IBY_BEPLANGS IBY_BEPLANGS contains list of all the languages supportedby the Back End Payment System (See page 3 – 21)

IBY_CREDITCARD IBY_CREDITACRD stores Credit Card related informationof the customer(payer) or payee. (See page 3 – 22)

IBY_DEFAULT_BEP IBY_DEFAULT_BEP contains the default Back End PaymentSystem information. Based on the instrument type thepayment request gets routed to this Back End PaymentSystem. (See page 3 – 23)

IBY_ECAPP IBY_ECAPP stores information about Electronic CommerceApplications registered with iPayment. (See page 3 – 24)

IBY_INSTRHOLDER IBY_INSTRHOLDER stores the information about theholder of the instrment. A payment instrument can be heldby different users or payees or payers. (See page 3 – 25)

IBY_IRF_PMT_AMOUNT IBY_IRF_PMT_AMOUNT stores information pertaining tothe payment amount risk factor involved in the paymentrequest. A payment request that has huge amount ispossibly a fraudulent payment. But the value of the amountvaries frombusiness to business. Merchants can set up aranges of amount risk factor . Each range is associated witha risk score – low, medium_low, medium , medium_highand high. (See page 3 – 26)

IBY_IRF_PMT_FREQUENCY IBY_IRF_PMT_HISTORY stores information pertaining tothe payment frequency risk factor. It has information aboutthe frequency of payments made in the given time frame(duration) . (See page3 – 27)

IBY_IRF_PMT_HISTORY IBY_IRF_PMT_HISTORY stores information pertaining tothe payment history risk factor. Merchants can set updifferent time ranges–which they consider risky. (See page3 – 28)

IBY_IRF_PMT_HIST_RANGE IBY_IRF_PMT_HISTORY_RANGE stores the frequencyranges information pertaining to the payment history riskfactor. The customer can setup multiple frequency rangesfor a specific duration. (Seepage 3 – 29)



IBY_IRF_RISKY_INSTR IBY_IRF_RISKY_INSTR stores information pertaining to therisk instrument risk factor. It has information about themerchant who sends the file of risky instruments, the typeof instrument and other account information pertaining totherisky instrument. (See page 3 – 30)

IBY_IRF_TIMEOF_PURCHASE IBY_IRF_TIMEOF_PURCHASE stores informationpertaining to the time of purchase risk factor. The merchantcan set up different time ranges–and associate a risk scoreof low risk, medium low risk, medium risk, medium highrisk and highrisk (See page 3 – 31)

IBY_IRF_TRXN_AMT_LIMIT IBY_IRF_TRXN_AMT_LIMITstores information pertainingto the transaction amount limit risk factor. It is a limit onthe total amount of payments made using the sameinstrument in a particular duration. (See page 3 – 32)

IBY_MAPPINGS IBY_MAPPINGS stores mapping of codes with risk scores.Each row includes a code and a value for that code. (Seepage 3 – 33)

IBY_PAYEE IBY_PAYEE holds a row for each payee such as a biller ormerchant/store at this site. (See page 3 – 34)

IBY_PMTMTHD_CONDITIONS IBY_PMTMTHD_CONDITIONS contains the conditions forthe payment method. Each condition is composed of aparameter, operation and value. The condition is evaluatedat runtime to check if the condition is satisfied (See page3 – 35)

IBY_PMTSCHEMES IBY_PMTSCHEMES contains a list of Payment Schemes thatwill be supported by a BEP (See page 3 – 36)

IBY_RISK_FACTORS IBY_RISK_FACTORS stores information about the RiskFactors. These are factors which a merchant deems fit to useto evaluate the risk of the customer who wants to purchaseits goods and services. Risk Management feature willcontainbundled risk factors which can be set up at the sitelevel. (See page 3 – 37)



IBY_RISK_FORMULAS IBY_RISK_FORMULAS stores risk formula retaledinformation . Risk Formula is used by merchants to evaluatethe risk of the customer. This formula could be different fordifferent goods/services offered by the merchants. A RiskFormulamay be comprised of multiple risk factors withvarying weights assigned to each one. (See page 3 – 39)

IBY_RISK_FORMULA_ITEM IBY_RISK_FORMULA_ITEM table is an intersection tablebetween the IBY_RISK_FORMULA andIBY_RISK_FACTORS. It stores weight for different RiskFactors. (See page 3 – 40)

IBY_ROUTINGINFO IBY_ROUTINGINFO contains information that mapsrouting rule name (payment method name) with the BackEnd Payment System. (See page 3 – 41)

IBY_TANGIBLE IBY_TANGIBLE storesInformation about the bills or ordersis stored in this table. (See page 3 – 42)

IBY_TRXN_CORE IBY_TRXN_CORE contains the details of a payment requestthat are specific for basic credit card operations. (See page3 – 46)

IBY_TRXN_EXTENDED IBY_TRXN_EXTENDED contains the details of a paymentrequest that are specific for extended SET functionality forCredit Cards (See page 3 – 48)

IBY_TRXN_FI IBY_TRXN_FI contains the details of a payment request thatare specific for systems that support both bank accounttransfers and credit cards such as Financial Institutions. (Seepage 2 – 14)

IBY_TRXN_SUMMARIES_ALL IBY_TRXN_SUMMARIES_ALL contains information abouteach payment request. This table is used for both onlineand offline payment transactions. The informationcontained in this table is generic in nature to cover thevarious paymentinstruments and the operations on them.The specific details are stored in other detail tables such asIBY_TRXN_CORE, IBY_TRXN_EXTENDED andIBY_TRXN_FI based on the type of operation and thepayment instrument used forpayment. (See page 3 – 51)



Public View List

This section lists each public database view that Oracle iPayment usesand provides a brief description of each of those views. These viewsmay be useful for your custom reporting or other data requirements.The page reference is to the detailed view description in Chapter 3.

Oracle iPayment uses the following public views:

View Name Description

FND_LOOKUPS Oracle Application Object Library QuickCodes (See page3 – 7)

IBY_BATCHES_ALL_V (See page 3 – 16)

IBY_TRANS_ALL_V (See page 3 – 43)



Internal View List

This section lists each private, internal view that Oracle iPayment uses.

Warning: Oracle Corporation does not support access to OracleApplications data using these views, except from standardOracle Applications forms, reports, and programs.

Oracle iPayment uses the following internal views:

• IBY_AVS_RSTYPES_V

• IBY_BANKACCT_V

• IBY_CRC_RSTYPES_V

• IBY_CREDITCARD_V

• IBY_ECAPP_V

• IBY_FOP_DTYPES_V

• IBY_FORMULA_FACTOR_V

• IBY_INSTR_HOLDER_V

• IBY_PAYMENTS_V

• IBY_PA_RSTYPES_V

• IBY_PH_DTYPES_V

• IBY_PH_RSTYPES_V

• IBY_RC_RSTYPES_V

• IBY_TAL_DTYPES_V

• IBY_TAL_RSTYPES_V

• IBY_TOP_RSTYPES_V

• IBY_TRANSACTIONS_SET_V

• IBY_TRANSACTIONS_V

• IBY_TRANS_BANKACCT_V

• IBY_TRANS_CORE_V

• IBY_TRANS_FI_V

• IBY_TRANS_SET_V



Module List

Oracle iPayment uses no additional forms, reports, or concurrentprograms.

C H A P T E R

3T

3 – 1Detailed Design


Detailed Design

his chapter presents a detailed design for implementing OracleiPayment. It contains detailed definitions of tables and views

that you may need to reference to write custom reports or use for otherdata extraction.



Overview of Detailed Design

During Detailed Design, we specify in detail how each applicationscomponent should work. We prepare detailed definitions of tables andviews.

You can refer to this Detailed Design chapter to gain a detailedunderstanding of the underlying structure and processing of OracleiPayment that enables you to:

• Convert existing application data

• Integrate your Oracle iPayment application with your otherapplications systems

• Write custom reports

• Define alerts against Oracle Applications tables

• Create views for decision support queries using query tools

Table and View Definitions

The Table and View Definitions section contains a detailed definition ofOracle iPayment applications tables. For each table, it providesinformation about primary keys, foreign keys, QuickCodes, indexes,triggers, and sequences. It also gives you a detailed description of eachcolumn and its characteristics. In addition, it provides the SQLstatement that defines each view. Review this section to get a detailedunderstanding of what tables your Oracle iPayment applicationcontains, and how it uses them to hold and access the information itneeds.



Table and View Definitions

This section contains a detailed description of each Oracle iPaymenttable and view that you may need to reference. For each table, itpresents detailed information about:

• Primary keys

• Foreign keys

• Column descriptions

• Indexes

• Oracle sequences

• Triggers

• View derivations

Because Oracle does not support customization of Oracle ApplicationObject Library tables, we do not provide you with detailed informationabout them. Consequently, this section does not document all theFND_% tables Oracle iPayment uses.

The following sections appear in each table or view description:

Foreign Keys

To help you understand the relationships between tables, we list eachforeign key contained in a table. For each foreign key in a table, we listthe primary key table name (the table to which a foreign key refers), itscorresponding primary key columns, and the foreign key columns thatrefer to those primary key columns.

When the primary key table has a composite primary key, we list eachcolumn of the composite key sequentially.

If a table contains two or more distinct foreign keys that refer to thesame primary key table, we repeat the primary key table name and listeach of the distinct foreign keys separately.

QuickCodes Columns

When a database column contains a QuickCodes value, which weimplement using a foreign key to FND_LOOKUPS, MFG_LOOKUPS,or to some other lookup table, we list the QuickCodes type (lookup



type) to which the QuickCodes value must belong and a complete listof QuickCodes values and meanings. Some QuickCodes can bedefined by you in the application. These values are designated asUser–defined.

Column Descriptions

We list the important characteristics of each column in a table or view.These characteristics include whether the column is part of the table’sprimary key, whether Oracle8i requires a value for this column, and thedata type of the column. We also give you a brief description of howOracle iPayment uses the column.

When a column is part of a table’s primary key, we append the notation(PK) to the name of that column.

To help you understand which columns Oracle iPayment uses andwhich columns it does not use, we alert you to any unused column.When no module uses a database column, we show one of thefollowing legends in the Description column:

Oracle iPayment does not use this column,although the column might be used in a futurerelease.

Oracle iPayment no longer uses this column.AutoInstall installs this column. Subsequentversions of Oracle iPayment might not include thiscolumn.

Oracle iPayment no longer uses this column. Ifyou upgraded your software from an earlier version,you may still have this column, depending uponwhether you chose to delete it during an upgradeprocess. If you install Oracle iPayment, you do nothave this column.

Standard Who Columns

Most Oracle iPayment tables contain standard columns to support \Row Who. When your program or SQL*Plus command selects a rowfrom a table, use these columns to determine who last updated the row.If your program or SQL*Plus command updates or inserts a row in an

Not currentlyused

No longer used

No longerinstalled



interface table, you must populate each of the five standard Whocolumns:

Date when a user last updated this row

User who last updated this row (foreignkey to FND_USER.USER_ID)

Date when this row was created

User who created this row (foreign key toFND_USER.USER_ID)

Operating system login of user who lastupdated this row (foreign key toFND_LOGINS.LOGIN_ID). You shouldset this to NULL, or to 0 if NULL is notallowed

Since every table containing Who columns has several foreign keys tothe tables FND_USER and FND_LOGINS, we do not include theforeign key columns LAST_UPDATED_BY, CREATED_BY, orLAST_UPDATE_LOGIN in a table’s list of foreign keys.

Additional Who Columns for Concurrent Programs

Some Oracle iPayment tables also contain several additional Whocolumns to distinguish between changes a user makes with a form andchanges a concurrent program makes. When a concurrent programupdates or inserts a row in a table, the concurrent program populatesthe following additional Who columns:

Concurrent request ID of program that lastupdated this row (foreign key toFND_CONCURRENT_REQUESTS.RE-QUEST_ID)

Application ID of program that lastupdated this row (foreign key toFND_APPLICATION.APPLICATION_ID)

Program ID of program that last updatedthis row (foreign key to FND_CONCUR-RENT_PROGRAM.CONCURRENT_PRO-GRAM_ID)

Date when a program last updated thisrow

LAST_UPDATE_DATE

LAST_UPDATED_BY

CREATION_DATE

CREATED_BY

LAST_UPDATE_LOGIN

REQUEST_ID

PROGRAM_APPLICATION_ID

PROGRAM_ID

PROGRAM_UPDATE_DATE



Since every table containing these additional Who columns has severalforeign keys to the tables FND_CONCURRENT_REQUESTS,FND_APPLICATION, and FND_CONCURRENT_PROGRAM, we donot include the foreign key columns REQUEST_ID,PROGRAM_APPLICATION_ID, or PROGRAM_ID in a table’s list offoreign keys.

Indexes

If an Oracle iPayment table uses an Oracle8i index, we list the databasecolumns that comprise that index, in sequential order.

Note: The indexes we document in this manual correspond tounique keys we specified during product development and testing.In some cases, we may add additional indexes during the portingprocess to fine–tune performance on specific platforms; therefore,there may be minor differences between the indexes documented inthis book and the indexes for production versions of OracleiPayment.

Sequences

Oracle iPayment uses Oracle8i sequence generators to generate uniqueintegers. If any table column gets its value from an Oracle8i sequencegenerator, we list the name of the corresponding sequence generatorand the name of the column that stores the unique integer.

Database Triggers

If a table has one or more active database triggers, we provide a briefexplanation of each database trigger and when it fires.

View Derivation

For each Oracle iPayment view you may need to reference, we includeimportant elements from the SQL statement that defines or creates aview. By studying this view definition, you can understand exactlyhow a view derives its contents.



FND_LOOKUPS

FND_LOOKUPS is a view of selected columns from the tableFND_LOOKUP_VALUES. This view contains information about theavailable QuickCodes in the language under which Oracle Applicationsis currently running at your site. Oracle Application Object Library usesthis view to display information for LOVs.

View DefinitionCREATE VIEW FND_LOOKUPS as SELECT LOOKUP_TYPE, LOOKUP_CODE, MEANING, DESCRIPTION, ENABLED_FLAG, START_DATE_ACTIVE, END_DATE_ACTIVE from FND_LOOKUP_VALUES LV Where LANGUAGE = userenv(’LANG’) and VIEW_APPLICATION_ID = 0 and SECURITY_GROUP_ID = fnd_global.lookup_security_group(LV.LOOKUP_TYPE, LV.VIEW_APPLICATION_ID)

Column DescriptionsName Null? Type Description

LOOKUP_TYPE NOT NULL VARCHAR2(30) QuickCode lookup typeLOOKUP_CODE NOT NULL VARCHAR2(30) QuickCode codeMEANING NOT NULL VARCHAR2(80) QuickCode meaningDESCRIPTION NULL VARCHAR2(240) DescriptionENABLED_FLAG NOT NULL VARCHAR2(1) Enabled flagSTART_DATE_ACTIVE NULL DATE The date when the QuickCode

becomes activeEND_DATE_ACTIVE NULL DATE The date when the QuickCode

becomes inactive



IBY_ACCPPMTMTHD

IBY_ACCPPMTMTHD contains a list of all the payment instrumentmethods that are accepted by a payeet.

Foreign KeysPrimary Key Table Primary Key Column Foreign Key Column

IBY_ACCTTYPE ACCTTYPEID ACCTTYPEIDIBY_PAYEE MPAYEEID MPAYEEID


PAYEEID NOT NULL VARCHAR2(80) ID of the payee passed byEllectronic CommerceApplication

ECAPPID NOT NULL NUMBER Electronic Commerce Applicationidentifier

ACCTTYPEID NOT NULL NUMBER(15) Account type identifierMPAYEEID NOT NULL NUMBER(15) Payee IdentifierSTATUS NULL NUMBER(2) Status in 0–active, 1–inactive.LAST_UPDATE_DATE NOT NULL DATE Standard WHO ColumnOBJECT_VERSION_NUMBER NOT NULL NUMBER This column is used for locking

purposes that subsequentlyallows for checking if there is’dirty’ or old data on thescreen compared to what is inthe database. The situationoccurs when the HTMLapplication is an ’stateless’application.

LAST_UPDATED_BY NOT NULL NUMBER(15) Standard WHO ColumnCREATED_BY NOT NULL NUMBER(15) Standard WHO ColumnCREATION_DATE NOT NULL DATE Standard WHO ColumnLAST_UPDATE_LOGIN NULL NUMBER(15) Standard WHO Column



IBY_ACCTTYPE

IBY_ACCTTYPE contains a list of various account types supported.For example for bank account, the account types could be Checking,Savings etc... For Credit Card, the account types could be Visa,MasterCard, Discover etc...

QuickCodes ColumnsColumn QuickCodes Type QuickCodes Table

ACCTTYPE IBY_ACT_TYPE IBY_LOOKUPSAMEX American ExpressCHECKING CheckingDISCOVER DiscoverMASTERCARD Master CardMONEYMARKET Money MarketSAVINGS SavingsUNKNOWN UnknownVISA Visa

INSTRTYPE IBY_INSTRUMENT_TYPES IBY_LOOKUPSBANKACCOUNT Bank AccountBOTH Credit Card or Bank AccountCREDITCARD Credit Card


ACCTTYPEID (PK) NOT NULL VARCHAR2(240) AccountType identifierACCTTYPE NULL VARCHAR2(240) Indicates the type of Accounts

e.g CHECKING, SAVING, VISA,AMEX etc. It is a lookup codefor LOOKUP TYPE IBY_ACCT_TYPE.

INSTRTYPE NULL VARCHAR2(30) Indicates different instrumenttypes e.g bank account, creditcard etc. It is a lookup codefor lookup typeIBY_INSTRUMENT_TYPES.

LAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnOBJECT_VERSION_NUMBER NOT NULL NUMBER This column is used for locking


LAST_UPDATED_BY NOT NULL NUMBER(15) Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnCREATED_BY NOT NULL NUMBER(15) Standard Who ColumnLAST_UPDATE_LOGIN NULL NUMBER(15) Standard Who Column

IndexesIndex Name Index Type Sequence Column Name

IBY_ACCTTYPE_ACCTTYPEID_U1 UNIQUE 5 ACCTTYPEID



SequencesSequence Derived Column

IBY_ACCTTYPE_S ACCTTYPEID



IBY_ACTIVITY

IBY_ACTIVITY stores scheduler related activities.


JTF_ACT_ACTIVITY_LOGS_ID NOT NULL NUMBER JTF Activity Log IdentifierAPPLICATION_ID NOT NULL NUMBER Application IdentifierACTIVITY_NAME_ID NOT NULL NUMBER Activity Name Identifier which

logs this activityJTF_ACT_ACTIVITY_LOGS_USER_ID NULL NUMBER JTF Activity Log User

IdentifierCOMPONENT NULL VARCHAR2(255) Subcomponent of the Loging

activityCOLUMN1 NULL VARCHAR2(255) the columns which stores the

values of activities.COLUMN2 NULL VARCHAR2(255) the columns which stores the






















values of activities.



COLUMN24 NULL VARCHAR2(255) the columns which stores thevalues of activities.







COLUMN31 NULL VARCHAR2(255) v“the columns which stores thevalues of activities.










CREATED_BY NOT NULL NUMBER Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnLAST_UPDATED_BY NOT NULL NUMBER Standard Who ColumnLAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnLAST_UPDATE_LOGIN NULL NUMBER Standard Who ColumnOBJECT_VERSION_NUMBER NULL NUMBER This column is used for locking



IBY_ACT_ACTIVITY_NAME_ID_N1 NOT UNIQUE 5 ACTIVITY_NAME_IDIBY_ACT_JTF_ACT_ACT_LOGS_ID_U1 UNIQUE 5 JTF_ACT_ACTIVITY_LOGS_ID


IBY_ACTIVITY_S JTF_ACT_ACTIVITY_LOGS_ID



IBY_BANKACCT

IBY_BANKACCOUNT keeps bank account related information of thecustomer(payer) or payee.


HZ_LOCATIONS LOCATION_ID ADDRESSIDIBY_ACCTTYPE ACCTTYPEID ACCTTYPEID


INSTRID NOT NULL NUMBER(15) System generated idBANKACCOUNTID NOT NULL VARCHAR2(30) Bank Account numberADDRESSID NULL NUMBER Address identifier, FK to

HZ_LOCATIONS table.FINAME NULL VARCHAR2(80) Financial Institution NameACCTTYPEID NOT NULL NUMBER Accttype identifier, FK to

iby_accttypeBRANCHNAME NULL VARCHAR2(30) Branch NameROUTINGNO NULL VARCHAR2(25) Routing NumberDESCRIPTION NULL VARCHAR2(240) Description of the instrumentsINSTRNAME NULL VARCHAR2(80) Name of the instrumentACCOUNT_HOLDER_NAME NULL VARCHAR2(80) Account Holder NameLAST_UPDATED_BY NOT NULL NUMBER(15) Standard Who ColumnsLAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnsCREATION_DATE NOT NULL DATE Standard Who ColumnsCREATED_BY NOT NULL NUMBER(15) Standard Who ColumnsLAST_UPDATE_LOGIN NULL NUMBER(15) Standard Who ColumnsOBJECT_VERSION_NUMBER NOT NULL NUMBER This column is used for locking



IBY_BANKACCT_INSTRID_U1 UNIQUE 5 INSTRID


IBY_INSTR_S INSTRID



IBY_BATCHES_ALL

IBY_BATCHES holds the information about batch operations for SSLcredit card transactions. A terminal based merchant will need to havebatch operations. The status of the payees batch will be contained in thistable.


IBY_BEPINFO BEPID BEPIDIBY_PAYEE MPAYEEID MPAYEEID


BATCHSTATEID IBY_BATCH_STATE IBY_LOOKUPS0 Batch–Accepted1 Batch–Sent2 Batch–Queued3 Batch–Rejected4 Batch–Processed5 Batch–Error–At–cc6 Batch–Not–Found7 Batch–Unknown


MBATCHID NOT NULL NUMBER(15) System generated BatchIdentifier

BATCHID NOT NULL VARCHAR2(80) Batch id provided by ElectronicCommerce Application

PAYEEID NULL VARCHAR2(80) Id of the payee passed byElectronic Commerce Application

BEPID NULL NUMBER Back End Payment Systemidentifier

MPAYEEID NULL NUMBER Payee identifierECAPPID NULL NUMBER Electronic Commerce Application

identifierPAYMENTMETHODNAME NULL VARCHAR2(80) Name of the payment methodBATCHSTATUS NULL NUMBER Status of the batchBATCHCLOSEDATE NULL DATE close date of this batch.NUMTRXNS NULL NUMBER number of transactions in this

batchBATCHSTATEID NULL NUMBER(15) Denotes state of the batch.

Various batch states are:0–batch–accepted, 1–batch–sent,2–batch–queued,3–batch–rejected,4–batch–processe ,5–batch–error–at–cc,6–batch–not–found,7–batch–unknown etc.

BATCHTOTAL NULL NUMBER total net amount for thisbatch

BATCHSALES NULL NUMBER total inflow



BATCHCREDIT NULL NUMBER it is the total outflow andincludes return and credittransaction amounts.

CURRENCYNAMECODE NULL VARCHAR2(15) three letter ISO currency codefor this batch

VPSBATCHID NULL VARCHAR2(80) Batchid from Back End PaymentSystem

GWBATCHID NULL VARCHAR2(80) Batchid from GatewayERRORLOCATION NULL NUMBER indicates the location of errorBEPCODE NULL VARCHAR2(80) Error code from Back End

Payment SystemBEPMESSAGE NULL VARCHAR2(80) Error messages from Back End

Payment SystemBATCHOPENDATE NULL DATE date batch is openedREQTYPE NULL VARCHAR2(20) type of request such as

closebatch, purgebatch,openbatch etc

REQDATE NULL DATE date when the batch operationrequest is received

DESTURL NULL VARCHAR2(1024) used for storing theconstructed Back End PaymentSystem url during schedule ofPayments

TERMINALID NULL VARCHAR2(80) used for credit cardprocessing. A merchant can getmultiple terminal Ids andthere is a batch open for eachTerminal Id. The merchant couldperform operations on thosebatches independantly.

ACQUIRER NULL VARCHAR2(80) the merchant bank which may beoptionally returned.

NLSLANG NULL VARCHAR2(80) NLS LanguageNEEDSUPDT NULL VARCHAR2(3) flag to identify the rows that

has changed status. Used bySchedular



LAST_UPDATED_BY NOT NULL NUMBER(15) Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnCREATED_BY NOT NULL NUMBER(15) Standard Who ColumnLAST_UPDATE_LOGIN NULL NUMBER(15) Standard Who ColumnORG_ID NULL NUMBER(15) Organization Identifier


IBY_BATCHES_BATCHID_PAYEEID_U1 UNIQUE 5 BATCHID6 PAYEEID

IBY_BATCHES_MBATCHID_U2 UNIQUE 5 MBATCHID


IBY_BATCHES_S MBATCHID



IBY_BATCHES_ALL_V

IBY_BATCHES_ALL view allows a merchant or business to view Batchdetails.

View DefinitionCREATE VIEW IBY_BATCHES_ALL_V as SELECT bat.batchid merchbatchid, bat.batchstatus, pyee.name payeename, bat.batchclosedate, bep.name bepname, bat.vpsbatchid, bat.numtrxns, lk.meaning batchstate, bat.batchtotal, bat.batchsales, bat.batchcredit, bat.paymentmethodname, bat.org_id

FROM IBY_BATCHES_ALL BAT , FND_LOOKUP_VALUES LK , IBY_PAYEE PYEE , IBY_BEPINFO BEP Where bat.bepid = bep.bepid(+) and bat.payeeid = pyee.payeeid(+) and bat.batchstateid = lk.lookup_code(+) and lk.lookup_type = ’IBY_BATCH_STATE’ and language = userenv(’LANG’) and security_group_id = fnd_global.lookup_security_group (lookup_type, view_application_id)


MERCHBATCHID NOT NULL VARCHAR2(240) Batch identiferBATCHSTATUS NULL NUMBER Status of the batchPAYEENAME NULL VARCHAR2(240) NAME is name of the PayeeBATCHCLOSEDATE NULL DATE BATCHCLOSEDATE is close date of

this batch.BEPNAME NULL VARCHAR2(240) Name of the Back end Payment

system like Cybercash, Verifoneetc

VPSBATCHID NULL VARCHAR2(240) VPSBatchID is the batchid fromBEP

NUMTRXNS NULL NUMBER NUMTRXNS is number oftransactions in this batch



BATCHSTATE NULL VARCHAR2(240) BATCHSTATE denotes state ofthe batch. Various batchstates are: batch–accepted0 batch–sent1,batch–queued2,batch–rejected3,batch–processed 4 (not usedcurrently) batch–error–at–cc5,batch–not–found6,batch–unknown 7.

BATCHTOTAL NULL NUMBER BATCHTOTAL is the total net forthis batch

BATCHSALES NULL NUMBER BATCHSALES is the total inflowBATCHCREDIT NULL NUMBER BATCHCREDIT is the total

outflow and includes return andcredit transaction amounts.

PAYMENTMETHODNAME NULL VARCHAR2(240) Payment Method NameORG_ID NULL NUMBER Organization Identifier



IBY_BEPINFO

IBY_BEPINFO has a row for every BEP(Back End Payment System)configured in system. A BEP is a payment provider such as Cybercash,Verifone etc




BEPID (PK) NOT NULL NUMBER(15) Back End Payment Systemidentifier

NAME NOT NULL VARCHAR2(80) Name of the Back End PaymentSystem like Cybercash, Verifoneetc

BASEURL NOT NULL VARCHAR2(1024) URL to the Back End PaymentSystem

SUFFIX NOT NULL VARCHAR2(10) Three–letter Back End PaymentSystem suffix. This is uniqueper Back End Payment System

BEPUSERNAME NOT NULL VARCHAR2(80) Username for authenticatingfrom iPayment to Back EndPayment System.

BEPPASSWORD NOT NULL VARCHAR2(80) password for BEPUSERNAME.SUPPORTEDOP NULL NUMBER bitmap to denote operations

supported by Back End PaymentSystem

PSUSERNAME NULL VARCHAR2(80) username for authenticatingfrom Back End Payment System toiPayment

PSPASSWORD NULL VARCHAR2(80) password for PSUSERNAMEADMINURL NULL VARCHAR2(1024) URL to the native Back End

Payment System admin pagesLOGINURL NULL VARCHAR2(1024) loginurl to the Back End

Payment SystemLOGOUTURL NULL VARCHAR2(1024) logouturl to the Back End

Payment SystemSRVRIDIMMED NULL VARCHAR2(1) Flag indicating whether Server

ID is immediately sent or not.ACTIVESTATUS NULL VARCHAR2(1) Indicates whether Back End

Payment System is active or notLEADTIME NULL NUMBER lead time that is needed to

schedule the paymentHOLIDAYFILE NULL VARCHAR2(1) denotes support for holiday

fileFILESUPPORT NULL VARCHAR2(1) Flag indicating whether Y or NSECURITYSCHEME NULL NUMBER denotes whether HTML Page or

Wallet for invoice/payoperation

INSTRTYPE NULL VARCHAR2(30) Instrument TypeLAST_UPDATE_DATE NOT NULL DATE Standard Who Column



OBJECT_VERSION_NUMBER NOT NULL NUMBER This column is used for lockingpurposes that subsequentlyallows for checking if there is’dirty’ or old data on thescreen compared to what is inthe database. The situationoccurs when the HTMLapplication is an ’stateless’application.



IBY_BEPINFO_BEPID_U1 UNIQUE 5 BEPIDIBY_BEPINFO_NAME_U2 UNIQUE 5 NAMEIBY_BEPINFO_SUFFIX_U3 UNIQUE 5 SUFFIX


IBY_BEP_S BEPID



IBY_BEPKEYS

IBY_BEPKEYS contains a list of all the keys that identifies a payee orpayer with a Back End Payment System.


IBY_BEPINFO BEPID BEPID


OWNERID NOT NULL VARCHAR2(80) ID of the payer or payeeBEPID NOT NULL NUMBER(15) Back End Payment System

IdentifierKEY NOT NULL VARCHAR2(80) key of a payer or payee for

the Back End Payment SystemOWNERTYPE NULL VARCHAR2(30) denotes whether payer or payeeLAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnOBJECT_VERSION_NUMBER NOT NULL NUMBER This column is used for locking





IBY_BEPLANGS

IBY_BEPLANGS contains list of all the languages supported by theBack End Payment System




BEPID NOT NULL NUMBER Back End Payment Systemidentifier

BEPLANG NOT NULL VARCHAR2(80) language supported by the BackEnd Payment System

PREFERRED NOT NULL NUMBER denotes whether this is thepreferred language of the BackEnd Payment System

LAST_UPDATE_DATE NOT NULL VARCHAR2(240) Standard Who ColumnsOBJECT_VERSION_NUMBER NOT NULL NUMBER This column is used for locking


LAST_UPDATED_BY NOT NULL VARCHAR2(240) Standard Who ColumnsCREATION_DATE NOT NULL VARCHAR2(240) Standard Who ColumnsCREATED_BY NOT NULL VARCHAR2(240) Standard Who ColumnsLAST_UPDATE_LOGIN NULL VARCHAR2(240) Standard Who Columns



IBY_CREDITCARD

IBY_CREDITACRD stores Credit Card related information of thecustomer(payer) or payee.


HZ_LOCATIONS LOCATION_ID ADDRESSIDIBY_ACCTTYPE ACCTTYPEID ACCTTYPEID


INSTRID NOT NULL NUMBER(15) ID generated by the systemCCNUMBER NOT NULL VARCHAR2(30) Credit Card numberEXPIRYDATE NOT NULL DATE Expiry DateACCTTYPEID NOT NULL NUMBER Accttype identifier,FK to

iby_accttype tableADDRESSID NULL NUMBER Address identifier, FK to

HZ_LOCATIONS tableINSTRNAME NULL VARCHAR2(80) Name of the InstrumentDESCRIPTION NULL VARCHAR2(240) Description of the instrumentCHNAME NULL VARCHAR2(80) Card Holder NameFINAME NULL VARCHAR2(80) Financial Institution NameLAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnLAST_UPDATED_BY NOT NULL NUMBER Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnCREATED_BY NOT NULL NUMBER Standard Who ColumnLAST_UPDATE_LOGIN NULL NUMBER Standard Who ColumnOBJECT_VERSION_NUMBER NOT NULL NUMBER This column is used for locking



IBY_CREDITCARD_INSTRID_U1 UNIQUE 5 INSTRID


IBY_INSTR_S INSTRID



IBY_DEFAULT_BEP

IBY_DEFAULT_BEP contains the default Back End Payment Systeminformation. Based on the instrument type the payment request getsrouted to this Back End Payment System.






INSTRTYPE NULL VARCHAR2(30) Type of Instrument supported byBack End Payment System

BEPID NOT NULL NUMBER(15) Back End Payment Systemidentifier






IBY_ECAPP

IBY_ECAPP stores information about Electronic CommerceApplications registered with iPayment.


ECAPPID (PK) NOT NULL NUMBER(15) Electronic Commerce Applicationidentifier

NAME NOT NULL VARCHAR2(80) Electronic Commerce Applicationname

APPLICATION_SHORT_NAME NOT NULL VARCHAR2(50) Application Short NameLAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnOBJECT_VERSION_NUMBER NOT NULL NUMBER This column is used for locking




IBY_ECAPP_APPSHORTNAME_U2 UNIQUE 5 APPLICATION_SHORT_NAMEIBY_ECAPP_ECAPPID_U1 UNIQUE 5 ECAPPID


IBY_ECAPP_S ECAPPID



IBY_INSTRHOLDER

IBY_INSTRHOLDER stores the information about the holder of theinstrment. A payment instrument can be held by different users orpayees or payers.


IBY_BANKACCT INSTRID INSTRIDIBY_CREDITCARD INSTRID INSTRID




INSTRID NOT NULL NUMBER Instrument identifier, FK toinstrument tables(iby_creditcard, iby_bankacct).

INSTRTYPE NOT NULL VARCHAR2(30) Instrument typeOWNERID NOT NULL VARCHAR2(80) referes to ID of the payee or

payer of the instrumentOWNERTYPE NOT NULL VARCHAR2(20) refers to either payee or payerACTIVESTATUS NULL NUMBER(1) referes to whether the

instrument is active or not inthe system

LAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnLAST_UPDATED_BY NOT NULL NUMBER Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnCREATED_BY NOT NULL NUMBER Standard Who ColumnLAST_UPDATE_LOGIN NULL NUMBER Standard Who ColumnOBJECT_VERSION_NUMBER NOT NULL NUMBER This column is used for locking



IBY_INSTRHOLDER_INSTRID_U1 UNIQUE 5 INSTRID



IBY_IRF_PMT_AMOUNT

IBY_IRF_PMT_AMOUNT stores information pertaining to the paymentamount risk factor involved in the payment request. A paymentrequest that has huge amount is possibly a fraudulent payment. Butthe value of the amount varies from business to business. Merchantscan set up a ranges of amount risk factor . Each range is associated witha risk score – low, medium_low, medium , medium_high and high.


IBY_PAYEE PAYEEID PAYEEID


LOWER_LIMIT NULL NUMBER Lower limit of payment amount.Customer payment amount shouldbe equal to or greater then thelower limit.

SEQ NOT NULL NUMBER(15) Seq order of the rangesUPPER_LIMIT NULL NUMBER Upper limit of payment amount.

Customer payment amount shouldbe less then the upper limitamount and greater then lowerlimit.

SCORE NOT NULL VARCHAR2(30) LOV of possible risk scores :low risk, medium low risk,medium risk, medium high risk,or high risk for a particularrange of limits in terms ofmaking payments forgoods/services he orders.

PAYEEID NULL VARCHAR2(80) id of the payee passed byElectronic Commerce Application






IBY_IRF_PMT_FREQUENCY

IBY_IRF_PMT_HISTORY stores information pertaining to the paymentfrequency risk factor. It has information about the frequency of aymentsmade in the given time frame (duration) .




DURATION_TYPE IBY_DURATION_TYPE IBY_LOOKUPSD DaysM MonthsW WeeksY Years


DURATION NOT NULL NUMBER(15) Number of days or weeksDURATION_TYPE NOT NULL VARCHAR2(15) LOV : days, weeksFREQUENCY NOT NULL NUMBER No of payments made during the

specified durationPAYEEID NULL VARCHAR2(80) id of the payee passed by

electronic commerce applicationLAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnOBJECT_VERSION_NUMBER NOT NULL NUMBER This column is used for locking





IBY_IRF_PMT_HISTORY

IBY_IRF_PMT_HISTORY stores information pertaining to the paymenthistory risk factor. Merchants can set up different time ranges–whichthey consider risky.






ID (PK) NOT NULL NUMBER(15) Unique ID generated by thesystem

DURATION NOT NULL NUMBER(15) Number of months or yearDURATION_TYPE NOT NULL VARCHAR2(15) LOV: months or yearsPAYEEID NULL VARCHAR2(80) id of the payee passed by



LAST_UPDATED_BY NOT NULL NUMBER(15) Standard Who ColumnCREATED_BY NOT NULL NUMBER(15) Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnLAST_UPDATE_LOGIN NULL NUMBER(15) Standard Who Column


IBY_IRF_PMT_HISTORY_ID_U1 UNIQUE 5 ID


IBY_IRF_PMT_HISTORY_S ID



IBY_IRF_PMT_HIST_RANGE

IBY_IRF_PMT_HISTORY_RANGE stores the frequency rangesinformation pertaining to the payment history risk factor. The customercan setup multiple frequency ranges for a specific duration.


IBY_IRF_PMT_HISTORY ID PAYMENT_HIST_ID


PAYMENT_HIST_ID NOT NULL NUMBER(15) ID associated with paymenthistory

FREQUENCY_HIGH_RANGE NULL NUMBER Higher limit of purchasefrequency.

FREQUENCY_LOW_RANGE NULL NUMBER Lower limit of purchasefrequency

SEQ NOT NULL NUMBER(15) Sequence Order of PaymentHistory Range

SCORE NOT NULL VARCHAR2(30) LOV of possible risk scores :low risk, medium risk, highrisk for a particular range offrequency limits






IBY_IRF_RISKY_INSTR

IBY_IRF_RISKY_INSTR stores information pertaining to the riskinstrument risk factor. It has information about the merchant who sendsthe file of risky instruments, the type of instrument and other accountinformation pertaining to the risky instrument.






PAYEEID NULL VARCHAR2(80) id of the payee passed byelectronic commerce application

INSTRTYPE NOT NULL VARCHAR2(30) Intrument Type. Bank Account,Credit Card etc

ROUTING_NO NULL VARCHAR2(80) Bank ID to which the accountbelongs

ACCOUNT_NO NULL VARCHAR2(80) Bank Account NumberCREDITCARD_NO NULL VARCHAR2(80) Credit Card NumberLAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnOBJECT_VERSION_NUMBER NOT NULL NUMBER This column is used for locking




IBY_IRF_RISKY_INSTR_PAYEEID_N1 NOT UNIQUE 5 PAYEEID



IBY_IRF_TIMEOF_PURCHASE

IBY_IRF_TIMEOF_PURCHASE stores information pertaining to thetime of purchase risk factor. The merchant can set up different timeranges–and associate a risk score of low risk, medium low risk, mediumrisk, medium high risk and high risk.




DURATION_FROM NOT NULL VARCHAR2(8) Stores the begining time HH:MMof the duration range

SEQ NOT NULL NUMBER(15) Seq order of the time rangeDURATION_TO NOT NULL VARCHAR2(8) Stores the end time HH:MM of

the purchaser rangeSCORE NOT NULL VARCHAR2(30) LOV of possible risk scores :

low risk, medium low risk,medium risk, medium high risk,or high risk.

PAYEEID NULL VARCHAR2(80) id of the payee passed byelectronic commerce application



LAST_UPDATED_BY NOT NULL NUMBER Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnCREATED_BY NOT NULL NUMBER Standard Who ColumnLAST_UPDATE_LOGIN NULL NUMBER Standard Who Column



IBY_IRF_TRXN_AMT_LIMIT

IBY_IRF_TRXN_AMT_LIMITstores information pertaining to thetransaction amount limit risk factor. It is a limit on the total amount ofpayments made using the same instrument in a particular duration.






DURATION NOT NULL NUMBER Number of days, weeks, monthsor year

DURATION_TYPE NOT NULL VARCHAR2(15) LOV : days, weeks, month, yearsAMOUNT NOT NULL NUMBER Transaction Amount limitPAYEEID NULL VARCHAR2(80) id of the payee passed by



CREATED_BY NOT NULL NUMBER(15) Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnLAST_UPDATED_BY NOT NULL NUMBER(15) Standard Who ColumnLAST_UPDATE_LOGIN NULL NUMBER(15) Standard Who Column



IBY_MAPPINGS

IBY_MAPPINGS stores mapping of codes with risk scores. Each rowincludes a code and a value for that code.


MAPPING_TYPE NOT NULL VARCHAR2(30) Mapping Code type e.g avs,riskcode, credit rating

MAPPING_CODE NOT NULL VARCHAR2(30) Mapping CodeVALUE NOT NULL VARCHAR2(240) Value of a lookup codeDESCRIPTION NULL VARCHAR2(240) Description of the quick codeSEQ NULL NUMBER(5) sequenceLAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnOBJECT_VERSION_NUMBER NOT NULL NUMBER This column is used for locking


PAYEEID NULL VARCHAR2(80) PayeeID is the id of the payeepassed by ecapplication



IBY_MAPPINGS_TYPE_CODE_U1 UNIQUE 5 MAPPING_TYPE7 PAYEEID

11 MAPPING_CODE



IBY_PAYEE

IBY_PAYEE holds a row for each payee such as a biller ormerchant/store at this site.


IBY_ECAPP ECAPPID ECAPPID


MPAYEEID NOT NULL NUMBER(15) System generated PayeeIdentifier

PAYEEID NOT NULL VARCHAR2(80) Payee Identifier passed byECApplication

NAME NOT NULL VARCHAR2(80) name of the payeeECAPPID NOT NULL NUMBER(15) Electronic Applicatin

identifierUSERNAME NULL VARCHAR2(80) username for authenticationPASSWORD NULL VARCHAR2(80) password for the username aboveACTIVESTATUS NOT NULL VARCHAR2(1) ACTIVESTATUS is 1 if the

merchant is active, 0otherwise.

THRESHOLD NULL NUMBER(15) threshold value to checkagainst the overall risk score

RISK_ENABLED NULL VARCHAR2(1) flag that indicates whether toenable risk management featureor not

SUPPORTEDOP NULL NUMBER bit map to denote operationssupported by the payee.



LAST_UPDATED_BY NOT NULL NUMBER Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnCREATED_BY NOT NULL NUMBER Standard Who ColumnLAST_UPDATE_LOGIN NULL NUMBER Standard Who Column


IBY_PAYEE_MPAYEEID_U2 UNIQUE 5 MPAYEEIDIBY_PAYEE_PAYEEID_U1 UNIQUE 5 PAYEEID


IBY_PAYEE_S MPAYEEID



IBY_PMTMTHD_CONDITIONS

IBY_PMTMTHD_CONDITIONS contains the conditions for thepayment method. Each condition is composed of a parameter, operationand value. The condition is evaluated at runtime to check if thecondition is satisfied


IBY_ROUTINGINFO PAYMENTMETHODID PAYMENTMETHODID


OPERATION_CODE IBY_OPERATIONS IBY_LOOKUPSEQ Equal toGE Greater than or equal toGT Greater thanLE Less than or equal toLT Less thanNE Not equal to

PARAMETER_CODE IBY_PARAMETERES IBY_LOOKUPSAMOUNT AmountINSTR_TYPE Instrument Type


PAYMENTMETHODID NOT NULL NUMBER(15) Payment Method IdentifierPARAMETER_CODE NOT NULL VARCHAR2(30) contains AMOUNT or INSTRTYPEOPERATION_CODE NOT NULL VARCHAR2(15) contains EQUALS, NEQUALS etcVALUE NULL VARCHAR2(30) contains the value for the

conditionIS_VALUE_STRING NULL VARCHAR2(1) denotes if the value is a

number or character. This isused internally for conversions

ENTRY_SEQUENCE NULL NUMBER(4) number which denotes the orderin which the admin user hasentered the conditions. Whenqueried, it needs to bedisplayed in the same orderthat the user has entered






IBY_PMTSCHEMES

IBY_PMTSCHEMES contains a list of Payment Schemes that will besupported by a BEP SSL: the BEP will conform to the PS10 VAPI SET: theBEP will conform to the PS11 VAPI BANCACCOUNT or FI




PMTSCHEMEID IBY_PMTSCHEMES IBY_LOOKUPS1 SET2 SSL3 FI4 BANKACCOUNT


BEPID NOT NULL NUMBER Bep identifierPMTSCHEMEID NOT NULL NUMBER(15) Payment Scheme identifierPMTSCHEMENAME NOT NULL VARCHAR2(30) Name of the Payment Scheme :

SSL,SET,Bank Account or FILAST_UPDATED_BY NOT NULL NUMBER(15) Standard Who ColumnLAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnCREATED_BY NOT NULL NUMBER(15) Standard Who ColumnLAST_UPDATE_LOGIN NULL NUMBER(15) Standard Who ColumnOBJECT_VERSION_NUMBER NOT NULL NUMBER(5) This column is used for locking



IBY_PMTSCHEMEID_BEPID_U1 UNIQUE 5 PMTSCHEMEID7 BEPID


IBY_PMTSCHEMES_S PMTSCHEMEID



IBY_RISK_FACTORS

IBY_RISK_FACTORS stores information about the Risk Factors. Theseare factors which a merchant deems fit to use to evaluate the risk of thecustomer who wants to purchase its goods and services. RiskManagement feature will contain bundled risk factors which can be setup at the site level.


RISK_FACTOR_CODE IBY_RISK_FACTOR_NAME IBY_LOOKUPSAVSCODES AVS CodesCREDITRATINGCODES Oracle Receivablels Credit

Rating CodesFREQOFPURCHASE Frequency of PurchaseOVERALLCREDITLIMIT Oracle Receivables Overall

Credit LimitPMTAMOUNT Payment Amount LimitPMTHISTORY Payment HistoryRISKCODES Oracle Receivables Risk

CodesRISKINSTRUMENTS Risky InstrumentsSHIPTO/BILLTO Ship To/ Bill To addressTIMEOFPURCHASE Time of PurchaseTRXNAMOUNT Transaction AmountTRXNCREDITLIMIT OracleReceivables Transac-

tional Credit Limit


RISK_FACTOR_ID (PK) NOT NULL NUMBER(15) ID generated by the System touniquely identify a particularRisk Factor

RISK_FACTOR_CODE NOT NULL VARCHAR2(30) Look up type to fnd_lookupsFACTOR_TYPE NOT NULL NUMBER(15) Risk Factor TypeINTERFACE_NAME NULL VARCHAR2(240) Class Name of the object ,

which will be loadeddynamically at runtime.

LAST_UPDATED_BY NOT NULL NUMBER(15) Standard Who ColumnOBJECT_VERSION_NUMBER NOT NULL NUMBER(5) This column is used for locking


LAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnCREATED_BY NOT NULL NUMBER(15) Standard Who ColumnLAST_UPDATE_LOGIN NULL NUMBER(15) Standard Who Column


IBY_RISK_FACTORS_FACTORID_U1 UNIQUE 2 RISK_FACTOR_ID



IBY_RISK_FACTOR_NAME_U2 UNIQUE 5 RISK_FACTOR_CODE


IBY_RISK_FACTORS_S RISK_FACTOR_ID



IBY_RISK_FORMULAS

IBY_RISK_FORMULAS stores risk formula retaled information . RiskFormula is used by merchants to evaluate the risk of the customer. Thisformula could be different for different goods/services offered by themerchants. A Risk Formula may be comprised of multiple risk factorswith varying weights assigned to each one.


RISK_FORMULA_ID (PK) NOT NULL NUMBER(15) ID generated by the System touniquely identify a particularRisk Formula

FORMULA_NAME NOT NULL VARCHAR2(80) Risk Formula NameDESCRIPTION NULL VARCHAR2(240) Description of the Risk FormulaPAYEEID NOT NULL VARCHAR2(80) Payee associated with this risk

formulaIMPLICIT_FLAG NULL NUMBER(2) Flag that indicates if the

formula is implicit or not.Valid values are 0,1’.





IBY_RISK_FORMULA_ID_U2 UNIQUE 5 RISK_FORMULA_ID


IBY_RISK_FORMULAS_S RISK_FORMULA_ID



IBY_RISK_FORMULA_ITEM

IBY_RISK_FORMULA_ITEM table is an intersection table between theIBY_RISK_FORMULA and IBY_RISK_FACTORS. It stores weight fordifferent Risk Factors. Weight is a number indicating the degree ofimportance assigned to a particular Risk Factor. Different merchantsmay assign different weights for the same Risk Factor even if they areoffering the same goods and services to the customer. Weights would bein the range of 0 (no weight) to 100 (full weight). Each Weight isidentified by a unique id, generated by the system.


IBY_RISK_FACTORS RISK_FACTOR_ID RISK_FACTOR_IDIBY_RISK_FORMULAS RISK_FORMULA_ID RISK_FORMULA_ID


WEIGHT NOT NULL NUMBER(15) Weights would be in the rangeof 0 (no weight) to 100 (fullweight)

RISK_FORMULA_ID NOT NULL NUMBER(15) Risk Formula defining columnRISK_FACTOR_ID NOT NULL NUMBER(15) Risk Factor defining columnLAST_UPDATED_BY NOT NULL VARCHAR2(240) Standard Who ColumnOBJECT_VERSION_NUMBER NOT NULL NUMBER(5) This column is used for locking


LAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnCREATED_BY NOT NULL VARCHAR2(240) Standard Who ColumnLAST_UPDATE_LOGIN NULL VARCHAR2(240) Standard Who Column


IBY_RISK_FORMULAID_FACORTID_U1 UNIQUE 5 RISK_FACTOR_ID10 RISK_FORMULA_ID



IBY_ROUTINGINFO

IBY_ROUTINGINFO contains information that maps routing rule name(payment method name) with the Back End Payment System.


IBY_BEPINFO BEPID BEPIDIBY_PAYEE MPAYEEID MPAYEEID


PAYEEID NULL VARCHAR2(80) id of the payee passed byElectronic Commerce Application

BEPID NOT NULL NUMBER(15) Back End Payment SystemIdentifier

PAYMENTMETHODID NOT NULL NUMBER(15) System Generated IdPAYMENTMETHODNAME NOT NULL VARCHAR2(80) name of the payment methodMPAYEEID NULL NUMBER Payee IdentifierCONFIGURED NOT NULL NUMBER(2) indicates whether payment

method is active or not. 1 isactive and 0 is inactive

PRIORITY NULL NUMBER(15) denotes the order in which thepayment methods are selected

LAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnOBJECT_VERSION_NUMBER NOT NULL NUMBER(5) This column is used for locking




IBY_RTINFO_PAYMENTMETHODID_U1 UNIQUE 5 PAYMENTMETHODID


IBY_PMTMETHOD_S PAYMENTMETHODID



IBY_TANGIBLE

IBY_TANGIBLE storesInformation about the bills or orders is stored inthis table.


MTANGIBLEID (PK) NOT NULL NUMBER(15) system generated ID, this idis exposed to Electronicapplication unlike others

TANGIBLEID NOT NULL VARCHAR2(80) bill or orderidAMOUNT NOT NULL NUMBER AmountCURRENCYNAMECODE NOT NULL VARCHAR2(15) code for currency name such

USDACCTNO NULL VARCHAR2(80) customer account number with

the biller or merchantREFINFO NULL VARCHAR2(80) any reference information

passed by the ElectronicCommerce Application

MEMO NULL VARCHAR2(80) memo for the paymentLAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnOBJECT_VERSION_NUMBER NOT NULL NUMBER(5) This column is used for locking


LAST_UPDATED_BY NOT NULL NUMBER(15) Standard Who ColumnCREATED_BY NOT NULL NUMBER(15) Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnLAST_UPDATE_LOGIN NULL NUMBER(15) Standard Who Column


IBY_TANGIBLE_MTANGIBLEID_U1 UNIQUE 5 MTANGIBLEID


IBY_TANGIBLE_S MTANGIBLEID



IBY_TRANS_ALL_V

IBY_TRANS_ALL view allows a merchant or business to viewtransactional detail.

View DefinitionCREATE VIEW IBY_TRANS_ALL_V as SELECT tall.TransactionId, tall.TangibleId, tall.PayeeId, tall.BEPID, tall.ECAppID, tall.trxnMID, tall.amount, tall.CurrencyNameCode, tall.ReqDate, tall.ReqType, tall.Status, tall.SettleDate, tall.UpdateDate, tall.TrxnTYpeid, tall.ErrorLocation, tall.BEPCode, tall.BEPMessage, tall.BatchID , tall.NeedsUpdt, tall.org_id, tall.paymentmethodname, tall.mtangibleid, tall.detaillookup, tall.reqseq, tall.desturl, tall.nlslang, tcore.terminalid, tcore.tracenumber, ltrim(rtrim(tcore.authcode)) authcode, tcore.referencecode, tcore.operationcode, tcore.instrname, tcore.authtype, tcore.avscode, tcore.acquirer, tcore.auxmsg, tan.acctno, tan.refinfo, tan.memo

FROM IBY_TRXN_SUMMARIES_ALL TALL



, IBY_TRXN_CORE TCORE , IBY_TANGIBLE TAN Where tall.trxnmid = tcore.trxnmid and tall.mtangibleid = tan.mtangibleid


TRANSACTIONID NOT NULL NUMBER TRANSACTIONID is the IDgenerated for each paymentrequest (orapmtreq) and passedback to ECApp.

TANGIBLEID NOT NULL VARCHAR2(80) TANGIBLEID is the bill or orderID

PAYEEID NOT NULL VARCHAR2(80) Payee IdentifierBEPID NOT NULL NUMBER(15) BEP IdentifierECAPPID NOT NULL NUMBER(15) ECAPP IdentifierTRXNMID NOT NULL NUMBER(15) TRXNMID is system generated IDAMOUNT NULL NUMBER(15) Transaction AmountCURRENCYNAMECODE NULL VARCHAR2(15) CURRENCYNAMECODE is the code

for currency name such USDREQDATE NULL DATE REQDATE is the date when the

batch operation request isreceived

REQTYPE NULL VARCHAR2(20) REQTYPE is the type of requestsuch as closebatch, purgebatch,openbatch

STATUS NULL NUMBER Status of the transactionSETTLEDATE NULL DATE SETTLEDATE is the scheduled

date for the bill or order usedfor offline payments only

UPDATEDATE NULL DATE UPDATEDATE is the datescheduled payment is updated

TRXNTYPEID NULL NUMBER(15) The TRXTYPE columns is a Lookupcode for lookup typeIBY_TRXNTYPES

ERRORLOCATION NULL NUMBER ERRORLOCATION is numeric codefor where the error occured.

BEPCODE NULL VARCHAR2(40) BEPCODE is any BEP specificcode

BEPMESSAGE NULL VARCHAR2(240) BEPMESSAGE is Payment Systemspecific message

BATCHID NULL VARCHAR2(80) Batch IdentifierNEEDSUPDT NULL VARCHAR2(3) NEEDSUPDT is a flag to identify

the rows that has changedstatus. Used by Schedular

ORG_ID NULL NUMBER Organization IdentifierPAYMENTMETHODNAME NULL VARCHAR2(240) Payment Method NameMTANGIBLEID NULL VARCHAR2(240) MTANGIBLEID is the master id

that points to iby_tangibletable for additionalinformation about tangible

DETAILLOOKUP NULL VARCHAR2(240) DETAILLOOKUP is a lookup columnfor CORE, EXTENDED or FI

REQSEQ NULL VARCHAR2(240) Request SequenceDESTURL NULL VARCHAR2(240) DESTURL is used for storing the

constructed bep url duringschedule of Payments

NLSLANG NULL VARCHAR2(240) NLS Language



TERMINALID NULL VARCHAR2(240) Terminal Id is a concept forcredit card processing. Amerchant can get multipleterminal Ids and there is abatch open for each TerminalId. The merchant couldperform operations on thosebatches independantly.

TRACENUMBER NULL VARCHAR2(240) Unique Transaction id forpayworks BEP follow–ontransactions

AUTHCODE NULL VARCHAR2(240) AUTHCODE is the authorizationcode received from Credit CardProcessing System forauthorization.

REFERENCECODE NULL VARCHAR2(240) REFERENCECODE is any referencecode received from PaymentSystems or processing systemwhich can be used forreference.

OPERATIONCODE NULL VARCHAR2(240) OPERATIONCODE is generic codefor any operation such as auth,capture etc

INSTRNAME NULL VARCHAR2(240) INSTRNAME is the paymentinstrument name such as Visa,MasterCard etc.

AUTHTYPE NULL VARCHAR2(240) AUTHTYPE denotes whetherauthorization is authonly orauthcapture.

AVSCODE NULL VARCHAR2(240) AVSCODE is the AddressVerification Code from paymentsystems.

ACQUIRER NULL VARCHAR2(240) ACQUIRER is the merchant bankwhich may be optionallyreturned.

AUXMSG NULL VARCHAR2(240) AUXMSG is any auxillary messagethat may be returned by thepayment system or processingsystem.

ACCTNO NULL VARCHAR2(240) ACCTNO is customer accountnumber with the biller ormerchant

REFINFO NULL VARCHAR2(240) REFINFO is any referenceinformation passed by the ECApp

MEMO NULL VARCHAR2(240) MEMO is any memo for thepayment



IBY_TRXN_CORE

IBY_TRXN_CORE contains the details of a payment request that arespecific for basic credit card operations.


IBY_TRXN_SUMMARIES_ALL TRXNMID TRXNMID


TRXNMID NOT NULL NUMBER Transaction IdentifierTERMINALID NULL VARCHAR2(80) used for credit card

processing. A merchant can getmultiple terminal Ids andthere is a batch open for eachTerminal Id. The merchant couldperform operations on thosebatches independantly.

TRACENUMBER NULL VARCHAR2(80) Unique Transaction id forpayworks Back End PaymentSystem follow–on transactions

AUTHCODE NULL VARCHAR2(80) authorization code receivedfrom Credit Card ProcessingSystem for authorization.

REFERENCECODE NULL VARCHAR2(80) reference code received fromBack End Payment Systems orprocessing system which can beused for reference.

OPERATIONCODE NULL VARCHAR2(80) generic code for any operationsuch as auth, capture etc

INSTRNAME NULL VARCHAR2(80) payment instrument name suchas Visa, MasterCard etc.

AUTHTYPE NULL VARCHAR2(20) denotes whether authorizationis authonly or authcapture.

AVSCODE NULL VARCHAR2(80) Address Verification Code fromback end payment systems.

ACQUIRER NULL VARCHAR2(80) merchant bank which may beoptionally returned by back endpayment system.

AUXMSG NULL VARCHAR2(255) auxillary message that may bereturned by the payment systemor processing system.

OBJECT_VERSION_NUMBER NOT NULL NUMBER(5) This column is used for lockingpurposes that subsequentlyallows for checking if there is’dirty’ or old data on thescreen compared to what is inthe database. The situationoccurs when the HTMLapplication is an ’stateless’application.

LAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnLAST_UPDATED_BY NOT NULL NUMBER(15) Standard Who ColumnCREATED_BY NOT NULL NUMBER(15) Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnLAST_UPDATE_LOGIN NULL NUMBER(15) Standard Who Column




IBY_TRXN_CORE_TRXNMID_U1 UNIQUE 5 TRXNMID



IBY_TRXN_EXTENDED

IBY_TRXN_EXTENDED contains the details of a payment request thatare specific for extended SET functionality for Credit Cards




TRXNMID NOT NULL NUMBER Transaction IdentifierSETTRXNID NULL VARCHAR2(80) transaction ID from Back End

Payment SystemAPPROVALCODE NULL VARCHAR2(80) SET approval code for an

operation. For example, forauth transaction it willcontain the authorization code

COMPLETIONCODE NULL VARCHAR2(80) additional SET status code forcompletion of transaction

SPLITID NULL NUMBER counter that indicates thesequence in the split shipment

TERMINALID NULL VARCHAR2(80) used for credit cardprocessing. A merchant can getmultiple terminal Ids andthere is a batch open for eachTerminal Id. The merchant could perform operations on thosebatches independantly.

SUBAUTHIND NULL NUMBER Subsequent auth indicatorCARDBIN NULL VARCHAR2(10) first 5 or 6 digits that

identifies the cardBATCHSEQNUM NULL NUMBER sequence of the transaction in

a batchBATCHTRXNSTATUS NULL NUMBER indicates the status of the

row if it is included in batchoperation

SETREQTYPE NULL NUMBER denotes whether pinit, preqSET request type

PREVSPLITID NULL NUMBER used during subsequentauthorization

SUBSAUTHTYPE NULL VARCHAR2(20) the authorization type forsubsequent authorization

SPLITSHIPMENT NULL NUMBER denotes yes/no for splittingthe shipment

AUTHCURRENCY NULL VARCHAR2(10) Authorized CurrencyAUTHPRICE NULL NUMBER Authorized PriceINSTALLTOTALTRXNS NULL NUMBER denotes number of installmentsRECURRINGFREQ NULL NUMBER denotes the frequency in number

of day of recurringauthorization

RECURRINGEXPDATE NULL DATE date for final installmentCUSTREFNUM NULL VARCHAR2(80) Customer Reference NumberDESTPOSTALCODE NULL VARCHAR2(10) Destination postal codeLOCALTAXPRICE NULL NUMBER Local tax priceLOCALTAXCURRENCY NULL VARCHAR2(10) Local Tax CurrencyCREDITCOUNTER NULL NUMBER indicates the ith return for

multiple returns




LAST_UPDATED_BY NOT NULL NUMBER(15) Standard Who ColumnLAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnCREATED_BY NOT NULL NUMBER(15) Standard Who ColumnLAST_UPDATE_LOGIN NULL NUMBER(15) Standard Who Column


IBY_TRXN_EXTENDED_TRXNMID_U1 UNIQUE 5 TRXNMID



IBY_TRXN_FI

IBY_TRXN_FI contains the details of a payment request that are specificfor systems that support both bank account transfers and credit cardssuch as Financial Institutions.




TRXNMID NOT NULL NUMBER Transaction IdentifierSPLITID NOT NULL NUMBER counter that indicates the

sequence in the split shipmentPSREQID NULL VARCHAR2(80) system generated ID that will

be sent to FI Back End PaymentSystems during schedule ofpayments with them

REFERENCECODE NULL VARCHAR2(80) referencecode from Back EndPayment System

AUXMSG NULL VARCHAR2(255) any auxillary message that maybe returned by the paymentsystem or processing system

SRVID NULL VARCHAR2(80) ID returned by Back EndPayment System when thepayment is scheduled

PROCESSFEE NULL NUMBER The fee charged for processinga transaction


LAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnLAST_UPDATED_BY NOT NULL NUMBER(15) Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnCREATED_BY NOT NULL NUMBER(15) Standard Who ColumnLAST_UPDATE_LOGIN NULL NUMBER(15) Standard Who Column


IBY_TRXN_FI_TRXNMID_U1 UNIQUE 5 TRXNMID


IBY_TRXNFI_PSREQID_S PSREQID



IBY_TRXN_SUMMARIES_ALL

IBY_TRXN_SUMMARIES_ALL contains information about eachpayment request. This table is used for both online and offlinepayment transactions. The information contained in this table is genericin nature to cover the various payment instruments and the operationson them. The specific details are stored in other detail tables such asIBY_TRXN_CORE, IBY_TRXN_EXTENDED and IBY_TRXN_FI basedon the type of operation and the payment instrument used for payment.


IBY_BATCHES_ALL MBATCHID MBATCHIDIBY_BEPINFO BEPID BEPIDIBY_PAYEE MPAYEEID MPAYEEIDIBY_TANGIBLE MTANGIBLEID MTANGIBLEID


STATUS IBY_TRANSACTION_STATUS IBY_LOOKUPS0 Transaction Completed Suc-

cessfully1 Communication Error11 Request Pending12 Schedule in Progress13 Request Scheduled14 Request Cancelled15 Failed to Schedule16 Payment System Failed17 Unable to Pay (Insufficient

funds)18 Request Submitted19 Invalid Credit Card Number2 Duplicate Order Id3 Duplicate Batch Id4 Mandatory Fields required5 Payment System Specific

error6 Batch partially succeded7 Batch failed8 Request action not supported

TRXNTYPEID IBY_TRXNTYPES IBY_LOOKUPS0 Inv1 ECPmt10 MarkReturn101 Split Auth102 Batch Admin11 Credit13 VoidCapture14 VoidMarkCapture17 VoidReturn



18 VoidMarkReturn2 AuthOnly3 AuthCapture4 VoidAuthOnly5 Return6 ECRefund7 VoidAuthCapture8 Capture9 MarkCapture


TRXNMID (PK) NOT NULL NUMBER system generated IDTRANSACTIONID NOT NULL NUMBER ID generated for each payment

request (orapmtreq) and passedback toElectronic CommerceApplication.

TANGIBLEID NOT NULL VARCHAR2(80) bill or order IDPAYEEID NOT NULL VARCHAR2(80) id of the payee passed by

Electronic Commerce ApplicationBEPID NOT NULL NUMBER(15) Back End Payment System

IdentifierMPAYEEID NOT NULL NUMBER Payee identifierECAPPID NOT NULL NUMBER(15) Electronic Commerce Application

IdentifierORG_ID NULL NUMBER(15) Organization identifierPAYMENTMETHODNAME NULL VARCHAR2(80) Payment Method NameMTANGIBLEID NOT NULL NUMBER master id that points to

iby_tangible table foradditional information abouttangible(orders)

PAYEEINSTRID NULL NUMBER Instrument id for the payeePAYERID NULL VARCHAR2(80) useridPAYERINSTRID NULL NUMBER Instrument id for the payerDETAILLOOKUP NULL VARCHAR2(30) lookup column for CORE,

EXTENDED or FI transactionsAMOUNT NULL NUMBER Transaction AmountINSTRNUMBER NULL VARCHAR2(60) Instrument number could be

Credit Card number(for 11i) incase of unregisteredinstruments.

CURRENCYNAMECODE NULL VARCHAR2(15) code for currency name suchUSD

STATUS NOT NULL NUMBER(15) Status of the transaction. Itis a lookup code for lookuptype IBY_TRANSACTION_STATUS

UPDATEDATE NULL DATE the date scheduled payment isupdated

TRXNTYPEID NULL NUMBER(15) The TRXTYPE columns is a Lookupcode for lookup typeIBY_TRXNTYPES

ERRORLOCATION NULL NUMBER Identifies the location oferror

BEPCODE NULL VARCHAR2(40) Error code from Back EndPayment System

BEPMESSAGE NULL VARCHAR2(255) Error message from Back EndPayment System

BATCHID NULL VARCHAR2(80) Batch Id provided by ElectronicCommerce Application



SETTLEDATE NULL DATE scheduled date for the bill ororder used for offline paymentsonly

MBATCHID NULL NUMBER Batch identifierREQDATE NULL DATE date when the batch operation

request is receivedREQTYPE NULL VARCHAR2(20) type of request such as

closebatch, purgebatch,openbatch etc...

REQSEQ NULL NUMBER(4) Request SequenceDESTURL NULL VARCHAR2(1024) used for storing the

constructed Back End PaymentSystem url during schedule ofPayments

NLSLANG NULL VARCHAR2(80) NLS LanguageNEEDSUPDT NULL VARCHAR2(3) flag to identify the rows that

has changed status. Used bySchedular

OVERALL_SCORE NULL NUMBER Overall Risk ScoreOBJECT_VERSION_NUMBER NOT NULL NUMBER(5) This column is used for locking


LAST_UPDATE_DATE NOT NULL DATE Standard Who ColumnLAST_UPDATED_BY NOT NULL NUMBER(15) Standard Who ColumnCREATION_DATE NOT NULL DATE Standard Who ColumnCREATED_BY NOT NULL NUMBER(15) Standard Who ColumnLAST_UPDATE_LOGIN NULL NUMBER(15) Standard Who Column


IBY_TRANSUMM1_BEPID_N1 NOT UNIQUE 4 BEPIDIBY_TRANSUMM2_TANGIBLEID_N2 NOT UNIQUE 1 TANGIBLEIDIBY_TRXN_SUMMARY_TRXNMID_U1 UNIQUE 5 TRXNMID


IBY_TRXNSUMM_MID_S TRXNMID

IBY_TRXNSUMM_TRXNID_S TRANSACTIONID

IBY_TRXNSUMM_REQSEQ_S REQSEQ

Index – 1

Index

AApplication Building Block, 1 – 6

CColumn descriptions, 3 – 4Columns, Who, 3 – 4Concurrent Program List. See Concurrent

Program Definitions

DDatabase Diagram, 1 – 6Database Diagrams

IBY Payment Processing, 2 – 8IBY Risk Management, 2 – 10

database diagrams, conventions, 2 – 5Database triggers, 3 – 6

FForeign keys, 3 – 3Form, 1 – 7Form List. See Form Definitions

IIndexes, 3 – 6

important note about, 3 – 6Internal View List, 2 – 17

LLookup types. See QuickCodes

MModule List, 2 – 18

See also Module DefinitionsModules, 1 – 6

OOracle8 sequences. See Sequences

PPublic Table List, 2 – 12Public View List, 2 – 16

QQuickCodes, 1 – 6

Columns that contain, 3 – 3

RRelationship, 1 – 6

Index – 2 Oracle iPayment Technical Reference Manual

Report List. See Report Definitions

SSequences, 3 – 6

TTable and View Definitions

FND_LOOKUPS, 3 – 7IBY_ACCPPMTMTHD, 3 – 8IBY_ACCTTYPE, 3 – 9IBY_ACTIVITY, 3 – 11IBY_AVS_RSTYPES_V, 2 – 17IBY_BANKACCT, 3 – 13IBY_BANKACCT_V, 2 – 17IBY_BATCHES_ALL, 3 – 14IBY_BATCHES_ALL_V, 3 – 16IBY_BEPINFO, 3 – 18IBY_BEPKEYS, 3 – 20IBY_BEPLANGS, 3 – 21IBY_CRC_RSTYPES_V, 2 – 17IBY_CREDITCARD, 3 – 22IBY_CREDITCARD_V, 2 – 17IBY_DEFAULT_BEP, 3 – 23IBY_ECAPP, 3 – 24IBY_ECAPP_V, 2 – 17IBY_FOP_DTYPES_V, 2 – 17IBY_FORMULA_FACTOR_V, 2 – 17IBY_INSTR_HOLDER_V, 2 – 17IBY_INSTRHOLDER, 3 – 25IBY_IRF_PMT_AMOUNT, 3 – 26IBY_IRF_PMT_FREQUENCY, 3 – 27IBY_IRF_PMT_HIST_RANGE, 3 – 29IBY_IRF_PMT_HISTORY, 3 – 28IBY_IRF_RISKY_INSTR, 3 – 30IBY_IRF_TIMEOF_PURCHASE, 3 – 31IBY_IRF_TRXN_AMT_LIMIT, 3 – 32IBY_MAPPINGS, 3 – 33IBY_PA_RSTYPES_V, 2 – 17IBY_PAYEE, 3 – 34

IBY_PAYMENTS_V, 2 – 17IBY_PH_DTYPES_V, 2 – 17IBY_PH_RSTYPES_V, 2 – 17IBY_PMTMTHD_CONDITIONS, 3 – 35IBY_PMTSCHEMES, 3 – 36IBY_RC_RSTYPES_V, 2 – 17IBY_RISK_FACTORS, 3 – 37IBY_RISK_FORMULA_ITEM, 3 – 40IBY_RISK_FORMULAS, 3 – 39IBY_ROUTINGINFO, 3 – 41IBY_TAL_DTYPES_V, 2 – 17IBY_TAL_RSTYPES_V, 2 – 17IBY_TANGIBLE, 3 – 42IBY_TOP_RSTYPES_V, 2 – 17IBY_TRANS_ALL_V, 3 – 43IBY_TRANS_BANKACCT_V, 2 – 17IBY_TRANS_CORE_V, 2 – 17IBY_TRANS_FI_V, 2 – 17IBY_TRANS_SET_V, 2 – 17IBY_TRANSACTIONS_SET_V, 2 – 17IBY_TRANSACTIONS_V, 2 – 17IBY_TRXN_CORE, 3 – 46IBY_TRXN_EXTENDED, 3 – 48IBY_TRXN_FI, 3 – 50IBY_TRXN_SUMMARIES_ALL, 3 – 51

TablesSee also Table and View DefinitionsColumn descriptions, 3 – 4Foreign keys, 3 – 3Indexes. See IndexesPrimary Keys, 3 – 4QuickCodes Columns, 3 – 3Who columns, 3 – 4, 3 – 5

VView Definitions. See Table and View

DefinitionsViews

See also Table and View Definitions; ViewList

Derivation, 3 – 6

Reader’s Comment Form

Oracle iPayment Technical Reference ManualA83676–01

Oracle Corporation welcomes your comments and suggestions on the quality and usefulnessof this publication. Your input is an important part of the information we use for revision.

• Did you find any errors?

• Is the information clearly presented?

• Do you need more information? If so, where?

• Are the examples correct? Do you need more examples?

• What features did you like most about this manual? What did you like least about it?

If you find any errors or have any other suggestions for improvement, please indicate the topic, chapter,and page number below:

Please send your comments to:

CRM Content Development ManagerOracle Corporation500 Oracle ParkwayRedwood Shores, CA 94065 USAPhone: (650) 506–7000 Fax: (650) 506–7200

If you would like a reply, please give your name, address, and telephone number below:

Thank you for helping us improve our documentation.

ipayment_trm

Documents

maps routing rule

confidential informationuse restricted

multiple terminal ids

time rangesand associate

enter journals window

foreign key constraint

risk management feature

credit transaction amounts