CA2258648A1

CA2258648A1 - A system, method and article of manufacture for managing transactions in a high availability system

Info

Publication number: CA2258648A1
Application number: CA002258648A
Authority: CA
Inventors: David A. Berger; Daniel R. Haller; Trong Nguyen; Kevin T. B. Rowney; Glenn A. Kramer
Original assignee: Verifone, Inc.; David A. Berger; Daniel R. Haller; Trong Nguyen; Kevin T. B. Rowney; Glenn A. Kramer; Hewlett-Packard Company
Current assignee: HP Inc
Priority date: 1996-06-17
Filing date: 1997-06-17
Publication date: 1997-12-24
Also published as: WO1997049050A2; AU3640597A; WO1997049050A3; EP0935785A2

Abstract

An architecture is disclosed allowing a server to communicate bidirectionally with a gateway over a first communication link, over which service requests are initiated by the server. In response to a transaction received from a host legacy system at the gateway, the gateway parses one or more transaction response values from the host message, maps the one or more transaction response values to a canonical response code, and stores the canonical response code in a transaction log. According to a broad aspect of a preferred embodiment of the invention, communication networks that employ transactions between applications must effectively manage transactions that flow over the network. In addition, networking systems must also detect counterfeit transactions, especially, when the networking systems are utilized for financial transactions. An active, on-line database is utilized as a transaction log to track original requests, valid retrys and detect fraudulent transactions. The transaction log serves as a memory cache where the received host response is returned to a valid retry transaction should the original response fail to reach a server because of a communications problem.

Description

CA 022~8648 1998-12-16 A SYSTEM, METHOD ~ND ARTICLE OF MANUFACrURE
FOR M~Nl~r~n~G TRANSACTIONS IN A H~GH AvAn ARn TTy ~r~

Field Of The T ~_~l1G~
5 The present invention relates to the secure, electronic payment in ~ h~tng~ for goods and services purchased over a commt]ni~tion network, and more specific~tlly, to a system, method and article of manufacture for securely transmitting paymentinformation from a customer to a merchant to a payment gateway and returning a certification, including a credit confidence factor to allow a merchant to determine 10 whether to accept or reject payment information utilizing a flexible, ~rten.cible architecture.

The present invention relates to an electronic graphical le~lcsellt~tion of a monetary system for implementing electronic money payments as an alternative medium of 15 economic ~ch~tn~e to cash, checks, credit and debit cards, and electronic funds transfer. The Electronic-Monetary System is a hybrid of currency, check, card payment systems, and electronic funds transfer systems, possessing many of the benefits of these systems with few of their limitations. The system utilizes electronic l~l rcs~lltations of money which are designed to be universally accepted and 20 ~ h~tnged as economic value by subscribers of the monetary system.

Today, ap~ llately 350 billion coin and currency transactions occur between individuals and institutions every year. The extensive use of coin and currency transactions has limited the automation of individual transactions such as 25 purchases, fares, and bank account deposits and withdrawals. Individual cash transactions are burdened by the need to have the correct amount of cash or providing change therefor. Furthermore, the h~n~ling and m~tn~Eing of paper cashand coins is inconvenient, costly and time consuming for both individuals and financial institutions.
Although checks may be written for any specific amount up to the amount available in the account, checks have very limited transferability and must be supplied from a physical inventory. Paper-based checking systems do not offer sufficient relief from the limitations of cash transactions, sharing many of the inconveniences of h~tn~lling 35 currency while adding the inherent delays associated with processing checks. To this , .

WO 97/49050 PCTrUS97/10402

-2-end, eÇonom~ ch~nge has striven for greater convenience at a lower cost, while also seeking ilnpluvcd security.

Automation has achieved some of these qualities for large transactions through 5 computerized electronic funds transfer ("EFT") systems. Electronic funds transfer is essçnti~lly a process of value P~r~h~n~e achieved through the b~nkin~ system's centralized computer tr~n~rtinrl~ EFT services are a transfer of payments utilizing electronic "checks," which are used primarily by large commercial organizations.
10 The Clearing House (ACH) where a user can enter a pre-authorized code and download information with billing occurring later, and a Point Of Sale (POS) system where a transaction is processed by connecting with a central computer for authorization for the transaction granted or denied im me~ tely are examples of EFVr systems that are utilized by retail and commercial org~ni~tinns~ However, the 15 payments made through these types of EFT systems are limited in that they cannot be performed without the b~nking system. Moreover, ACH transactions usually cannot be performed during off business hours.

Home Banking bill payment services are examples of an EFVr system used by 20 individuals to make payments from a home computer. Currently, home b~nkin~
initiatives have found few customers. Of the banks that have offered services for payments, account transfers and information over the telephone lines using personal computers, less than one percent of the bank's customers are using the service. One reason that Home R~nking has not been a successful product is 25 because the customer cannot deposit and withdraw money as needed in this type of system.

Current EFT systems, credit cards, or debit cards, which are used in conjunctionwith an on-line system to transfer money between accounts, such as between the 30 account of a merchant and that of a customer, cannot satisfy the need for an automated transaction system providing an ergonomic interface. Examples of EFVr systems which provide non-ergonomic interfaces are disclosed in US Patents Numbers 5,476,259; 5,459,304; 5,452,352; 5,448,045; 5,478,993; 5,455,407;
5,453,601; 5,465,291; and 5,485,510.
To implement an autom~ted, convenient transaction that can dispense some form ofeconomic value, there has been a trend towards off-line payments. For example, CA 022~8648 1998-12-16 WO 97/49050 PCTtUS97/10402 numerous ideas have been ~lo,.~osed for some form of "clccl~ullic money" that can be used in cA~hless payment transactions as alternatives to the traditional currency and check types of payment systems. See U.S. Pat. No. 4,977,595, entitled "METHOD AND APPARATUS FOR IMPLEMENTING ELECTRONIC CASH," and U.S.
Pat. No. 4,305,059, entitled "MODULAR FUNDS TRANSFER SYSTEM."
The more well known tech~ es include magnetic stripe cards purchased for a given amount and from which a prepaid value can be deducted for specific purposes.
Upon exhaustion of the economic value, the cards are thrown away. Other examplesinclude memory cards or so called smart cards which are capable of repetitively storing information representing value that is likewise deducted for specific purposes.

It is desirable for a computer operated under the control of a merchant to obtain information offered by a customer and transmitted by a computer operating under the control of the customer over a publicly acces~ihle packet-switched network (e.g., the Internet) to the computer operating under the control of the merchant, without risking the exposure of the information to interception by third parties that have access to the network, and to assure that the information is from an authentic source. It is further desirable for the merchant to transmit informAtion, including a subset of the information provided by the customer, over such a network to a payment gateway computer system that is de~ign~te~l, by a bank or other fins~nri~l institution that has the responsibility of providing payment on behalf of the customer, to authorize a c-mmrrcial transaction on behalf of such a finzlnri~l institution, without the risk of exposing that information to interception by third parties. Such institutions include, for example, fin~nri~l institutions offering credit or debit card services.

One such attempt to provide such a secure trAn~mi.C~ion rh~nnel is a secure payment technology such as Secure Electronic Transaction ~hereinafter "SET"), jointly developed by the Visa and MasterCard card assori~tion~q~ and described in Visa and MasterCard's Secllre Electronic lransaction (SET) Specip~cation, February 23, 1996, hereby incorporated by reference. Other such secure payment technologies include Secure Transaction Technology ("STT"), Secure Electronic Payments Protocol ("SEPP"), Internet Keyed Payments ("iKP"), Net Trust, and Cybercash Credit Payment - 35 Protocol. One of ordinary skill in the art readily comprehends that any of the secure payment technologies can be substituted for the SET protocol without undue experimentation. Such secure payment technologies require the customer to operate CA 022~8648 1998-12-16 WO 97l49050 PCT/US97/10402 software that is compliant with the secure payment technology, interacting with third-party certification authorities, thereby allowing the customer to transmitencoded information to a merchant, some of which may be decoded by the merchant, and some which can be decoded only by a payment gateway specified by 5 the customer.

Another such attempt to provide such a secure trRn~miscinn channel is a general-purpose secure commnnicRtir~n protocol such as Netscape, Inc.'s Secure Sockets Layer (hereinafter "SSL"), as described in Freier, Karlton & Kocher (hereinafter"Freier"), The SSL Protocol Version 3.0, March 1996, and hereby incorporated by reference. SSL provides a means for secure trRn~mic~ion between t~,vo computers.SSL has the advantage that it does not require special-purpose software to be installed on the customer's computer because it is already incorporated into widely available softv,~are that many people utilize as their standard Internet access 15 medium, and does not require that the customer interact with any third-party certification authority. Instead, the support for SSL may be incorporated into software already in use by the customer, e.g., the Netscape Navigator World WideWeb bluw~ g tool. However, although a computer on an SSL connection may initiate a second SSL connection to another computer, a drawback to the SSL
20 approach is each SSL connection supports only a two-computer connection.
Therefore, SSL does not provide a me~h~ni~m for transmitting encoded informationto a merchant for retrRn~misQi-ln to a payment gateway such that a subset of theinformation is readable to the payment gateway but not to the merchant. AlthoughSSL allows for robustly secure two-party data trarl~mi.c~ n~ it does not meet the 25 ultimate need of the electronic commerce market for robustly secure three-party data transmission. Other examples of general-purpose secure commnnicRtion protocols include Private CommnnicRtinns Technology ("PCT") from Microsoft, Inc., Secure Hyper-Text Transport Protocol ("SHTTP") from Terisa Systems, Shen, Kerberos, Photuris, Pretty Good Privacy ("PGP") which meets the IPSEC criteria. One 30 of ordinary skill in the art readily comprehends that any of the general-purpose secure comml~nir~tinn protocols can be substituted for the SSL transmission protocol without undue G,~e~ entation.

Banks desire an Internet payment solution that emulates existing Point of Sale (POS) 35 applications that are currently installed on their host computers, and require minimRl changes to their host systems. This is a critical requirement since any downtime for a banks host computer system represents an enormous expense.

CA 022~8648 1998-12-16 Currently, VeriFone supports over fourteen hundred different payment-related applic~tions The large number of applications is necessal y to accommodate a wide variety of host message formats, diverse methods for comm--nir~ting to a variety of hosts with different dial-up and direct-co,llleulsrh~mes, and different certification 5 around the world. In addition, there are a wide variety of business pr~,cesses that dictate how a Point of Sale (POS) terminal queries a user for data and subsequently displays the data. Also, various vertical market segments, such as hotels, car rental agencies, restaurants, retail sales, mail sales / telephone sales require interfaces for different types of data to be entered, and provide different discount rates to 10 merchants for complying with various data types. Moreover, a plethora of report generation mech~ni~m~ and formats are utilized by merchants that bz~nking organi7:~tions work with.

Banks are unwilling to converge on "standards" since collvel ~llce would facilitate 15 switching from one acquiring bank to another by merchants. In general, banks desire to increase the cost that a merchant incurs in switching from one acquiring bank to another acquiring bank. This is accomplished by supplying a merchant with a terminal that only communicates utilizing the bank's proprietary protocol, and by providing other value-added services that a merchant may not be able to 20 obtain at another bank.

Internet-based payment solutions require a-lrlitinn~l security measures that are not found in conventional POS terminals. This additional requirement is necessitatedbecause Internet communication is done over publicly-accessible, unsecured 25 comm-~nir~t;nn line in stark contrast to the private, secure, dedicated phone or leased line service utilized between a traditional merchant and an acquiring bank.
Thus, it is critical that any solution utilizing the Internet for a comml~nir~tion backbone, employ some form of cryptography.

30 As discussed above, the current state-of-the-art in Internet based pay,l,clltplucessillg is a protocol referred to as SET. Since the SET messages are uniformacross all implementations, banks cannot differentiate th~msrlves in any re~on~hle way. Also, since SET is not a proper superset of all protocols utilized today, there are bank protocols which cannot be mapped or translated into SET because they 35 require data elements for which SET has no placeholder. Further, SET only h~n~lles the message types directly related to authorizing and captur-ing credit card transactions and adjustments to these authorizations or captures. In a typical POS

, ... . . . ....

terminal in the physical world, these mess~ges comprise almost the entire volume of the total number of messages beL..~ the merchant and the authorizing bank, but only half of the total number of different message types. These message types, which are used infrequently, but which are critical to the operation of the POS
5 terminal must be sulu~uul ~ed for proper tr~n~cti- n proces~in~

SUn~L~RY OF THE l~ VL..~lOl.
According to a broad aspect of a ulcfe~-~d embodiment of the invention, communi~tion networks that employ transactions bel~ ll applic~tif n~ must 10 effectively manage transactions that flow over the network. In addition, nelwulkillg systems must also detect counterfeit tr~n~cti~n~ especially, when the n~:lwulking systems are utilized for fin~n~i~l transactions. An active, on-line cl~t~ha~e is utilized as a tr~n~tion log to track original requests, valid retrys and detect fradulanttransactions. The tr~n~ tion log serves as a memory cache where the received host 15 response is returned to a valid retry tr~n~rtinn should the original response fail to reach a server because of a commllnic~ti-)n~ problem.

CA 022~8648 1998-12-16 DF~ ON OF THE DRAWINGS
The foregoing and other objects, aspects and advantages are better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:
5 Figure lA is a block diagram of a re~l~,sentative hal.lw~le el~vil~ lent in accordance with a preferred embodiment;
Figure lB depicts an overview in accordance with a preferred embo-lim.ont;
Figure lC is a block diagram of the system in accordance with a ~lcfell~d embodiment;
10 Figure 2 depicts a more detailed view of a customer computer system in comm-]nic~tion with merchant system under the Secure Sockets Layer protocol in accordance with a preferred embodiment;
Figure 3 depicts an overview of the method of securely supplying payment information to a payment gateway in order to obtain payment authorization in 15 accordance with a preferred embodiment;
Figure 4 depicts the detailed steps of generating and tr~n~mitting a payment authorization request in accordance with a preferred embodiment;
Figures 5A through 5F depict views of the payment authorization request and its component parts in accordance with a preferred embodiment;
20 Figures 6A and 6B depict the detailed steps of ~.oces~illg a payment authorization request and generating and transmitting a payment authorization request responsein accordance with a preferred embodiment;
Figures 7A through 7J depict views of the payment authorization response and itscomponent parts in accordance with a preferred embodiment;
25 Figure 8 depicts the detailed steps of 1~l ocesshlg a payment authorization response in accordance with a preferred embodiment;
Figure 9 depicts an overview of the method of securely supplying payment captureinformation to a payment gateway in accordance with a ~1 cfcl 1 cd embodiment;
Figure 10 depicts the detailed steps of generating and transmitting a payment 30 capture request in accordance with a preferred embodiment;
Figures 1 lA through 1 lF depict views of the payment capture request and its component parts in accordance with a preferred embodiment;
Figures 12A and 12B depict the detailed steps of processing a payment capture request and generating and transmitting a payment capture request response in 35 accordance with a preferred embodiment;
Figures 13A through 13F depict views of the payment capture response and its component parts in acco.da.lce with a preferred embodiment;

CA 022~8648 1998-12-16 W O 97/49050 PCTrUS97/10402 Figure 14 depicts the detailed steps of processing a payment capture response inaccordance with a ~-cfe-~cd embodiment;
Figure 15A ~ 15B depicts transaction ploccs~illg of merchant and consumer tr~n~ tions in accordance with a ~lcfcllcd embodiment;
5 Figure 16 illustrates a transaction class hierarchy block diagram in accoldance with a ~leÇe,lcd embodiment;
Figure 17 shows a typical mess~ flow beLwc:cll the merchant, vPOS terminal and the Gateway in accordance with a ~lefellcd embodiment;
Figures 18A-E are block diagrams of the extended SET architecture in accordance 10 with a pl ~fel l ~d embodiment;
Figure 19 is a flowchart of vPOS merchant pay customi7~ti~ in accordance with a preferred embodiment;
Figures 20A-20H are block diagrams and tlowcharts setting forth the detailed logic of thread processing in accordance with a pl~fc~ed embodiment;
15 Figure 21 is a detailed diagram of a multithreaded gateway engine in accordance with a ~lefellcd embodiment;
Figure 22 is a ~low diagram in accordance with a ~l cfcl 1 ~d embodiment;
Figure 23 illustrates a Gateway's role in a network in accordance with a preferred embodiment;
20 Figure 24 is a block diagram of the Gateway in accordance with a preferred embodiment;
Figure 25 is a block diagram of the vPOS Terminal Architecture in accordance with a preferred embodiment;
Figure 26 is an architecture block diagram in accordance with a p.cfc..~d 25 embodiment;
Figure 27 is a block diagram of the payment manager architecture in accordance with a preferred embodiment;
Figure 28 is a Consumer Payment Message Sequence Diagram in accordance with a ,vlefellcd embodiment of the invention;
30 Figure 29 is an illustration of a certificate issuance form in accordance with a preferred embodiment;
Figure 30 illustrates a certiffcate issuance response in accordance with a preferred embodiment;
Figure 31 illustrates a collection of payment instrument holders in accordance with 35 a plcf~.led embodiment;
Figure 32 illustrates the default payment instrument bitmap in accordance with a ~!~ efcl l cd embodiment;

CA 022~8648 l998-l2-l6 W O 97/49050 PCT~US97/10402 _9 Figure 33 illustrates a selected pay...cnt instrument vrith a fill in the blanks for the cardholder in accordance with a ~le~t/ led embodi~l~cilt;
Figure 34 illustrates a coffee purchase utilizing the newly defined VISA card inaccordance with a ~.~;f~ d embo-lim~nt of the invention;
S Figure 35 is a flowchart of con~iitir~n~l authorization of payment in accordance with a preferred embodiment;
Figures 36-48 are screen displays in accordance with a preferred embodiment;
Figure 49 shows how the vPOS authenticates an incoming response to a request in accordance with a plerer-~d .orrhodiment;
lO Figure 50 is a flowchart for the merchant interaction with the Test Gateway in accordance with a preferred embodiment;
Figures 51-61 are flowcharts depicting the detailed logic of the gateway in acco.da..ce with a preferred embodiment;
Figure 62 is the main ~lministration display for the Gateway in accordance with a l S preferred embodiment;
Figure 63 is a configuration panel in accordance with a preferred embodiment.
Figure 64 is a host comml~ni-~ti~ n display for facilitating communication between the gateway and the acquirer payment host in accordance with a preferred embodiment;
20 Figure 65 is a Services display in accordance with a preferred embodiment; and Figure 66 is a graphical lep-~se-ltation of the gateway transaction ~i~t~h~e in accordance with a preferred embodiment.

DETAILED D~;S~;~ur~ lON
25 A preferred embo-lim-~nt of a system in accordance with the present invention is preferably practiced in the context of a personal computer such as the IBM PS/2,Apple Macintosh computer or UNIX based wurk~L~tion. A representative hardware environment is depicted in Figure lA, which illustrates a typical hardware configuration of a wu~k~lation in accordance with a preferred embodiment having a 30 central processing unit 10, such as a mic.u~uces~or~ and a number of other units interconnected via a system bus 12. The wurk~tation shown in Figure lA includes a Random Access Memory (RAM) 14, Read Only Memory (ROM) 16, an I/O adapter 18 for connecting peripheral devices such as disk storage units 20 to the bus 12, a user interface adapter 22 for connecting a keyboard 24, a mouse 26, a speaker 28, a 35 microphone 32, and/or other user interface devices such as a touch screen (not shown~ to the bus 12, comml-nic~tion adapter 34 for connecting the workstation to a comml~n~ tion network (e.g., a data processing network) and a display adapter 36 CA 022~8648 1998-12-16 W 097/49050 PCTrUS97/10402 for connecting the bus 12 to a display device 38. The wulh:iL~tion typically hasresident thereon an operating system such as the Microsoft Windows NT or Windows/95 Operating System (OS), the IBM OS/2 operating system, the MAC OS, or UNIX operating system. Those skilled in the art will appreciate that the ~l~èsellt invention may also be implemented on platforms and operating systems other than those mentioned.

A preferred embodiment is written using JAVA, C, and the C++ language and utilizes object oriented progr~mming methodology. Object oriented progr~mming (OOP~ has become increasingly used to develop complex applications. As OOP moves toward the mainstream of software design and development, various software solutions require adaptation to make use of the benefits of OOP. A need exists for these principles of OOP to be applied to a messaging interface of an electronic mess~ging system such that a set of OOP classes and objects for the messaging interface can be 1 5 provided.

Thus, as object-oriented progr~mming solutions are applied to various problems and progr~mmin~ tasks, signifir~nt reductions in the design and development effort for software can be achieved. A preferred embodiment of the invention utilizes HyperText Markup Language (HTML) to impl.om~nt documents on the lnternet together with a general-purpose secure commllnin~ti~n protocol for a transport medium between the client and the merchant. HTTP or other protocols could be readily substituted for HTML without undue experimentation. Information on theseproducts is available in T. Berners-Lee, D. Connoly, "RFC 1866: Hypertext MarkupLanguage - 2.0" (Nov. 1995); and R. Fielding, H, Frystyk, T. Berners-Lee, J. Gettys and J.C. Mogul, "Hy~uelle~lT ransfer Protocol -- HTTP/ 1.1: HTTP Working Group Internet Draft" (May 2, 1996). HTML is a simple data format used to create hyluelLe~L
documents that are portable from one platform to another. HTML documents are SGML documents with generic semantics that are ap~lol,liate for replesellting information from a wide range of ~lom~in~ HTML has been in use by the World-Wide Web global information initiative since 1990. HTML is an application of ISOStandard 8879:1986 Information Processing Text and Office Systems; Standard Generalized Markup Language (SGML). Sun's JAVA allows developers to create robust User Interface (UI) components. Custom "widgets" (e.g. real-time stock tickers, ~nim~t~d icons, etc.) can be created, and client-side ,uelrollllance isilll~luved. Unlike HTML, Java supports the notion of client-side vAlirlzltinn, Omo~tling a~l,lupliate processing onto the client for improved performance.

CA 022~8648 1998-12-16 Dynamic, real-time Web pages can be created. Using the above-mentioned custom UI compor~.onts, dynamic Web pages can also be created.

Sun's Java language has emerged as an industry-recogni~erl language for5 "pro~ ....l.i.,g the Internet." Sun defines Java as: ~a simple, object-oriented, distributed, intel~leLed, robust, secure, architecture-neutral, portable, high-performance, multithreaded, dynamic, buzzword-compliant, general-purpose progr~mmin~ language. Java supports progr~mming for the Internet in the form of platform-independent Java applets." Java applets are small, speri~ e~l applications 10 that comply with Sun's Java Applir~ti~n ProgrPImming Interface (API) allowingdevelopers to add "interactive content" to Web documents (e.g. simple ~nim~tinn page adornments, basic games, etc.). Applets execute within a Java-compatible Ll~w:~l (e.g. Netscape Navigator) by copying code from the server to client. From a language standpoint, Java's core feature set is based on C++. Sun's Java literature 15 states that Java is basically "C++, with ~xtension~ from Objective C for moredynamic method resolution". Another technology that provides similar function toJAVA is provided by Microsoft and ActiveX Technologies, to give developers and Web designers wherewithal to build dynamic content for the Internet and personal computers. ActiveX includes tools for developing ~nim~tion, 3-D virtual reality, video 20 and other multime~ content. The tools use Internet standards, work on multiple platforms, and are being supported by over 100 colllpallies. The group's building blocks are called ActiveX Controls, small, fast components that enable developers to embed parts of software in hy,~ l Lt:.~l markup language (HTML) pages. ActiveX
Controls work with a variety of plo~ .. ;.,g languages including Microsoft Visual 25 C++, Borland Delphi, Microsoft Visual Basic progr~mming system and, in the future, Microsoft's development tool for Java, code named "Jakarta." ActiveX Technologies also inr~ os ActiveX Server Framework, allowing developers to create server applir~tir,n~. One of ordinary skill in the art readily recognizes that ActiveX could be substituted for JAVA without undue experimentation to practice the invention. Figure 30 lB depicts an overview of the present invention. Customer computer system 120 is in communication with merchant computer system 130. The customer-merchant session 150 operates under a general-purpose secure comml-nic.~tion protocol such as the SSL protocol. Merchant computer system 130 is ~lflitinn~lly in communication with payment gateway computer system 140. A payment gateway is 35 a system that provides electronic cr,mmerce services in support of a bank or other fi"Anrisll institution, and that interfaces to the fin~nri~l institution to support the authorization and capture of transactions. The customer-institution session 170 W O 97/49050 PCT~US97/10402 operates under a variant of a secure payment terhnrllogy such as the SET protocol, as described herein, referred to as Merchant-Ori inRted Secure Electronic Transactions ("MOSET"~, as is more fully described herein.

C L -~o-Merchant Cc '~~''~
Figure 2 depicts a more detailed view of customer computer system 120 in commnnirRtion with merchant system 130 using customer-merchant session 150 operating under the SSL protocol as documented in Freier and incorporated by reference. Customer computer system 120 initiates commllnicRtirn with merchant computer system 130 using any well-known access protocol, e.g., TrRn~mi~sion Control Protocol/lnternet Protocol ("TCP/IP"). A deswil-~ion of TCP/IP is provided in Information Sciences Institute, "TrRn~mi~ion Control Protocol DARPA Internet Program Protocol SperificRtir,n (RFC 793)" (September, 1981), and Information Sciences Institute, "Intemet Protocol DARPA Internet Program Protocol Specification (RFC 791)" (September, 1981). In this implementation, customer computer system 120 acts as a client and merchant computer system 130 acts as a server.

Customer computer system 120 initiates commnnirRtion by sen~ling "client hello"
message 210 to the merchant computer system 130. When a client first connects to20 a server it is required to send the client hello message 210 as its first message. The client can also send a client hello message 210 in response to a hello request on its own initiative in order to renegotiate the security parameters in an existing connection. The client hello message includes a random structure, which is used later in the protocol. Specifically, the random structure includes the current time 25 and date in standard UNIX 32-bit format according to the sender's internal clock and twenty-eight bytes of data generated by a secure random number generator.
The client hello message 210 further includes a variable length session identifier. If not empty, the session identifier value identifies a session between the same client and server whose security parameters the client vwishes to reuse. The session 30 identifier may be from an earlier connection, the current connection, or another currently active connection. It is useful to specify the current connection if the client only wishes to update the random structures and derived values of a connection. It is useful to specify another currently active connection if the client wishes to establish several simultaneous independent secure connections to the 35 same server without repeating the full hRntl~hRkr protocol. Client hello messRg~
210 further includes an in~1icRtr,r of the cryptographic algorithms supported by the client in order of the client's preference, ordered according to client preference.

CA 022~8648 1998-12-16 .

In response to client hello message 210, if merchant computer system 130 wishes to cu.lc~uond with customer computer system 120, it responds with server hello message 215. If merchant co-..~uLt:. system 130 does not wish to communicate S with customer computer system 120, it respon~ls with a m~s.~A~, not shown, indicating refusal to comml~nic~tion Server hello message 215 includes a random structure, which is used later in the protocol. The random structure in server hello message 215 is in the same format as, but has contents independent of, the random structure in client hello mes~ 210. Speciffcally, the random structure includes the current time and date in standard UNIX 32-bit format according to the sender's internal clock and twenty-eight bytes of data generated by a secure random number generator. Server hello message 215 further includes a variable length session identifier. The session identifier value identifies a new or existing session between the same client and server. Server hello message 215 further includes an indicator l 5 of the cryptographic algorithms selected from among the algorithms specified by client hello message 210, which is utilized in further encrypted communications.
Optionally, Merchant computer system 130 tr~n~mits a server certificate 220. If transmitted, server certificate 130 enables customer computer system 120 to authenticate the identity of merchant computer system 130. If merchant computer system 130 does not transmit a server certificate 220, or if server certificate 220 is suitable only for authentication, it may optionally transmit a server key P~ch~nee message 225. Server key t~ .h~n~ message 225 i~lentifies a key that may be used by customer computer system 120 to decrypt further messages sent by merchant computer system 130. After transmitting server hello message 215, and optionallytransmitting server certificate 220 or server key ~ h~nge message 225, merchant computer system 130 tr~n~mit.c a server hello done message 230 and waits for a further response from customer computer system 120.

Customer computer system 120 optionally transmits client certificate 240 to merchant computer system 130. If transmitted, client certificate 240 enables merchant computer system 130 to authenticate the identity of customer computer system 120. Alternatively, customer computer system 120 may transmit a no-client-certificate alert 24~, to inrlic~te that the customer has not registered with any ~ 35 certification authority. If customer computer system 130 does not transmit a client certificate 240, or if client certificate 240 is suitable only for authentication, customer computer system 130 may optionally transmit a client key ~rh~nge . .,, , , .. . . . ., . . ~ .. .

CA 022~8648 1998-12-16 W O 97/49050 PCT~US97/10402 message 250. Client key Px~h~nge message 250 identifies a key that may be used by merchant computer system 130 to decrypt further messages sent by customer computer system 120. After optionally transmitting client certificate 240, no-client-certificate alert 245, and/or client key ext~h~nge message 250, customer colllpu~e system 120 transmits a finished message 260.

At this point, customer computer system 120 and merchant computer system 130 have:
1) negotiated an encryption scheme that may be commonly employed in further commnni-~tiQn~, and 2) have commllnic~ted to each other a set of encryption keys that may be used to decrypt further comml]nic~ti-~ns be~ n the two computer systems.

Customer computer system 120 and merchant computer system 130 may thereafter 15 engage in secure communications 270 with less risk of interception by third parties.
Among the messages communicated by customer computer system 120 to merchant computer system 130 may be messages that specify goods or services to be orderedand payment information, such as a credit card number and related informAtil n, collectively referred to as "payment informAtion," that may be used to pay for the 20 goods and/or services ordered. In order to obtain payment, the merchant must supply this information to the bank or other payment gateway responsible for therreled payment method. This enables the merchant to perform payment authorization and payment capture. Payment authorization is the process by whichpermission is granted by a payment gateway operating on behalf of a fin~nciPl 25 institution to authorize payment on behalf of the fin~nci~l institution. This is a process that ~sesses tr~ns~ti~n risk, confirms that a given transaction does notraise the account holder's debt above the account's credit limit, and les~,.ves the specified amount of credit. Payment capture is the process that triggers the movement of funds from the financial institution to the merchant's account after30 settlement of the account.

F'~.y - t AnthG~:7~t~
Merchants utilize point-of-sale products for credit and debit transactions on a daily basis. An embodiment in accordance with the subject invention allows an acquirer35 processor to accept transactions from Internet storefronts without altering a current host environment.

CA 022~8648 1998-12-16 The system easily CO.Iv~l Ls payment protocol messages and simultaneously manages transactions from a number of Internet merchant servers. As the number of transactions grows, the payment gateway can be scaled to handle the increased bll~in~?ss, and it can be configured to work with specific business processes used by the acquirer/processor. Thus, the payment gateway SUppOl L~ Internet processing utilizing payment processing operations.

The payment gateway provides support for configuring and installing the Internetpayment capability utilizing existing host point-of-sale technolc gy. The payment gateway also provides an intuitive Graphical User Interface (GUI) with support built in to accommodate future payment instruments such as debit cards, electronic checks, electronic cash and micl o~aylllents. The payment gateway implements secure transactions using RSA public-key cryptography and the MasterCard/Visa Secure Electronic Transaction (SET) protocol. The gateway also provides full l 5 functionality for merchant payment processing including authorization, capture, settlement and reconcili~tion while providing monitor activity with l~pOl Lillg and tracking of transactions sent over the Internet. Finally, the payment gateway also impl~m~nts Internet payment procedures that match current processor business models to ensure consistency for merchants. ET~nrlling Internet tr~n~ctions is destined to become a necess~ry function for every payment procrocessing system.
Today, merchants often transmit data received over the Internet inefficiently. Some fax the information or waste time keying data into a non-lnternet system.

Figure 3 depicts an overview of the method of securely supplying payment inforrnation to a payment gateway in order to obtain payment authorization. In function block 310, merchant computer system 130 generates a payment authorization request 315 and tr~nsmit.~ it to payment gateway computer system 140. In function block 330, payment gateway system 140 processes the payment authorization request, generates a payment authorization response 325 and transmits it to merchant computer system 130. In function block 320, merchant computer system 130 processes payment authorization response 325 and determines whether payment for the goods or services sought to be obtained by the customer has been authorized.

Pa~e-.~ A--t~ tion Request ~~.,e.~tion Figure 4 depicts the detailed steps of generating and transmitting a payment authorization request. Figures 5A through 5F depict views of the payment . ., ~

CA 022~8648 1998-12-16 authorization request and its compor~ent parts. In function block 410, merchant computer system 130 creates a basic authorization request 510. The basic authorization request is a data area that includes all the information for determining whether a request should be granted or denied. Spe~ifi~lly, it includes such 5 information as the party who is being charged, the amount to be charged, the account number of the account to be charged, and any additional data, such as passwords, needed to validate the charge. This information is either calculated based upon prior customer mer~h~ntliee selection, or provided by the customer over the secure link 270 est~hliehed in the customer-merchant general-purpose secure 10 comml-nicAti-~n protocol session. Fig 5A depicts a basic authorization request 510.

In function block 420, merchant computer system 130 combines basic authorization request 510, a copy of its encryption public key certificate 515 and a copy of its signature public key certificate 520. Merchant computer system 130 l 5 calculates a digital eign~tllre 525 for the comhinecl contents of the combined block 530 comprising basic authorization request 510, the encryption public key certificate 515 and the .eign~tllre public key certificate 520, and appends it to the comhinRtion of the combined basic authorization request 510, the encryption public key certificate 515 and the eign~tnre public key certificate 520. The merchant 20 computer system cQlcul~tes digital eiE~n~tl~re 525 by first calculating a "message digest" based upon the contents of the comhine-l basic authorization request 510, the encryption public key certificate 515 and the signature public key certificate 520. A message digest is the fixed-length result that is generated when a variable length message is fed into a one-way h~.ehing function. Message digests help verify 25 that a message has not been altered because altering the message would change the digest. The message digest is then encrypted using the merchant computer system's 130 digital signature private key, thus forming a digital signature.

Figure 5B depicts the combined block 530 formed by function block 420 and 30 containing basic authorization request 510, the encryption public key celLir,cate 515, the sign~tllre public key ce, liricate 520, and digital eign~tl-re 525. In function block 430, merchant computer system 130 generates a random encryption key RK-0 540, denoted as RK-0. Random encryption key RK-0 540 is a symmetric encryption key. A symmetric encryption key is a key characterized by the property that a 35 message encrypted with a symmetric key can be de~,y~led with that same key. This is contrasted with an asymmetric key pair, such as a public-key/private-key key pair, where a message encrypted with one key of the key pair may only be decrypted CA 022~8648 1998-12-16 with the other key of the same key pair. Figure 5C depicts random encryption keyRK-0 540.

In function block 440, merchant computer system 130 encrypts combined block 530 using random encryption key RK-0 540 to form encrypted combined block 550.
Figure 5D depicts encrypted combined block 550. The encryption state of encrypted combined block 550 is graphic~lly shown by random key lock 555, which inrlic~testhat encrypted combined block 550 is encrypted using random key RK-0 540. In function block 450, merchant computer system 130 encrypts random encryption key RK-0 540 using the public key of payment gateway system 140 to form encrypted random key 560. Figure 5E depicts encrypted random key 560. The encryption state of encrypted random key 560 is gr~phicRlly shown by payment gateway public key lock 565, which inrli~tes that encrypted random key 560 is encrypted using the payment gateway public key. In function block 460, merchant computer system 130 conc~ten~t~s encrypted combined block 550 and encrypted random key 560 to form merchant authorization request 315. Figure 5F depicts merchant authorization request 315 comprising encrypted combined block 550 and encrypted random key 560. In function block 470, merchant computer system 130 transmits merchant authorization request 315 to payment gateway system 140.
PY~,~,...e,..t.A--t~o~- t~.. Request ~i~ce~L~ ~
Figure 6 depicts the detailed steps of processing a payment authorization request and generating and transmitting a payment authorization request response.
Function blocks 610 through 630 depict the steps of processing a payment authorization request, while function blocks 635 through 685 depict the steps ofgenerating and tr~n~mitt;ng a payment authorization request response. In function block 610, payment gateway computer system 140 applies its private key to encrypted random key 560 contained within received merchant authorization request 315, thereby de~ g it and obtaining a cleartext version of random key RK-0 540. In function block 615, payment gateway computer system 140 applies random key RK-0 540 to encrypted combined block 550, thereby dec~ ling it and obtaining a cleartext version of combined block 530. Combined block 530 collll,lises basic authorization request 510, a copy of merchant computer system's 130 encryption public key certificate 515 and a copy of merchant computer system's 130 ~ign~tnre public key certificate 520, as well as merchant digital ~ign?~tllre 525.

CA 022~8648 l998-l2-l6 W 097/49050 PCTrUS97/10402 In function block 620, payment gateway computer system 140 verifies merchant computer system's 130 encryption public key certificate 515 and merchant computer system's 130 signature public key certificate 520. Payment gateway computer system 140 performs this verifir~tif~n by m~king a call to the certif r.~tit~n S authorities associated with each ce. Lir.cate. If verifit-~tion of either certificate fails, payment gateway computer system 140 rejects the authorization request. In function block 625, payment gateway computer system 140 v~ tes merchant digital signature 525. Payment gateway computer system 140 performs this validation by calculating a message digest over the contents of the combined basic authorization request 510, the encryption public key certificate 515 and the QignP~tllre public key certificate 520. Payment gateway computer system 140 thendecrypts digital ~ign~ture 525 to obtain a copy of the equivalent message digestcalculated by merchant computer system 130 in function block 420. If the two message digests are equal, the digital signature 525 is validated. If validation fails, l 5 payment gateway computer system 140 rejects the authorization request. In function block 630, payment gateway computer system 140 determines the finz3n~
institution for which authorization is required by inspection of basic authorization request 510. Payment gateway computer system 140 contacts the app~ iate fin~nci~l institution using a secure means, e.g, a direct-dial modem-to-modem connection, or a proprietary internal network that is not accessible to third parties, and using prior art means, obtains a response in-lic~tine whether the requested payment is authorized.

F~ - ' AuthG.lz6t;0n ~2~sF D- - e Generation Function blocks 635 through 685 depict the steps of generating and transmitting a payment authorization request response. Figures 7A through 7J depict views of the payment authorization response and its component parts. In function block 635, payment gateway computer system 140 creates a basic authorization response 710.
The basic authorization request is a data area that includes all the information to determine whether a request was granted or denied. Figure 7A depicts basic authorization response 710. In function block 640, payment gateway computer system 140 comhin~s basic authorization response 710, and a copy of its ~ien~ture public key certificate 720. Payment computer system 140 calculates a digital sign~t--re 725 for the combined contents of the combined block 730 comprising basic authorization response 710 and the Sien~tl-re public key certificate 720, and appends the signature to the comhin~ti- n of the combined basic authorization response 710 and the signature public key certificate 720. The payment gateway CA 022~8648 1998-12-16 WO 97/49050 PCT/U~97/10402 computer system calc~ t~s digital ~ign~t~re 725 by first calculating a mes~e digest based on the contents of the combined basic authorization response 710 and .sign~tl-re public key certificate 720. The message digest is then encrypted using the merchant computer system's 140 digital .~ tl-re private key, thus forming a S digital-~ignS~tllre.

Figure 7B depicts the combined block 730 formed in function block 640 and containing basic authorization response 710, the ~ign~tllre public key certificate 720, and digital signAtllre 725. In function block 645, payment gateway computersystem 150 generates a first symmetric random encryption key 740, denoted as RK-1. Figure 7C depicts first random encryption key RK-1 740. In function block 650, payment gateway computer system 140 encrypts cornbined block 730 using random encryption key RK- 1 740 to form encrypted combined block 750. Figure 7D depictsencrypted combined block 750. The encryption state of encrypted combined block 750 is grPIphic~lly shown by random key lock 755, which indicates that encryptedcombined block 750 is encrypted using random key RK- 1 740. In function block 655, payment gateway computer system 140 encrypts random encryption key RK- 1 740 using the public key of merchant computer system 130 to form encrypted random key RK 760. Figure 7E depicts encrypted random key RK- 1 760. The encryption state of encrypted random key 760 is gr~phic~lly shown by merchant public key lock 765, which indicates that encrypted random key 760 is encrypted using the merchant public key. In function block 660, payment gateway computer system 140 generates a random capture token 770. Random capture token 770 is utilized in subsequent payment capture processing to associate the payment capture request with the payment authorization request being processed. Figure 7F depicts capture token 775. In function block 665, payment gateway computer system 140 generates a second symmetric random encryption key 775, denoted as RK-2. Figure 7G depicts second random encryption key RK-2 775. In function block 670, payment gateway computer system 140 encrypts capture token 770 using random encryption key RK-2 770 to form encrypted capture token 780. Figure 7H depicts encrypted capture token 780. The encryption state of encrypted capture token 780is gr~phic~lly shown by random key lock 785, which in~ic~t~s that encrypted capture token 780 is encrypted using random key RK-2 770. In function block 675,payment gateway computer system 140 encrypts second random encryption key RK-2 775 using its own public key to form encrypted random key RK-2 790. Figure 7I
depicts encrypted random key RK-2 790. The encryption state of encrypted random key 790 is gr~phic~lly shown by payment gateway public key lock 795, which CA 022~8648 1998-12-16 W O 97/490~0 PCTrUS97/10402 intlirAt~s that encrypted random key 790 is encrypted using the payment gateway public key. In function block 680, payment gateway computer system 140 concAtenAtes encrypted combined block 750, encrypted random key RK-l 760, encrypted capture token 780 and encrypted random key RK-2 790 to form merchant authorization response 325. Figure 7J depicts merchant authorization respon~e 325 comprising encrypted comhin~-l block 7S0, encrypted random key RK-l 760, encrypted capture token 780 and encrypted random key RK-2 790. In function block 685, payment gateway computer system 140 trAn~mit~ merchant authorization response 325 to merchant system 130.
P~,~e.~ Authorization Rcsl~o~se P~ces~ g Figure 8 depicts the detailed steps of processing a payment authorization response.
In function block 810, merchant computer system 130 applies its private key to encrypted random key RK- 1 760 contained within received merchant authorization response 325, thereby dc~ ing it and obtaining a cleartext version of random keyRK-l 740. In function block 820, merchant computer system 130 applies random key RK- 1 740 to encrypted combined block 750, thereby decrypting it and obtaining a cleartext version of combined block 730. Combined block 730 comprises basic authorization response 710, a copy of payment gateway computer system's 140 ~ignAtllre public key certificate 720, as well as payment gateway digital siE~n~tllre 725. In function block 830, merchant computer system 130 verifies payment gateway computer system's 140 signature public key certificate 720. Merchant computer system 130 ~lrc,.ll-s this verification by making a call to the certification authority associated with the certificate. If verificAti~ n of the certificate fails, merchant computer system 130 concludes that the authorization response is counterfeit and treats it though the authorization request had been reiected. Infunction block 840, merchant computer system 130 vAlitlAt~s payment gateway digital signature 725. Merchant computer system 130 pelrGlllls this validation by calculating a message digest over the content~ of the combined basic authorization request 710 and the signature public key certificate 720. Merchant computer system 130 then decrypts digital signature 725 to obtain a copy of the equivalent message digest cAlclllAtecl by payment gateway computer system 140 in function block 640. If the two message digests are equal, the digital ~ignAture 725 is VAli~lAtP-l If validation fails, concludes that the authorization response is counterfeit and treats it though the authorization request had been rejected. In function block 850, merchant computer system 130 stores encrypted capture token 780 and encrypted random key RK-2 790 for later use in payment capture. In function block CA 022~8648 1998-12-16 WO 97/49050 PCT~US97/10402 860, merchant computer system 130 p~uces3es the customer purchase request in accordance with the authorization response 710. If the authorization response in~lic~tes that payment in authorized, merchant computer system 130 fills the requested order. If the authorization response in-lir~t~s that payment is not authorized, or if merchant computer system 130 d~t~ ined in function block 830 or 840 that the authorization response is counterfeit, merchant computer system 130 inflic~tes to the customer that the order cannot be filled.

Pa~,~e..l Capture Figure 9 depicts an overview of the method of securely supplying payment captureinformation to payment gateway 140 in order to obtain payment capture. In function block 910, merchant computer system 130 generates a merchant payment capture request 915 and transmits it to payment gateway computer system 140. In function block 930, payment gateway system 140 processes the payment capture request 915, generates a payment capture response 925 and transmits it to merchant computer system 130. In function block 920, merchant computer system 130 processes payment capture response 925 and verifies that payment for the goods or services sought to be obtained by the customer have been captured.

P~cnt Capture Request Generation Figure 10 depicts the detailed steps of generating and tr~n.~mitting a payment capture request. Figures 1 lA through 1 lF depict views of the payment capture request and its ccl.lpc",ent parts. In function block 1010, merchant computer system 130 creates a basic capture request 510. The basic capture request is a data area that includes all the information needed by payment gateway computer system 140 to trigger a transfer of funds to the merchant operating merchant computer system 130. Spe.~ific~lly, a capture request includes a capture requestamount, a capture token, a date, summary information of the purchased items and a Merchant ID (MID) for the particular merchant. Figure 1 lA depicts basic authorization request 1110. In function block 1020, merchant computer system 130 combines basic capture request 1110, a copy of its encryption public key certificate 1115 and a copy of its .Cign~tllre public key certificate 1120. Merchant computer system 130 calculates a digital si~n~ture 1125 for the combined contents of the combined block 1130 colllpli~ g basic capture request 1110, the encryption public key certificate 1115 and the ~ign~tvre public key certificate 1120, and appends it to the comhin~ti-7n of the combined basic capture request 1110, the encryption public key certificate 1115 and the signature public key certificate 1120.

CA 022~8648 1998-12-16 The merchant computer system cAlclllAtes digital ~iEnAtllre 1125 by first calculating a message digest over the contents of the t~nmhinerl basic capture request 1110, the encryption public key certificate 1115 and the si nAture public key certificate 1120.
The message digest is then encrypted using the merchant co,~ tel system's 130 digital signAtllre private key, thus forming a digital sign~tl~re.

Figure 1 lB depicts the combined block 1130 formed by function block 1020 and containing basic capture request 1110, the encryption public key certificate 1115, the signAtl]re public key certificate 1120, and digital signAtl~re 1125. In function lO block 1030, merchant computer system 130 generates a random encryption key 1140, denoted as RK-3. Random encryption key RK-3 1140 is a symmetric encryption key. Figure 11C depicts random encryption key RK-3 1140. In function block 1040, merchant computer system 130 encrypts cornbin~d block 1130 using random encryption key RK-3 1140 to form encrypted combined block 1150. Figure 15 1 lD depicts encrypted combined block 1150. The encryption state of encryptedcombined block 1150 is grAphirAlly shown by random key lock 1155, which indicates that encrypted combined block 1150 is encrypted using random key RK-3 1140. In function block 1050, merchant computer system 130 encrypts random encryption key RK-3 1140 using the public key of payment gateway system 140 to 20 form encrypted random key 1160. Figure 11E depicts encrypted random key 1160.The encryption state of encrypted random key 1160 is graphically shown by payment gateway public key lock 1165, which in-licAtes that encrypted random keyRK-3 1160 is encrypted using the payment gateway public key. In function block 1060, merchant computer system 130 concatenates encrypted combined block 25 1150, encrypted random key 1160, and the encrypted capture token 780 and encrypted random key RK-2 790 that were stored in function block 850 to form merchant capture request 915. Figure 11F depicts merchant capture request 915, comprising encrypted combined block 1150, encrypted random key 1160, encrypted capture token 780 and encrypted random key RK-2 790. In function block 1070, 30 merchant computer system 130 transmits merchant capture request 915 to payment gateway system 140.

P~e~l Capture Request P~cc~ .g Figure 12 depicts the detailed steps of processing a payment capture request and35 generating and transmitting a payment capture request response. Function blocks 1210 through 1245 depict the steps of processing a payment capture request, while function blocks 1250 through 1285 depict the steps of generating and transmitting CA 022~8648 1998-12-16 a payment capture request response. In function block 1210, payment gateway computer system 140 applies its private key to encrypted random key 1160 contained within l~c~;v~d merchant capture request 915, thereby de~ly~Jling it and obtaining a cleartext version of random key RK-3 1140. In function block 1215, payment gateway computer system 140 applies random key RK-3 1140 to encrypted combin-~(l block 1150, thereby de~ Li~lg it and obtaining a cleartext version ofcombined block 1130. Combined block 1130 comprises basic capture request 1110, a copy of merchant computer system's 130 encryption public key certificate1115 and a copy of merchant computer system's 130 Qign~tllre public key certificate 1120, as well as merchant digital sign~tllre 1125. In function block1220, payment gateway computer system 140 verifies merchant computer system's 130 encryption public key certificate 1115 and merchant computer system's 130 ~igns~tllre public key certificate 1120. Payment gateway computer system 140 pel~oll~ls this verification by making a call to the certification authorities associated l 5 with each certificate. If verification of either certificate fails, payment gateway colllpuLel system 140 rejects the capture request. In function block 1225, payment gateway computer system 140 v~ la~t~s merchant digital signature 1125. Payment gateway computer system 140 performs this validation by calculating a message digest over the contents of the combin~d basic capture request 1110, the encryption public key certificate 1115 and the signature public key cel Lir~cate 1120. Payment gateway computer system 140 then decrypts digital sign~tllre 1125 to obtain a copy of the equivalent message digest calculated by merchant computer system 130 in function block 1020. If the two message digests are equal, the digital signature1125 is v~ te-l. If validation fails, payment gateway computer system 140 rejects the capture request. In function block 1230, payment gateway computer system 140 applies its private key to encrypted random key RK-2 790 contained within received merchant capture request 915, thereby de~ ting it and obtaining a cleartext version of random key RK-2 775. In function block 1235, payment gateway computer system 140 applies random key RK-2 775 to encrypted capture token 780, thereby decrypting it and obtaining a cleartext version of capture token 770. In function block 1240, payment gateway computer system 140 verifies that aproper transaction is being tr~n.Qmitted between capture token 780 and capture request 1110. A capture token contains data that the gateway generates at the time of authorization. When the authorization is approved, the encrypted capture token is given to the merchant for storage. At the time of capture, the merchant returns the capture token to the gateway along with other information required for capture.
Upon receipt of the capture token, the gateway compares a message made of the CA 022~8648 1998-12-16 W O 97/49050 PCTrUS97/10402 capture request data and the capLù.c token data and tr~n~mit~ this information over a tr~tlitionAl credit/debit network. If an il..~lope-l~y formatted transaction is detected, payment gateway computer system 140 rejects the capture request. In function block 1245, payment gateway computer system 140 determines the 5 financial institution for which capture is requested by inspection of basic capture request 1110. Payment gateway computer system 140 contacts the a~l~.u~liate fin~nçif~l institution using a secure means, e.g, a direct-dial modem-to-modem connection, or a proprietary internal network that is not ~-~ces.~ihl~ to third parties, and using prior art means, instructs a computer at the fin~n~i~l institution to l O perform the requested funds transfer after settlement.

P~,...e~ C~ Rcs~ e 1'~ -~ ''~
Function blocks 1250 through 1285 depict the steps of generating and transmitting a payment capture request response. Figures 13A through 13F depict views of the l 5 payment capture response and its component parts. In function block 1250, payment gateway computer system 140 creates a basic capture response 710. The basic capture request is a data area that includes all the information to in~ic~te whether a capture request was granted or denied. Figure 13A depicts basic authorization request 1310. In function block 1255, payment gateway computer system 140 comhines basic capture response 1310, and a copy of its signature public key certificate 1320. Payment co-llputer system 140 c~ llAt~s a digital signature 1325 for the combined contents of the combined block 1330 comprising basic capture response 1310 and the ~ign~tllre public key certificate 1320, and appends the ~i n~ture to the cornhin~tion of the combined basic authorization request 1310 and the signature public key certificate 1320. The payment gateway computer system calculates digital signature 1325 by first calculating a messagedigest over the contents of the combined basic capture response 1310 and signature public key certificate 720. The message digest is then encrypted using the merchant computer system's 140 digital ~ign~tllre private key, thus forming a digital ~ign~tllre~

Figure 13B depicts the combined block 1330 formed by function block 1255 and containing basic capture request 1310, the ~ign~tllre public key certificate 1320, and digital signature 1325. In function block 1260, payment gateway computer system 140 generates a symmetric random encryption key 1340, denoted as RK-4.
Figure 13C depicts random encryption key RK-4 1340. In function block 1275, payment gateway computer system 140 encrypts combined block 1330 using CA 022~8648 1998-12-16 random encryption key RK-4 1340 to form encrypted comhined block 1350. Figure 13D depicts encrypted combined block 1350. The encryption state of encrypted combined block 1350 is graphically shown by random key lock 1355, which in~licRtes that encrypted comhined block 1350 is encrypted using random key RK-41340. In function block 1275, payment gateway computer system 140 encrypts random encryption key RK-4 1340 using the public key of merchant computer system 130 to form encrypted random key RK-4 1360. Figure 13E depicts encrypted random key RK-4 1360. The enc-yl~liol~ state of encrypted random key 1360 is grRphir~lly shown by merchant public key lock 1365, which inrlicRtes that l O encrypted random key 1360 is encrypted using the merchant public key. In function block 1280, payment gateway computer system 140 conrRtrnRtes encrypted combined block 1350 and encrypted random key RK-4 1360 to form merchant capture response 925. Figure 13F depicts merchant capture response 925 comprising encrypted combined block 1350 and encrypted random key RK-4 1360. In function block 1285, payment gateway computer system 140 trRn.~mitc merchant capture response 925 to merchant system 130.

Payment Capture R~ F~c~s~ g Figure 14 depicts the detailed steps of processing a payment capture response. In function block 1410, merchant computer system 130 applies its private key to encrypted random key RK-4 1360 contained within rece.vcd merchant capture response 925, thereby dec.y~Lfi~g it and obtaining a cleartext version of random key RK-4 1340. In function block 1420, merchant computer system 130 applies random key RK-4 1340 to encrypted c~mbine~l block 1350, thereby decrypting it and obtaining a cleartext version of colnhine~l block 1330. Combined block 1330 comprises basic capture response 1310, a copy of payment gatt:way computer system's 140 signature public key certificate 1320, as well as payment gateway digital signature 1325. In function block 1430, merchant computer system 130 verifies payment gateway computer system's 140 ~ignRt-]re public key certificate1320. Merchant computer system 130 performs this verifirRtion by making a call to the certification authority associated with the cel Lificate. If verification of the certificate fails, merchant computer system 130 concludes that the capture response is counterfeit and raises an error condition. In function block 1440, merchant computer system 130 vRlitlRtrs payment gateway digital ~ignRtllre 1325. Merchantcomputer system 130 pelrolllls this validation by calculating a message digest over the contents of the combined basic authorization request 1310 and the signature public key certificate 1320. Merchant computer system 130 then decrypts digital ....

WO 97l49050 PCT/US97/10402 .
sign:ltllre 1325 to obtain a copy of the equivalent message digest calculated bypayment gateway computer system 140 in function block 1255. If the two message digests are equal, the digital ~ign~tllre 1325 is validated. If vAli-l~tion fails, merchant computer system 130 concludes that the authorization response is 5 counterfeit and raises an error con~1ition In functinn block 1450, merchant computer system 130 stores capture response for later use in by legacy system accounting programs, e.g. to ue~ru~ recon~ tion beLwee-l the merchant operating merchant computer system 130 and the fin~n~ l institution from whom payment was requested, thereby completing the transaction. The system of the present 10 invention ~uc---~ imnle~ te deployment of a secure payment terhnolcgy architecture such as the SET architecture without first est~hli~hing a public-key encryption infrastructure for use by consumers. It thereby pel.lliLs immediate use of SET-compli~nt transaction processing without the need for consumers to migrate to SET-csmrli~nt application software.
VIRTUAL POINT OF SALE ~vPOS) DETAILS
A Virtual Point of Sale (vPOS) Terminal Cartridge is described in accordance with a preferred embodiment. The vPOS Terminal Cartridge provides payment functionalitysimilar to what a VeriFone PoS terminal ("gray box") provides for a merchant today, 20 allowing a merchant to plocess ~U~ylllc~lts securely using the Internet. It provides full payment functionality for a variety of payment instruments.
P~ n~t;~nnli1 y Figure 15A illustrates a payment processing flow in accordance with a ~u-ef~ d embodiment. The payment functionality provided by the vPOS terminal is divided 25 into two main categories: UMerchant-Initiated" 1510 and UC-~n~l-mer-Initiated"
lSOO. Some payment transactions require comml]nic~tion with the Acquirer Bank through the Gateway 1530. The normal flow of a transaction is via the vPOS
Cartridge API 1512 to the vPOS C++ API 1514 into the payment protocol layer 1516which is responsible for co--ve- Li..g into the a~ -ulu-iate format for tr~qn~mis~ion to 30 the Gateway for ad~ition~l processing and fulvv~ ling to existing host payment authorization systems. Host legacy format refers to an ~isting authonzation system for credit card approval currently utilized with the VeriFone Point of Sale (POS) gray terminals. The output from the payment protocol layer 1516 is tr~n~mitted to theauthorization plocessillg center via the gateway 1530. These transactions are 35 referred to as "Online Transactions" or "Host Payments." The transactions that can be done locally by the merchant without having to communicate with the Acquirer Bank are referred to as ULocal Functions and Transactions.n To support different CA 022~8648 1998-12-16 types of payment instruments, the vPOS Terminal payment functionality is categul~cd as set forth below.

~ Host Payment F~ t'~ y These transactions require commllnicati-)n with S the final host, either immediately or at a later stage. For ~Y~mpl~o~ an Online Authorization-Only transaction, when initiAt.orl, commllni-~tes with the host immerli~tely. However, an Off-line Authorization-Only transaction is locally authorized by the vPOS terminal without having to communicate with the host, but at a later stage this off-line authorization transaction is sent to the host.
Within the Host Payment Functionality some transactions have an associated Payment Instrument, while others do not. These two kinds of transactions are:
~ Host Fi.~o~ l Pa~ nrti~"nlity: These transactions have a Payment Instrument (Credit Card, Debit Card, E-Cash, E-Check, etc.) associated with them. For ~x~mple, the aReturn" transaction, which is initiated upon returning a memh~n-lise to the merchant.
~ Host A~mi~ at;~,., Payment F~n~t;nn~lity: These transactions do not require a payment instrument, and provide either ~lmini~trative or inquiry functionality. Examples of these transactions are ~Reconcile~ or the "Batch Close.~
20 ~ Local F'~nC~;onc and Trn .Ctionc- These transactions do not require commnnic~ti~n with the host at any stage, and provide essential vPOS terminal ~ mini~trative functionality. An example of this is the vPOS terminal configuration function, which is required to set up the vPOS terminal. Another example is the ~vPOS Batch Review~ function, which is required to review the different transactions in the vPOS Batch or the Transaction Log.
P~ t Instn~
A preferred embodiment of a vPOS terminal supports various Payment Instruments.
A consumer chooses a payment based on personal preferences. Some of the Payment Instruments supported include:
~ Credit Cards Debit Cards ~ Electronic Cash ~ Electronic Checks ~ Micro-Payments (electronic coin) - 35 ~ Smart Cards CA 022~8648 1998-12-16 W O 97/49050 PCTrUS97/10402 UnRL Table The table below enumerates the URLs coll~sl-u-lding to the transactions supported by the vPOS Terminal Cartridge. Note that the GET method is allowed for all transactions; however, for tr~n~rtions that either create or modify information on S the merchant server, a GET request returns an HTML page from which the transaction is performed via a POST method.

T~ UnRL POST Access Control HosT FINANCL9L PAWENT ~ U~ rIALITY
auth capture /vPOSt/mi/authcaptur allowed merchant e/ login/password auth capture /vPOSt/ci/authcapture allowed no access control auth only /vPOSt/mi/authonly/ allowed merchant login/ password auth only /vPOSt/ ci/ authonly/ allowed no access control adjust /vPOSt/mi/adjust/ allowed merchant login/password forced post /vPOSt/mi/~olced~o:il/ allowed merchant login/password offline auth /vPOSt/mi/oMineauth/ allowed merchant login/ password offline auth /vPOSt/ci/offlineauth/ allowed no access control pre auth /vPOSt/mi/preauth/ allowed merchant login / password pre auth comp /vPOSt/mi/preauthcom allowed merchant p/ login/ password return /vPOSt/mi/return allowed merchant login / password return /vPOSt/ci/return/ allowed no access control void /vPOSt/mi/void/ allowed merchant login / password HOST ADMINISTRATrVE PAYMENT FlJr. _ 1 lONALITY
balance inquiry /vPOSt/mi/bi/ not allowed merchant login/ password CA 022~8648 1998-12-16 host logon tvPOSt/mi/hostlogon/ allowed merchant login/ password parameter /vPOSt/mi/parameters not allowed merchant download dnld/ login/password reConcil~o /vPOSt/mi/reconcile/ allowed merchant login/ password test host /vPOSt/mi/testhost/ not allowed merchant login/password LOCAL ~ur._~lONS & TRAN8ACTION9 accum review /vPOSt/mi/accum/revi not allowed merchant ew/ login/password batch review /vPOSt/mi/batch/revie not allowed merchant w/ login/password cdt review /vPOSt/mi/cdt/review/ not allowed merchant login/password cdt update /vPOSt/mi/cdt/update allowed merchant login/ password cpt review /vPOSt/mi/cpt/review not allowed merchant login / password cpt update /vPOSt/mi/cpt/update allowed merchant login/ password clear accum /vPOSt/accum/clear/ allowed merchant login/password clear batch /vPOSt/mi/batch/clear allowed merchant login/password hdt review /vPOSt/mi/hdt/review/ not allowed merchant login/ password hdt update /vPOSt/mi/hdt/update allowed merchant login/ password lock vPOS /vPOSt/mi/lock/ allowed merchant login/password query txn /vPOSt/ci/querytxn/ not allowed no access control query txn /vPOSt/mi/querytxn/ not allowed merchant login/ password tct review /vPOSt/mi/tct/review/ not allowed merchant login/ password CA 022~8648 1998-12-16 W O 97/49050 PCTrUS97/10402 tct update /vPOSt/mi/tct/update/ allowed merchant login/ password unlock vPOS /vPOSt/mi/unlock/ allowed merchant login/password URL r~es ~ ~tlons This section describes the GET and POST arguments that are associated with each transaction URL. It also describes the results from the GET and POST methods. For URLs that produce any kind of results, the following fields are present in the HTML
5 document that is returned by the vPOS Terminal Cartridge:

txnDate Date of the transaction (mm/dd/yy or dd/mm/yy) txnTime Time of the transaction (hh-m m:ss GMT or hh m m-ss local time) merchantId Merchant ID of the merchant using the vPOS terminal terminalld vPOS Terminal Id txnNum Transaction number of the given transaction txnType Type of transaction For URLs that deal with fin~nri~l transactions, the following fields are present in the HTML document that is returned by the vPOS terminal cartridge:
txnAmount Transaction amount that is being authorized, forced posted, voided, etc.
poNumber Purchase order number authIdentNu Authorization ID number for the transaction m retRefNum Retrieval reference number for the given tr~n~rti-~n pilnfo Payment instrument information. This varies for different payment instruments. For example, in the case of credit cards, the credit card number (piAcctNumber) and expiration date (piExpDate) are returned.
Aocl-mulDte Review URL p'~n~~ Dlity: This is a local information inquiry function that retrieves the local (merchant's) transaction totals (accumulators).
GET A.~ None.
15 GET Results: Retrieves the transaction totals for the merchant. Currently, the total is returned as an HTML document. The transaction totals currently returned are:

CA 022~8648 1998-12-16 creditAmt Total Credit Amount since the last settlement logged in the vPOS terminal creditCnt Total Credit Count since the last settlement logged in the vPOS terminal debitAmt Total Debit Amount since the last settlement logged in the vPOS terminal debitCnt Total Debit Count since the last settlement logged in the vPOS terminal Note: Accum Review is a local function, as opposed to Balance Inquiry which is done over the Internet ~,vith the host.
Ad~ust URL Functi~n~lity: Corrects the amount of a previously completed transaction.
GET Arg~nn~nts: None GET Results: Because the Adjust transaction modifies data on the merchant server, the POST method should be used. Using the GET method returns an HTML form 10 that uses the POST method to perform the transaction.
POST Argl-men~:

pvsTxnNum Previous transaction number txnAdjustedAmou The adjusted transaction amount. Note that the original nt transaction amount is easily retrievable from the previous transaction number.

POST Res~ltc- On success, pvsTxnNum and txnAdjustedAmount are presented in 15 the HTML document, in addition to the transaction fields described above.

Auth Capture URL Fttnr~ n~l;ty: This transaction is a combin~tion of Auth Only (Authorizationwithout capture~ and Forced Post tr~nS~t~tinn 20 GET Arg~m~ntc: None GET Results: Because the Auth Capture transaction modifies data on the merchant server side, the POST method should be used. Usin~ the GET method returns an HTML form that uses the POST method to perform the transaction.
POST A" ~ ..t~

~, . , .. ~, ~ , CA 022~8648 l998-l2-l6 W O 97/49050 PCTrUS97/10402 piAcctNumber Payment Instrument account number, e.g., Visa credit card number piExpDate Expiration date txnAmt Transaction amount POST E2r~ On success, an HTML document that contains the trAn~ tion fields described above is returned. On failure, an HTML document that cont~in.~ the reason for the failure of the transaction is returned. The transaction is logged into a 5 vPOS Terminal transaction log for both instances.
Auth Only ty: Validates the cardholder's account number for a Sale that is performed at a later stage. The transaction does not confirm the sale to the host, and there is no host data capture. The vPOS captures this transaction record and10 later forwards it to confirm the sale in the Forced Post transaction request. GET A.~ None.
GET R~oc~ltc: Because the Auth Only transaction modifies data on the merchant server side, the POST method should be used. Using the GEI method returns an HTML form that uses the POST method to perform the transaction.~5 POST Asg-mr ~;
piAcctNumber Payment Instrument account number, e.g., Visa credit card number piExpDate Expiration date txnAmt Transaction amount POST R~s~ltc On success, an HTML document that contains the transaction fields is returned. On failure, an HTML document that contains the reason for the failure of the transaction is returned. The transaction is logged into vPOS Terminal 20 transaction log for both instances.
NOTE: The /vPOSt/ci/authonly/ URL should be used for customer-initiated tr~n~ti-n~. /vPOSt/mi/authonly/ should be used for merchant-initi~ted transactions.
Rnl~.~~e InquirY
25 URL F'~ ty: Performs an on-line inquiry or the merchant's balance.
GET A~ ~n~c: None GET Res~ s:
MrchtBlnceA Merchant balance amount for a given merchant. The mt balance amount at any given time is the difference bet~,veen . . , CA 022~8648 1998-12-16 W 097/49050 PCT~US97/10402 the credit and debit amount since the last settlement between the merchant and the acquirer.

Batch Revlew URL F'~ ty: Retrieves Rll records from the trRnSRction log or the batch.
GET A.~- -c~ None 5 GET Rr_ 1tc The GET method IGLHe~.s the transactions that have been bRtched inthe vPOS terminal for future reconri1iRtinrl~ The batch can be cleared from the vPOS
terminal after a manual reconciliation between the acquirer and the vPOS. The batch data is retrieved as a set of records and is formatted as a table in the HTML
document. The following fields are present in a typical record:
NTransType Transaction type NPurchOrderNo Purchase order number SzAcctNum Customer's payment instrument account number SzExpDate Customer's payment instrument expiration date SzTransAmt TrRn~Rc~inn amount SzTransDate Transaction date SzTransTime Transaction time SzRetrievalRefN Transaction's retrieval reference number um SzAuthId Authorization ID for the trRn.~cti- n SzOrigAmt Original transaction amount ~RRtchl~um Batch number for the given transaction NCurrencyType Currency in which the transaction was done LnTransNum Tr~n ~ction number CDT Rev~ew URL F'~n~'t;nnslity: Displays the vPOS terminal configuration data colles~ol-ding to the Card Definition Table (CDT).
l5 GET A~ None GET Res~ltc: The GET method returns a default HTML form that contains the current configuration values. The form can be mo~lifi~d and posted using the /vPOSt/mi/cdt/update/ URL to update the card definition table. Not all fields in the card rlt~fini~il n table are e~ ahle The following fields are returned in a form to the 20 user:

CA 022~8648 1998-12-16 W O 97/49050 PCTrUS97/10402 NHostlndex Index into the Host Definition Table or the Acquirer that maps to this card issuer.
SzPANLo Low end of the PAN (Primaly Account Number) range SzPANHi High end of the PAN range NMaxPANDigit Maximum number of digits in the PAN for this acquirer.
NMinPANDigit Minimum number of dits in the PAN for the acquirer SzCardLabel Card Issuer's name Transactions Specifies if a particular transaction is allowed for a given Available bit card range.
vector CDT Update tio ~lity: Updates the vPOS terminal configuration data corresponding to the Card Definition Table (CDT).
GET A g~ - ': None 5 GET E2~_ 1tc The GET method returns a default HTML form that contains the current configuration values. The form can be filled out and posted using the /vPOSt/mi/cdt/update URL to update the card definition table.
POST A g~ - ': (Editable CDT fields need to be decided.) POST Results: (Depends on editable CDT fields, and therefore needs to be decided.
Clear ~- lotor URl F~ t~ ty: Zeroes out the accumulator totals currently resident in the vPOS terminal.
GET Alg~ - ' : None.
15 GET Results: Presents a form that uses the POST method to zero the accumulators.
POST Arg~m~rt-e: None.
POST ~2es~ltc Zeroes the accumulators/transaction totals in the vPOS terminal.

Clear Batch 20 URL E~n~tiorolity: Zeroes out the transaction logs currently b~tehe~l in the vPOS
terminal.
GET A.~ None.
GET ~_ lte: Presents a form that uses the POST method to clear the batch.
POST Alg'- ~..e ~-~ ~. None.
25 POST Rrs~ltc- Zeroes the transactions that comprise the batch in the vPOS
terminal.

CA 022~8648 1998-12-16 - Forced Post G~i~n~lity: Confirms to the host the completion of a sale, and requests for data capture of the transaction. This is used as a follow-up transaction after doing an Authonzation (Online or Off-line) transaction.
S GET Arg~m~nts: None.
GET R~s~ c: Returns the HTML form for performing the Forced Post transaction.
POST Argnme~s:

pvsTxnNum the previous transaction number from an auth only transaction 10 POST R~s~ltc: On success, pvsTxnNum is presented in the HTML document. On failure, an HTML document is returned that contains the reason for the failure of the transaction.
HDT Review URL Functi~n~lity: Displays the vPOS terminal configuration data corresponding to 15 the Host Definition Table (HDT).
GEI' Arg-m~ntc: None GET Results: The GET method returns a default HTML form that contains the current configuration values. The form can be modified and posted using the /vPOSt/mi/hdt/update URL to update the hosts definition table. Not all fields in the 20 host definition table are editable. The following fields are returned in a form to the user:
szTermld Terminal ID for this vPOS terminal szMerchId Merchant ID for this vPOS terrninal szCurrBatchNu Current batch number existing on the vPOS
m szTransNum Reference number for the next transaction in the vPOS
transaction log/batch. This is generated by vPOS and is not e~it~hle by the merchant.
szTPDU Transport Protocol Data Unit. Required for building the ISO 8583 packet.
InSTAN System trace number; mess~g~ number of the next transaction to be transmitted to this acquirer.
szNII Network International Number. Required for building the ISO 8583 packet.
szHostNarne Name for identifying the host.

CA 022~8648 1998-12-16 nHostType Host type nNumAdv Number of off-line transactions that can be piggy-backed at the end of an on-line transaction.
Data Capture Specifies for which tr~n~tinnS data capture is Required Bit required.
vector:
HDT Update URL F~n~' -lity: Updates the vPOS terminal configuration data co"~spollding to the Host Definition Table (HDT).
GET Arg~m~ntQ: None 5 GET Results: The GET method returns a default HTML form that contains the current configuration values. The form can be filled out and posted to the merchant server using the /vPOSt/mi/hdt/update URL to update the host ~lefinition table Unlock vPOS
URL Fl t- -lity: Local function that starts the vPOS at the start of the day.
GET A~ None.
GET R~ Q: Returns an HTML form that uses the POST method to perform this transaction.
POST Ar~ : None.
POST R~8''1~Q Resets a Boolean flag on the merchant server that en?~hl-os 15 tr~n~ctinnS to be accepted by the vPOS terminal.
Offline Auth URL F~ -Dlity: This transaction is same as the "Authorization Only"
transaction, except that the transaction is locally captured by the vPOS terminal without having to communicate with the host. A Forced Post operation is done as a 20 follow-up operation of this transaction.
GET A.~,~- ...e~~ None.
GET ~ Q: Because the Offline Auth transaction modifies data on the merchant server side, the POST method should be used. Using the GET method returns an HTML form for using the POST method to pelro~ the transaction.
25 POST Al~--...~ .-1~s:
piAcctNumber Payment Instrument account number, e.g., Visa credit card number piExpDate Expiration date txnAmt Transaction amount CA 022~8648 1998-12-16 POST ~2e~ tc: On success, an HTML document that contains the transaction fields described in Section 4.1 is returned. On failure, an HTML document that containsthe reason for the failure of the transaction is returned. The tr~n~cti~n is logged into vPOS terminal tr~n~rtion log for both instances.
Pa. -~t ~ r Do~rnload URL FU~O1 :o--olity: Downloads the vPOS configuration information from the host and sets up the vPOS in the event of the configuration data being changed.
GET A~ ---e--~: None GET E2es~lte: Retrieves an HTML form that uses the POST method for the parameterdownload transaction.
POST Arg~m~nfe: None.
POST Results: Downloads the following parameters from the host and uploads them into the vPOS terminal configuration table.
~ card/issuer definition table (CDT) ~ host/acquirer definition table (HDT~
commllnic~ti--ns parameter table (CPT) ~ terminal configuration table (TCT) The various configuration parameters can be reviewed and modified using the URLsfor the desired functionality.
Pre Auth URL F----~ ity: Used in lodging and hotel est~hli~hments to pre-authorize a charge that is completed some time in future.
GET Argllmer~te: None GET Re~lts Retrieves the HTML form for posting the pre-authorizaton transaction.POST Arg~m~ntc:

piAcctNumber Payment Instrument account number, e.g., Visa credit card number piExpDate Expiration date Pre Auth Comp URL F~nrtior~nlity: Completes a pre-authorization transaction.
GET Arguments: None 30 GET Ree~1te: Retrieves the HTML form for posting the pre-authorization completion transaction.
POST A~

CA 022~8648 1998-12-16 pvsTxnNum Previous transaction number from an auth only tr~n~tisn POST Re ltC- On success, pvsTxnNum is presented in the HTML document. On failure, an HTML document is returned that contains the reason for the failure of the tr~n~ction.

R~CQ~'C;1-URL F~_ 9t'Q -lity: This transaction is done at the end of the day to confirm to the host to start the settlement process for the transactions captured by the host for that particular vPOS batch.
10 GET A~ m~.ntc None GET Results: Retrieves the HTML form for posting the Reconcile transaction.
POST A'E,' - ' : None.
POST R~s~lt~ On success, the reconcile function prints any discrepancies in the merchant's batch of transactions and totals vis-a-vis the host's batch of transactions 15 in totals. The output format is a comhin~tion of the output of the Batch Review and Accum Review transactions.
Return ,t~ lity: Credits the return amount electronically to the consumer's account when previously purchased merch~nfli~e is returned. The vPOS terminal 20 captures the transaction record for this tr:~n~ tinn GET A~ --e~ None GET ~2esylt~ Retrieves the HTML form for posting the Return transaction.
POST A.~,. - '~:

Prevl'xnNum Reference to the previous transaction number The previous tr~ns~tion has access to the following fields:

TxnAmount Transaction amount PiAccountNu Payment instrument account number m PiExpDate Payment instrument expiration date CA 022~8648 1998-12-16 POST ~2es-~ltR: On success, pvsTxnNum is presented in the HTML document, in addition to Test Host URL F~ cti~n~lity: Checks the presence of the host and also the integrity of theS link from the vPOS to the host.
GETAr~mçnt~: None.
GET R~s~ltc: On success, an HTML document is returned that reports success in connecting to the host. On failure, an HTML document is returned that reports the error encountered in testing the host.
Lock vPOS
URL F~n~tionolity: This local function locks or stops the vPOS terminal from accepting any tr~ns~ctions.
GET Arg~mentF: None.
GET~2es~ltc: Returns an HTML form that posts the locking of the vPOS terminal.
15 POST Arg~m~ntc: None.
POST R~S~lt~: On success, an HTML document is returned that contains the status that vPOS terminal was successfully. On failure, an HTML document is returned that reports the cause of failure of the operation, e.g., access denied, the vPOS
terminal is already locked or is presently pl..cessing a transaction, etc.
Vold URL Fu..~t - -lity: C~ncel~ a previously completed draft capture transaction.
GET A.~ e~ : None.
GET Res~lt~: Retrieves an HTML form for posting the Void transaction.
POSTAr~... r.~5 pvsTxnNum Transaction number from a previous Auth Only tr~nS~ction .

Host Logon URL Function~lity: Administrative transaction used to sign-on the vPOS with the host at the start of the day, and also to download encryption keys for debit 30 transactions.
GETAr~mentc: None GET Re~ltc: Retrieves an HTML form for posting the Host Logon tr~n~ctinn.
POST A.~ --~ --~ ~: None.

CA 022~8648 1998-12-16 W097/49050 PCTrUS97/10402 ioST I2es~ s Currently, debit card based transactions are not supported. The result is an HTML document int1i~3ting the success or failure of the host logon operation.
CPT Review 5 URL E'~nrti~ns1ity: Returns the vPOS terminal configuration data corresponding to the Comml~nic~tions Parameter Table (CPT~.
GET A~ r-l~: None GET R~S~ltc: The GET method returns a default HTML form that contains the current configuration values corresponding to the vPOS terminal's commllni-~tion10 parameters. The form can be filled out and posted to the merchant server using the /vPOSt/mi/cpt/update URL to update the comm-~nicAtion~ parameter table. The following fields are returned in a form to the user:
SzAcqPriAddress Primary Host address SzAcqSecAddress Secondary Host address SzActTerAddress Tertiary Host address NRespTimeOut Time-out value (in seconds) before which the vPOS
should receive a response from the host CPT Update 15 URL F--.-~ :n-~nlity: Updates the vPOS terminal configuration data corresponding to the Commllnic~ti--ns Parameter Table (CPT).
GET A~g~me~-e: None GET Results: The GET method returns a default HTML form that contains the current configuration values. The form can be modified and posted to update the 20 comm-~nic~tion parameter table.
POST A.'g~

SzAcqPriAddress Primary Host address SzAcqSecAddress Secondary Host address SzActTerAddress Tertiary Host address NRespTimeOut Time-out value (in secon~l~) before which the vPOS
should receive a response from the host POST }~eL lte On success, the HTML document returned by the vPOS contains the 25 values set by the merchant. On failure, the HTML document contains the reason for the failure of the invocation of the URL.

CA 022~8648 1998-12-16 TCT Review URL F. ' ~ ty: Returns the vPOS terminal configuration data co.,~,ponding to the Terminal Configuration Table (TCT).
GET A.~ '~ None.
5 GET ~2~s~ltc The GET method returns a default HTML form that contains the current configuration values. The form can be filled out and posted using the /vPOSt/mi/tct/update URL to update the terminal configuration table. The following fields are returned in a form to the user:
SzMerchName Merchant naIne SzSupervisorPwd Supervisor password FvPOSLock l= vPOS locked, O = vPOS unlocked SzAuthOnlyPwd Password for initiRtine auth-only transaction SzAuthCaptPwd Password for initiating auth with capture transaction SzAdjustPwd Password for adjust transaction SzRefundPwd Password for refund transaction szForcedPostPwd Password for forced post transaction szOfflineAuthPwd Password for offline auth transaction szVoidPwd Password for void transaction szPreAuthPwd Password for pre-authorization transaction szPreAuthCompP Password for pre-authorization completion wd TCT Update 10 URL Functionality: Updates the vPOS terminal configuration data co~ uul~ding to the Terminal Configuration Table (TCT).
GET A~g~ -~tC: None GET R~S-~1tc: The GET method returns a default HTML form that contains the current configuration values. The form can be filled out and posted using the 15 /vPOSt/mi/tct/update URL to update the terminal configuration table.
POST Arg~ments: All arguments in TCT Review functionality are the returned values from the /vPOSt/mi/tct/update the URL.

szMerchName Merchant name szSupervisorPwd Supervisor password fvPOSLock l= vPOS locked, O = vPOS unlocked szAuthOnlyPwd Password for jnitiRtine auth-only transaction szAuthCaptPwd Password for initiating auth with capture transaction szAdjustPwd Password for adjust transaction szRefundPwd Password for refund transaction szForcedPostPwd Password for forced post trAn~ ti- n szOfflineAuthPwd Password for offline auth transaction szVoidPwd Password for void tr~nq~tinn szPreAuthPwd Password for pre-authorization transaction szPreAuthCompP Password for pre-authorization completion wd POST Results: On success, the POST modifies values of the terminal configurationtable parameters. On failure, the HTML document contains the reason for the failure of the trAn~ction S Query 'l r -t'~
URL F~n~ti~ ty: Permits the merchant and customer to query a given transaction corresponding to a transaction number.
GhUr Al~....r ..t c txnNum Transaction number 10 GhUI' R~S~ For a given transaction, the URL returns an HTML document. If a transaction refers to an older transaction, the transaction's entire history is made available.
l~L results Depending upon the method (GET/POST) as well as the success or failure of the 15 HTTP request, different documents are returned to the user. The vPOS terminalprovides a framework whereby different documents are returned based upon a number of preferences. Currently the language and content-type are supported as p,~fe.el.ces. A simple framework is proposed here. Each of the tr~n~ tion has a set of documents associated with it: form for the payment transaction, GET success, 20 GET failure, POST success, and POST failure.

In the directory structure defined below, documents are stored corresponding to the pl~:f~ ,ces. The top level of the directory structure is the content-type, the next level is language (for NLS support). For ~oY~mple, to create text/html content in US
25 English & French, the directory structure given below would contain the HTML
documents for each of the transactions. The vPOS terminal cartridge has a configuration file that allows the user to specify the content-type as well as the language to be used for a cartridge. The first release of the vPOS terminal cartridge supports one content-type and language for each server.

CA 022~8648 1998-12-16 - Data SL.. ~:t.. ~ & F~
Functions A brief description of the Virtual Point of Sale Terminal cartridge fi~nctions are provided below. vPOSTInit(), vPOSTExec(~ and vPOSTShut() are the entry points required for each cartridge in accordance with a preferred embodiment. The otherfunctions implement some of the key vPOST cartridge functionality. In the block diagram shown in Figure 15B, the vPOS provides an interface for transactions which are initi~tP-l both by the consumer and the merchant. The merchant initi~t~s a transaction from a Graphical User Interface (GUI) 1550 and all the transactions that are initiated by the consumer are routed by the Merchant WEB Server 1545.

The Authorization/Data Capture Module 1560 ~.ucesses the requests originated by the merchant or the consumer and routes them to the Protocol Module 1565. The Protocol Module is responsible for building the payment protocol request packet (e.g., an SSL-encapsulated ISO 8583 packet) 1570 before s.on~line the request to the Gateway 1579. Then, the Gateway 1579 awaits a response from the Protocol Module 1565, and upon receiving the response, the Gateway 1579 parses the data and provides unwrapped data to the Authorization/Data-Capture Module 1560. The Authorization/Data-Capture Module 1560 analyzes the response and updates the Transaction Log 1580. The Transaction Log 1580 contains information concerning any successfully completed transactions and the accumulators or the transaction totals. The vPOS terminal creates and maintains the Transaction Log 1580, and the vPOS Configuration Data 1585 contains information which is used to configure thebehavior of the vPOS. The entire vPOS functionality is thread-safe and hence using the vPOS in a multi-threaded environment does not require any additional interfacing requirements. Figures 36-48 are vPOS screen displays in accordance with a preferred embodiment.
P~ t - - l~ty As discussed above, the different Payment Functionality provided by the vPOS
terminal can be divided into two main categories as ~Merchant Initizlte~l" and "Consumer Tnitislte~l.~ Some of these transactions require communication with the Gateway and these transactions are referred to as "Online Transactions." The transactions which can be done locally to the merchant without having to communicate are referred to as "Local Functions/Transactions.~ In order to provide support for many different types of Payment Instruments, the vPOS Payment Functionality have been cate~;~,Hzed. Host payment functionality and transactions require commllnic~ti~ n with the host either immediately or at a later stage. Each of CA 022~8648 1998-12-16 the host finPnfifll payment transactions come to this category and require a Payment Instrument. These transactions can be initiated with different types of Payment Instruments which the vPOS terminal supports.

5 An authorization without capture tr~ns~tinn is used to validate the card holder's account number for a sale that needs to be performed at a later stage. The transaction does not confirm a sale's completion to the host, and there is no host data capture in this event. The vPOS captures this transaction record and later fol wards it to the host to confirm the sale in a forced post transaction request. An 10 authorization without capture transaction can be initi~te-l both by the consumer and the merchant. A forced post transaction confirms to a host computer that a completion of a sale has been accomplished and requests data capture of the transaction. The forced post transaction is used as a follow-up transaction after doing an authorization (Online or Off-line) transaction. The transaction can be 15 initiated only by the merchant. The authorization with post transaction is a combination of authorization without capture and forced post transactions. This transaction can be initiated both by the consumer and the merchant.

The offline post transaction is identical to the "authorization without capturen20 transaction, except that the transaction is locally captured by the vPOS without initiating comml~nic~tion with a host. A forced post operation is done as a follow-up operation of this transaction. This transaction can be initiated by both the consumer and the merchant. The return transaction is used to credit the return amount electronically to the consumer's account when a purchased merch~n~ e is 25 returned. The vPOS captures the return trRn~ctinn record when the merch~n~ e is returned, and this transaction can be initiated only by the merchant. The void transaction cancels a previously completed draft capture transaction. The vPOS GUI
provides an interface for retrieving a tr~nS~ntion record required to be voided from the batch and passes it to the Authorization/Data-Capture module after 30 confirmation. The batch record is updated to reflect the voided transaction after getting an applcv~l from the gateway. This transaction can be initi~te~l only by the merchant.

The pre-authorization transaction is identical to the authorization v~ithout capture 35 tr~ cti~-n, but the consumers' ~open-to-buy~ amount is reduced by the pre-authorization amount. An example of this type of transaction is the "check-in~
transaction in a hotel environment. A check-in transaction sends a pre-., CA 022~8648 1998-12-16 W O 97/49050 PCT~US97/10402 authorization request to the host, so that an amount required for the customers'stay in the hotel is lc:S~ d. The pre-authorization transaction is followed by a pre-authorization complete transaction. This transaction can be initi~ted both by the consumer and the merchant.

The pre-authorization complete tr~n.s~rtinn is done as a follow-up to the pre-authorization transaction. This tr~nR~tinn informs the host of the actual tr~n.s~rtion amount. The pre-authorization complete transaction amount could be more or less than the pre-authorization amount. An ~rAmple is the "check-out"
10 transaction in a hotel environment. The check-out amount can be less than or more than the check-in amount. This transaction can only be initiated by a merchant.

The adjust transaction is initi~ted to make a correction to the amount of a previously completed transaction. The adjust transaction can be initiated only by the 15 merchant. The host ~lmini.~trative transactions do not require any payment instrument. The balance inquiry transaction is used for on-line inquiry into thebalance of the merchant's account. The batch data or the configuration data is not affected by this transaction. The reconrili~ti-)n or close transaction is processed at the end of the day to start the settlement process for the transactions captured by 20 the host for that particular vPOS. The host log-on transaction is an ~lministrative tr~ns~ction which is used to synchronize the vPOS with the host at the start of the day and also initiate a fresh batch at the vPOS terminal.

The parameters download transaction is used to download the vPOS configuration 25 information from the host and set-up the vPOS in the event of any change in the configuration data. A test transaction is used to detect the presence of a host and the status of a link from the vPOS to the host. Local transactions or functions are initi~ted by a merchant and do not require communication with the gateway. Thesetransactions can only be initiated by a merchant. The totals or accumulators review 30 is a local information inquiry function and is used to retrieve the local (merchant's) totals. The detail transaction or the batch review function is used to retrieve all the records from the transaction log or the batch. The clear batch function is used to start a fresh batch. This transaction is utilized to electronically reconcile the vPOS
with the host and to manually reconcile the vPOS with the host. After completing35 the manual recon~ tion processing, the merchant can initiate this transaction to start a fresh batch. The clear accumulator function is similar to the clear batch functionality and resets all vPOS terminal accumulators to zero. This function is CA 022~8648 1998-12-16 W O 97/49050 PCTrUS97/10402 le~ ed when the merchant is not able to reconl~il.o the vPOS with the host electronically. The vPOS unlock or start tr~n~ctinn is a local function used to start the vPOS at the start of the day. The vPOS lock or stop function is used to Lock or stop the vPOS from accepting any transactions. The vPOS configuration setup 5 function is used to setup the vPOS configuration data. The vPOS configuration data is divided into different tables, for ~YRmple, the Card/Issuer Definition Table (CDT), the Host/Acquirer Definition Table (HDT~, the Communic~tion~ Parameters Table (CPT) and the Terminal Configuration Table (TCT). The following sections explaineach of these configuration tables in detail.
Host n~ n Table lHDT~
The table contains information specific to the acquirer.
Field Attributes/ Field DeE .~,~;G.. IC<.. ~ .-ts.
Bytes Terminal Identifler ANS(20) Terminal ID for this acquirer/host Merchant Identifier ANS(20) Merchant ID for this acquirer/host Current Batch N(6) Batch Number for the batch currently existing Number on the vPOS
Transaction I(2) Reference Number for next transaction in the Number vPOS transaction log/batch (vPOS generated~
TPDU AN(10) Transport Protocol Data Unit - Required for building the ISO 8583 packet.
STAN L(4) Systems Trace Number - Message Number of the transaction to be transmitted next for this acquirer.
NII N(3) Netv~rork International Identifier - Required for building the ISO 8583 packet.
Host Name or ANS(20) Name for identifying the host, e.g., UAMEX-SIN~.
Label This is only a text string and is used for the purpose of identifying the host.
No. of advice I(2) No. of off-line transactions (advice messages) messages that can be piggy-backed at the end of an on-line transaction. If set to zero then piggy-b: (~king is disabled.

The following fields specify whether Data Capture is required for a particular 15 transaction for this acquirer.

CA 022~8648 1998-12-16 W O 97/490~0 PCTrUS97/10402 Field Attributes/ Field Des~ .. /CommentR
B~rtes Host Protocol Type 1(2) Host Protocol type, e.g., ISO 8583, SET, etc., Host Protocol Sub- I(2) Sub protocol type, e.g., AMEX-ISO8583, Type MOSET, etc., Auth Only DC Flag Bit(l bit) l = REQUIRED, 0 = NOT REQUIRED
Auth Capture DC Bit(l bit) l = REQUIRED, 0 = NOT REQUIRED
Flag Adjust DC Flag Bit(1 bit) l = REQUIRED, 0 = NOT REQUIRED
Refund DC Flag Bit(l bit) l = REQUIRED, 0 = NOT REQUIRED
Cash Advance DC Bit(l bit) 1 = REQUIRED, 0 = NOT REQUIRED
Flag Cash Back DC Flag Bit(l bit) l = REQUIRED, 0 = NOT REQUIRED
Off-line Auth DC Bit(l bit) 1 = REQUIRED, 0 = NOT REQUIRED
Flag Void DC Flag Bit(l bit~ 1 = REQUIRED, 0 = NOT REQUIRED
Pre-Auth DC Flag Bit(l bit) l = REQUIRED, 0 = NOT REQUIRED
Pre-Auth Complete Bit(l bit) l = REQUIRED, 0 = NOT REQUIRED
DC Flag Card D~ l n~ Table ~CDT~
This table contains information which are specific to the card issuer.
Field ALI.lbules/ Field ~es ~ lon/CG---.. r.. tc Bytes Host Index I(2) Index into the HDT or the acquirer which maps to this card issuer.
PAN Low Range N(l9) Low end of the PAN range .
PAN High Range N(l9) High end of the PAN range.
Minimum PAN I(2) The minimum number of digits in the PAN for digits this acquirer.
Maximum PAN I(2) The maximum number of digits in the PAN for digits this acquirer.
Card Label ANS(20) Card Issuer Name for identification, e.g., VISA.

CA 022~8648 1998-12-16 W O 97/490S0 PCT~US97/10402 .
The following fields specify whether a particular transaction is allowed for a card range.
Field A~ s/ Fielt D~s~ t;o.~/
Bytes Auth Only Allowed Bit(l bit) 1 = ALLOWED, 0 = NOT ALLOWED
Auth Capture Bit(l bit) l = ALLOWED, 0 = NOT ALLOWED
Allowed Adjust Allowed Bit( l bit) l = ALLOWED, 0 = NOT ALLOWED
Refund Allowed Bit(l bit) l = ALLOWED, 0 = NOT ALLOWED
Cash Advance Bit(l bit) l = ALLOWED, 0 = NOT ALLOWED
Allowed Cash Back Allowed Bit(l bit) 1 = ALLOWED, O = NOT ALLOWED
Off-line Auth Bit(l bit) l = ALLOWED, 0 = NOT ALLOWED
Allowed Void Allowed Bit(l bit) l = ALLOWED, 0 = NOT ALLOWED
Pre-Auth Allowed Bit(l bit) l = ALLOWED, 0 = NOT ALLOWED
Pre-Auth Complete Bit(l bit) l = ALLOWED, 0 = NOT ALLOWED
Allowed Com '~n1 i~nc Parameter Table ~CPT) 5 This table contains comm11nic~tions parameters information specific to an acquirer.
The HDT and this table have a one-to-one mapping between them.

Field Attributes/ Field Des~ i~L'- /Commç~tc Bytes Primary Address AN(l00) Primary Host Address (Telephone number, IP
address, etc.) Secondary Address AN(lOO) Secondary Host Address to be used if thePrimary Address is busy or not available.
Tertiary Address AN(lO0) Tertiary Host Address.
Response Time-out 1(2) Time-out value (in seconds) before which thevPOS should receive a response from the host.

Terrninal Cc.... r.~,~,,.~10n Table (TCT~
10 This table contains information specific to a particular vPOS terminal.
¦ Field ¦ Attributes/ ¦ Field nes~ t - /Co~m~

CA 022~8648 1998-12-16 - Bytes Merchant Name ANS(100) Name of the merchant having the vPOS
terminal.
- vPOS Lock Flag Bit (l bit) 1 = vPOS Locked, 0 = vPOS Unlocked Payment Instr!~mrntR
As discussed above, the vPOS terminal supports different Payment Instruments andeach of the Payment Functions described above can be initiated by these different Payment Instruments. The consumer making a purchase from a merchant provides a choice of payment methods depending upon their personal p, efe. ~nce. The Payment Instrument Class Hierarchy which is used by the different vPOS terminal Payment Functions is described below.
Message Sequence Diagram Figure 17 shows a typical message flow between the consumer, merchant, vPOS
terminal and the Gateway. This section describes the different classes listed in the previous section, their data and members, and defines the type of the transaction lS that is to be performed. Processing commences at 1700 when a merchant server eceives a sales order and passes it via the vPOS Graphical User Interfece (GUI) 1710 to an authorizer 1720 for approval and subsequent protocol processing 1730 and ultimately trAnsmi.s~ion via the gateway 1740 to the network.

Class Name:
CV}'CLTroneort;~ n Data:
Transaction Type (int) Transaction Date and Time (CPCLOateTime) Card Definition Table (CVPCL_CDT) Host Definition Table (CVPCL_HDT) Communications Parameters Table (CVPCL_CPT) Terminal Configuration Parameters (CVPCL_TCT) Batch Record (CVPCLBatch) Accumulator Record (CVPCLAccum) Memher Functions:
CVPCLTransaction();
EStatus GetTransType();

W O 97/49050 PCTrUS97/10402 .
EStatus GetTransDateTime(CPCLDateTime&);
EStatus SetTransType(const int);
virtual EStatus Tnit~ eTrans(TvposparamsBlk *) = 0;
virtual EStatus ExecuteTrans(TvPOSResultsBlk *) = 0;
S virtual EStatus ShutDown() = O;

Host Tr ~ on Class D~f. l'- ~
This section contains all the host transaction class definition~:.

Host Transaction Class (CVPC~ ~r IC rl r~ns~
This is an abstract base class derived from the CVPCLTransaction class and is used for deriving transaction classes which need to communicate with the host either imrl~e~ tely or at a later stage.

Class Name:
CVPCT ~ostTrans Data:

Member Fnnctinnc:
CVPCLHostTrans();

Fi - ~-1 Tr-o-neoc~iQn Class (cvpcLFin~n~;olTrans) This is an abstract base class derived from the CVPCLHostTrans. This class is used to derive transaction classes which require a payment instrument (e.g., a Credit Card) associated with them to ~e~ the transaction.

Class Name:
CVPCLF;~ c;olTrans Data:
Transaction Amount (CVPCLAmt) Purchase Order Number (charl]]) Transaction Number (charll) Authorization Identification Number (char[]) Retrieval Reference Number (char[l) Batch (CVPCLBatch) Accumulators (CVPCLAccumulators) Member Functions:

~ -51-CVPCLFin ~ n~i~lTrans(~;
EStatus GetTransAmt(CVPCLAmt&);
EStatus GetPurchOrderNum(char *~;
EStatus GetTransRefNum(char *);
S EStatus GetRetRefNum(char *);
EStatus GetAuthId(char *);
EStatus GetCurrencyType(EPCLCurrency *);
EStatus SetPurchOrderNum(const char *);
EStatus SetTransRefNum(const char ~);
EStatus SetRetRefNum(const char *);
EStatus SetAuthld(const char *);
EStatus SetCurrencyType (const char *) Fi - '-l Credit Card Transaction Class (CVPCLFinCCTrans) This is the base abstract class for the fin~n~ l host transaction which require a Credit Card payment instrument. This class is derived from the CVPCLFin~n~ i~lTrans.

20 Class Name:
CVPCLFlnC~ r Data:
Credit Card Payment Instrument (CPCLCreditCard) 25 r ~emher F unctions:
CVPCLFinCCTrans();

Credit Card Autl~o.l~tiGn Only Tr~ t~ - Class (CVPCL_CrA-~thOnly) 30 This is the class derived from the CVPCLFinCCTrans class and implem-onts the Authorization Only Tr~n~ctir-n.

Class Name:
CVPCL_CçA~thonly 35 Data:

Member Functions:

CVPCL_CCAuthOnly();
EStatus Tnitiali7eTrans(TvposparamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();
S EStatus FormBatchRec();

Credit Card Autho.~ Ic with Capture Tra - ~ t-- Class ~CVPCL_CCA~thCapt~
This is the class derived from the CVPCLFinCCTrans class and implements the Authori_ation with Data Capture Transaction.
Class Name:
CVPCL_CCAuthCapt Data:
Member F~-nl.:t.'- ~:
1 5 CVPCL_CCAuthCapt();
EStatus Initiali_eTrans(TvPOSParamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();
EStatus FormBatchRec();
Credit Card Return Tr~ t'- Class (CVPCL_CCReturn) This is the class derived from the CVPCLFinCCTrans class and implements the Return Transaction.

Class Name:
CVPCL_CCReturn Data:

r~em~er F~ C
CVPCL_CCReturn();
EStatus Tniti~li7eTrans(TvposparamsBlk ~);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();
EStatus FormBatchRec();
Credit Card Pre-Autholi~aticn Transaction Class (CVPCL_CCPreAuth) This is the class derived from the CVPCLFinCCTrans class and impl~ments the Pre-Authorization Transaction.

Class Nsme:
S CVPCL_CCPreAuth Data:
r-- her Fu..et~
CVPCL_CCPreAuth();
EStatus Initi~ eTrans(TvpOSParamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();
EStatus FormBatchRec();

Credit Card Off-line A~ o- 5~ 5~.. Only Tr~n~rti~ Class (CVPCL_CCOfni~A~h) This is the class derived from the CVPCLFinCCTrans class and implements the Offline Authorization Class Transaction.
Class Name:
CVPCL_CCOffli~ vth Data:
Member F~
CVPCL_CCOfflineAuth();
EStatus lnitializeTrans(TvPOSParamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();
EStatus FormR~tchRec();

Credit Card Adjust; ~ Class (CVPCL_CCAd~5ust~
This is the class derived from the CVPCLFinCCTrans class and implements the Adjust Transaction.

Class Name:
CVPCL_CCAd.,5ust Data:

Member F~ L~

CA 022~8648 l998-l2-l6 W O 97/49050 PCT~US97/10402 CVPCL_CCAdjust(~;
EStatus InitializeTrans(TvPOSParamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();
EStatus FormBatchRec();

Credit Card Void Tr ---' - Class (CVPCL_CCVoid~
Thls is the class derived from the CVPCLFinCCTrans class and implements the Void1 0 Transaction.

Class Name:
CVPCL_CCVoid Data:
Member F..,.c~,o~s:
CVPCL_CCVoid();
EStatus InitializeTrans(l'vPOSParamsBlk ~);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();
EStatus FormBatchRec();

Credit Card Forced Post Tr~ncoction Class (CVPCL_CCForcedPost) This is the class derived from the CVPCLFinCCTrans class and implements the Forced Post Transaction.

Class Name:
CVPCL_CCForcedPost Data:
Member F~nc~ nc:
CVPCL_CCForcedPost();
EStatus InitializeTrans(TvPOSParamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();
EStatus FormR~tc.hRec();

.

Pre-Autho.12;6LlG~ C~ te Tr-on~oe~ n Class ~cvpcL-ccpreA~hcomp) This is the class derived from the CVPCLFinCCTrans class and impl~oments the Pre-Authorization Completion Transaction.

5 Class Name:
CVPCL_CCPre ~ C o m~
Data:

Mem~ Fv ~ --Q:
CVPCL_CCPreAuthComp();
EStatus Tniti~1i7eTrans(TvPOSPararnsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();
EStatus FormBatchRec();
Credit Card Rolonre Inquiry Class (CVPCL_CCR~lsneeJ q) This class is derived from the CVPCLFinCCTrans class and is used to ~ rOl-l1 theMerchant Balance Inquiry function.

Class Name:
CVPCL_ Data:

r-em~er F!--~ --Q
CVPCL_CCBalancelnq();
EStatus InitializeTrans(TvPOSParamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();

~A - 53~ Host Tr~o-- r~ " Class (CVPCT J~m;nTTostTrans) This is an abstract base class derived from the CVPCLHostTrans class and is used to derive the administrative host transaction classes.

Clas_ Name:
CVPC-T A~lm;nTT~_L'l-ran_ Data:

W O 97/49050 PCTrUS97/10402 Member FL_O~
CVPCLAdminHostTrans();
int GetHostIndex();
EStatus SetHostIndex (const int);
s n~cQr~n~ Tro~ '- Class (CVPC-T-"~cQ~
This is the class derived from the CVPCLAdminHostTrans class and implements the Reconcile or Close functionality.
Class Name:
CVPC.T.R~conc~ilo Data:

Member F. _t~
CVPCLReconcile();
EStatus InitializeTrans(TvPOSParamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();

Host Log-on Tr-o-nco~ L - Class ~CVPCT TTostT-og~.,) This is the class derived from the CVPCLAdminHostTrans class and imrl~omer~ts the Host Log-on Tr~nsf~rtinn Class Name:
CVPC.T.~Tos~T ogon Data:

Member Fnn~ ne CVPCLHostLogon();
EStatus InitializeTrans(TvPOSParamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();

Parameters Downloat Troneaotinn Class ICVPCLParamsDwnld) This is the class derived from the CVPCLAdminHostTrans class and implements the Parameters Download (vPOS configuration information from the host) functionality.

Class Name:

. .

W O 97/49050 PCTrUS97/10402 CVPCLParamsDwnld Data:

Member Fl -t - -:
CVPCLPararnsDwnld();
EStatus Tniti~li7eTranstTvposparamsBlk ~);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();

Test Transaction Class (CVPCLTe6t~Tost) This is the class derived from the CVPCLAdminHostTrans class and implements the Test functionality which is used to test the host and the link.

Class Name:
1 5 CVPCLTestHo~t Data:

er F~ncti-.ne CVPCLTestHost();
EStatus InitializeTrans(TvPOSParamsBlk *);
EStatus ExecuteTranstTvPOSResultsBlk *);
EStatus ShutDownTrans();

I,ocal Tr~ -' lc Class Defin;tiQnQ (CVPCT T ocslTrans~
This is the abstract base class for all the transactions that are performed locally to the vPOS.

Class Name:
CVPC~T T ocslTrans Data:
Record Number (int) Host Index (int) Member Fn..ct'~ -:
CVPCLocalTrans();
int GetRecNum();
int GetHostlndex() EStatus SetRecNum(const int);

EStatus SetHostIndex(const int);

Virtual POS Lock/Stop Class (CVPCLvPOST ock) This class im~lemrnts the vPOS Lock or the Stop Local functionality. Under the S locked state the vPOS does not accept any tr~n~rtirn requests. The class is derived from the CVPCLLocalTrans base class.
Class Name:
CVPCLvPOSLock Data:
Member F~-n-~t;r CVPCLvPOSLock();
EStatus InitializeTrans(TvPOSParamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();
Virtual POS UnLock/Start Class ~CVPCLvPOSUnlock) This class implements the vPOS UnLock or the Start Local functionality. The class is derived from the CVPCLLocalTrans base class.

Class Name:
CVPCLvPOSUnLock Data:

Member FL__~' ' :
CVPCLvPOSUnlock();
EStatus InitializeTrans(TvPOSParamsBlk *J;
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();

Tr~ne~rt;Q-~ Data A~lm~ L.. ti~n Class (cvpcLTransDz~taA~1min~
This is an abstract base class used to derive the classes which are required to review/manage the tr~n~rtion data which includes the batch data and the accumulator data. The class is derived from the CVPCLLocalTrans base class.

3 5 Class Name:
CvpcLTr~nel)iJt~A~min Data:

Member F--..~t~
CVPCLTransDataAdmin();

Batch Review Class (CVPÇT B ' -hT2eview~
5 This class is derived from the CVPCLTransDataAdmin base class and impl~ment.
the batch review functionality Class Name:
CVPCT P~tcl~l2eview Data:
Member F.. ~ c CVPCLBatchReview();
EStatus InitiRli~eTrans(TvPOSParamsBlk *~;
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();

Clear Batch Class ~CVPCLClF-~ çh) This class is derived from the CVPCLTransDataAdmin base class and implements the clear batch functionality, which is used to clear the batch in the event of doing a 20 manual recon~ tir)n bClwt~ the vPOS and the acquirer.

Class Name:
CVPC-T Cle~rl~atch Data:
Member F- _t;c -:
CVPCLClearBatch();
EStatus InitializeTrans(TvPOSParamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();
~Cc.~ tors Review Class (CVPC'-T Acc~ml?eview~
This class is derived from the CVPCLTransDataAdmin base class and implements the Accumulators Review functionality.
Class Name:
CVPCT A ~c~mT~eview Data:
Member FL__t'- ~:

CVPCLAccumReview(~;
EStatus ~niti~ .eTrans(TvpOSparamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();

Clear A~ tors Class ICVPÇTSl~
This class is derived from the CVPCLTransDataAdmin base class and imp~çment.
the Accumulators Clear functionality.

Class Name:
CVPC'.~-Ck ~ ~A~c~m Data:
Mem~-rF~-nr~i~n~
CVPCLClearAccum();
EStatus InitializeTrans(TvPOSParamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans(~;

vPOS Co~f.Ej,~tion Data AAmi~ ,..tion Class ~cvpcLconfi~n~
This is an abstract base class and is used to derive classes which implement thefunctionality for mPn~ing the vPOS configuration data. The c}ass is derived fromthe CVPCLLocalTrans base class.

Class Name:
cvpcLconfien~ts~ AAmin Data:
~lemh~r F.~ ~_t'- -:
Acq..:ler Data or the Host Der' - Table Review Class (CVPCL_HDTReview) This class is derived from the CVPCLConfigDataAdmin class and implements the 30 Host Definition Table Review functionality.

Class Name:
CVPCL_HDTReview Data:
35 ~ emher F.,__t; -:
CVPCL_HDTReview();
EStatus Tniti~ eTrans(TvPOSParamsBlk *);

EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();

Issuer Data or the Card Def~ Table Review Class (CVPCL_CDTReview~
5 This class is derived from the CVPCLConfigDataAdmin class and implements the Card D~finitinn Table Review functionality.
Class Name:
CVPCL_CDTReview Data:
10 r'~m~er F.
CVPCL_CDTReview();

EStatus InitializeTrans(TvPOSParamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();

Com. ~ ;c~ Parameters Table Review Class (CVPCL_CPTReview) This class is derived from the CVPCLConfigDataAdmin class and implements the Commllnic~tion~ Parameters Table Review functionality.
Class Name:
CVPCL_CPTReview Data:

25 Member F~-nc 1 innc CVPCL_CPTReview();
EStatus InitializeTrans(TvPOSParamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();
Terminal Couri~u.~tion Table Review Class (CVPCL_TCTReview) This class is derived from the CVPCLConfigDataAdmin class and implements the Terminal Configuration Table Review functionality.

35 Class Name:
CVPCL_TCTReview Data:

.. . .. . ...

.
r ~ n~t CVPCL_TCTReview();

EStatus Tniti~li7eTrans(TvposparamsBlk *~;
EStatus ExecuteTrans~TvPOSResu}tsBlk ~);
EStatus ShutDownTrans();

Ac~u;ler Data or the Host ne~ Table Update Class (CVPCL_HDTUpdate~
This class is derived from the CVPCLConfigDataAdmin class and implements the Host Definition Table Update functionality.
Class Name:
CVPCL_HDTUptate Data:
Member Fl~n~t~
CVPCL_HDTUpdate();
EStatus Initi~1i7eTrans(TvPOSparamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();
Issuer Data or the Card Def~ ;QIl Table Update Class (CVPCL_CDTUpdate) This class is derived from the CVPCLConfigDataAdmin class and implements the Card Definition Table Update functionality.
Class Name:
CVPCL_CDTUpdate Data:
Member F~n~t~
CVPCL_C3:)TUpdate();
EStatus ~niti~1i7.eTrans(TvpOSParamsBlk *);
EStatus ExecuteTrans(TvPOSResultsBlk *);
EStatus ShutDownTrans();

vPOS API nefin~ -This section f~ in~ in the vPOS API which are required for interfacing with the vPOS Class Library. All the different vPOS transactions can be initi~tetl using the API defined in this section.
vpO~Tnit;~ .e - Tnit;~ VPOs , CA 022~8648 1998-12-16 W O 97/49050 PCT~US97/10402 This API is used to start and initialize the vPOS. The API tl~finition is disclosed below.
API nefin vPOSBool vPOSlniti~ e(void);
5 P~ t~
None Returns:
TRUE or FALSE in~lir~tin~ whether the function call was a success.

vPOE~F-~ te - F' ~ e a vPOS Transaction This API is used to execute a particular vPOS tr~ns~cti-)n.
API De f~ ~' ~ ~ :
vPOSBool vPOSExecute(TvPOSParamsBlk *, TvPOSResultsBlk P~ ters:
Pointer to the Parameters Structure (TvPOSParamsBlk) Pointer to the Results Structure (TvPOSResultsBlk) Ret-.~c TRUE or FALSE intlic~ting whether the function call was a success.

vPO~ tnown - Shutdown the vPOS
This is used to shutdown the vPOS.
API Definiti~n vPOSBool vPOSShutDown(void) P~r...,.cters:
None Ret..~..c TRUE or FALSE intlic:~ting whether the function call was a success.

vPOS Status Cotes 30 This section details the different status codes (listed under the enumeration EStatus) which the vPOS returns for the different operations performed.
enum EStatus {

eSuccess = 0, // Function call or operation successful eFailure, // General failure evPOSLocked, // vPOS locked, transaction not allowed / / Transaction related error codes .

CA 022~8648 1998-12-16 W O 97/49050 PCTrUS97/10402 ePmtlnstNotSupported, / / Payment Instrument not SU~ol Led eTransNotSupported, // Tr~n~ti-n type not supported eTransInitErr, // Transaction Initi~ flti~n Failed eAdjustNotAllwd, / / Adjust not allowed on this transaction eVoidNotAllwd, // Void not allowed on this transaction eForcedPostNotAllwd, // Forced Post not allowed on this trRn~ ti~n ePreAuthCompNotAllwd, // Pre-Auth. not allowed on this tr~n~rti~n eAmtErr, / / Error in the amount passed eHDTLoadErr, / / Error during loading the HDT table eCDTLoadErr, / / Error during loading the CDT table eCPTLoadErr, / / Error during loading the CPT table eTCTLoadErr, / / Error during loading the TCT table eHDTWriteErr, / / Error during writing to the HDT table eCDTWriteErr, / / Error during writing to the CDT table eCPTWriteErr, / / Error during writing to the CPT table eTCTWriteErr, / / Error during writing to the TCT table eTCTFieldErr, / / Error h~ntlling a TCT table field eT lhnFrr, // Luhn check failed on the account eE~nging~.rr, // Card range not found ePANLenErr, // PAN length error eExpiredCard, // Card expired eInvalidMonth, / / Invalid month in the expiration date eFileOpenErr, / / General file open error eFileCloseErr, / / General file close error vPOS Terminal Arch;~ t e Figure 25 is a block diagram of the vPOS Terminal Architecture in accordance with a led embodiment. The Internet 2500 provides the communication processing necessary to enable the vPOS Terninal architecture. The terminal interface CGI
30 2520 communicates via the Internet to provide information to the vPOS OLE Server 2550 which formats information in accordance with the vPOS API DLL 2560 which uses the protocol class DLL 2570 to flesh out the message for delivery to the Gateway Server 2580. The collection of the vPOS OLE Server 2550, vPOS API DLL
2560 and the Protocol Class DLL 2570 make up the vPOS Software Development 35 ToolKit (SDK) which are used to enable vPOS applications for interfacing with an Operator 2540.

CA 022~8648 1998-12-16 - vPOS/GATEWAy Arc~
The architecture of the Virtual Point of Sale (vPOS) and Virtual Gateway (GATEWAY) architecture maintains SET compli~nce while providing support for additional message types that are not PnAhle~l in SET. The ar~ hitf ctnre includes ;~O1AtjOn of 5 wy~o~ hic details in a single module to f~cilit~te single version ~;~,v~ ent approval while m~,~;...;,.;.~ the fl~xihility of the system for customi7~tion and fzl~ilit:~ting transfer of updated versions on an acquirer specific basis. Figure 18 is a block diagram of the .oxtended SET archiLe~L-Ire in accordance with a preferred embodiment. Processing commences at function block 1800 for a consumer-originated transaction via the World Wide Web (WWW) or 1810 for a merchant-origin~ted transaction on the Internet. In either case control passes imme~ tely to the WWW server 1820 for the tr~mq~-~tion to be appropriately formatted and the appropriate interface page pres~ntecl, whether the transaction is a store front 1822, shopping cart 1824, pay page 1826, standard terminal ~imini~tration 182B-1830 tr~ns~t~tinn~ or an ~xten~ed terminal transaction 1834. If processing requires authentication of the tr~ns~l~tion~ then control passes through the Virtual Point of Sale (vPOSl Application ProgrAmming Interface (API) library 1840 for SET compliant transactions and through the vPOS API ~xtlon~inns library for ~xt-on~ion~ to the SET
protocol. Then, at function block 1842, if the transaction is SET compliant, andfunction block 1864 if the tr~ns~tion is not SET compliant, a library of protocol stack information is used to conform the message before it is tr~n~mitte-l to a Gateway site for ultimate delivery to a bank host 1874 for authorization.

~.xten~led SET messages are pl~,cessed at the Gateway site on a two track basis with the division criteria being SET compliance (which will change over time as more functionality is put into SET) or SET ~xt~n~i~ns. Set compliant messages are processed via the protocol statck library 1862, while SET ~xten~ions are processed via the protocol stack entension library 1864. Then, at function block 1870 the gateway engine plOCeSSeS SET and Host specific code including gateway ~1ministration t~xtension~ 1872 that bypass the normal processing and flow directly from the merchant and consumer server 1820 to the gateway ~imini~tration ~xtf~ nnS 1872 to the Gateway Engine 1870.

As described above, there are three ~~h~nnel~ by which messages are ~xch~n~ed between vPOS 1846 and GATEWAY 18~;6.

1. Standard SET messa~es CA 022~8648 1998-12-16 W O 97/49050 PCT~US97/10402 The standard SET messages are origin~tetl by the merchant software either via a pay page 1826 directly controlled by the consumer, or via an operator interface conqi.qting of a set of HTML pages and associated executables launched by the pages (e.g. pay page 1826 and standard terminal ~rlminiqtration 1828-1830.) Each SET
5 message type (e.g.t authorization v. capture) trRn.~mitq a different set of data and each requires a different Protocol Data Unit (PDU) to describe its enco~ling.
Examples of how Standard SET messages are encoded are given in the SET
docum~nt~tion previously incol~ol~ted by reference.

10 2. Extended SET messa~es The Fxt-on-led SET meSsAees are utilized as an aescape mechAni~m" to implement acquirer-specific messages such as settlement/reconciliation, employee logon/logoff, and parameter download. The messages are developed as a set of name-value pairs encapsulated in a PKCS-7 wrapper and wrapped in Multipurpose Internet Mail 15 ~xt~nqio~q (MIME), described in a book by N. Borenstein & N. Freed, "RFC 1521:
MIME (Multipurpose Internet Mail ~xten~ion~q) Part One: Menh~ni.qm.q for S~e-;iryillg and Describing the Format of Internet Message Bodies" (Sep. 1993). The name-value pairs can have arbill~.y (8-bit) data, so arbitrary items can be passed through the ~xt~n~l~d SET channel, including executable programs and Dynamic Load Libraries 20 (DLL)s. Figure 18B illustrates a multipart MIME message with one Extended SETmessage and one Standard SET authorizing message. Mime is utilized as an outer wrapper 1890 to allow an F.xtPnrl~d SET message 1891 to be tr~n~mitte~l as a compon of messages embedded in one MIME multipart message. In this manner, a standard SET message can be sent with an F'~ten~l~d SET message in one 25 vPOS/GATEWAY communic~tinn tr~n~ntion. Embedding the Extended SET
messages in a PKCS-7 wlappel enables the same message authentication to occur as in standard SET messages. Thus, for SET-compliant and non-SET-compliant messages, the same merh~ni~m may be used to restrict which entities the vPOS or Gateway will trust in any commlmic~tinn.q An important concept in ~:xt~n~led SET30 is that all messages, of any type, are sent in a uniform name/value pair format, thus allowing a single Protocol Data Unit to suffice for any type of mesq~ sent through the Extended SET ch~nn~l Since arbitrary data may be sent this way, a mechAni~m must be provided to preclude the use of the Extended SET channel by parties other than a~lovcd financial institutions. If this is not ensured, then the NSA and the 35 US DepartmerIt of Commerce will not approve the software for export. SET itself to some degree ensures that this Extended SET ch~nnel is used only by financi~l institutions. The protocol stack ~xtenqion library only processes messages that have CA 022~8648 1998-12-16 been signed by a fin~nci~l institution SET certificate that is in turn signed by a payment instrument brand certificate (such as Visa or MasterCard). Stronger control over the FxtPndec~ SET ch~nn~l can be achieved by further l~i,lH.:Lillg processing of messages to those signed (either instead of or in addtion to the 5 fin~nci~l institution SET certificate) by a second certificate belonging to a third-party agency, either ~o~l,.r.lental or private (e.g., VeriFone, as manufacturer of thesoftware~.

In this way, a particular set of Fxtenrl~l SET mess~ges can be implementerl by Bank 10 X, and a different set of messages by Bank Y. If a vPOS has an ~Yt~n-led terminal transaction interface as shown in Figure 18A at block 1834 for Bank X, and has been configured to only accept mess~ees from a Gateway with Bank X's certificate, then it will be able to communicate those messages to a Gateway that has the certificate for Bank X, and accepts mess~g~s of the types in Bank X's message set.
15 The vPOS will not be able to connect to the Bank Y gateway, or to any other system that purports to communicate via F.xten~le~l SET. This restriction is further secured by utilizing a public key certificate that is "hard wired" into vPOS, and which is distributed only to gateways that use the ~.xtendef~ SET meçh~ni~m 20 Figure 18C is an ~x~mple flowchart of message processing in accordance with a~!lerelled ~mborlim~Dnt. Processing commences at function block 1880 when a message is recei~d by an HTTPS server or other listener and passed to decision block 1883 to determine if the sen-ling vPOS has transmitted an authentic message and if the vPOS is authorized to communicate with this gateway. If the message is 25 not authentic, then the message is logged as an error and the error is h~n-llecl as shown in function block 1889. If the message is authentic, then the message is decrypted at function block 1884 and the PDU parses the message into name /
value pairs. Then, based on the message type and the ~xt~n-le-i SET version information, the r~m~ining message is parsed at function block 1885 and the 30 message is ~~he~ke-l for conformance to the appropriate spe-~ific~tion as shown at decision block 1887. If the meSs~ge does not conform, then it is logged and the error handled at function block 1889. If the message conforms to the proper specification in decision block 1887 then the message is tr~n.~l~tlo-l into the a~ o,~,Hate host format and sent to the host as shown in function block 1888.
35 Thus, when a gateway leceives an incoming message from a vPOS and parses the Extended SET portion of the message, a single MIME message can transmit a SET
message and/or an FYt~nrl~d Set Message.

CA 022~8648 1998-12-16 .
An export license for the encryption can be obtained on a case-by-case basis, and since there will be potentially milli~rl.~ of vPOS's, it is desireable to obtain a commodities jurisdiction for the vPOS, to enable a single version of the vPOS (rather 5 than one version for each bank) to be ~U~J~1Ul led by the vPOS a,ul~ re. The archileulll-e described here ensures that the single version of vPOS, no matter how it is configured with extended terminal tr~n~Aeti~n interfaces, cannot be used to communicate any data other than that cont~ined in the extended SET mes~Aees thathave been a~luv~d for export by the US guv~lllment to be used exclusively for a l O specific bank.

Figure 18D is an ~lrAmple of a simple message beL~ l, vPOS and Gateway using the~ten(led SET channel enz~hling an employee to sign on, or "logon" to a given terminal in accordance with the subject invention. The message must contain the 15 employee's logon ID, a password to be verified by the bank host computer, and the date and time as shown at 1894. While the contents of the message are shown without encryption in Figure 18D, it should be noted that the information (including the logon password) are SET encrypted inside the PKCS-7 wrapper 1894. Certain fields may be designAted as mandatory for an l~ t~n~leçl SET message, to allow the 20 Gateway or vPOS to decide how to handle the message. For the sake of clarity, in this message 1894, only two fields, "messAgetype" and "ESETversion", are mandatory. These fields inform the Gateway that this message is of type "logon,"and that the vPOS is using version " l .OA" of the ESET message formats defined for the Gateway. In this embodiment, the length inrlicAtor "[~]" is used to distinguish 25 the length (in bytes) of the field of type "messAeetype" in the message. In this way, there are no special end-of-data characters, and therefore albiLl~.y data need not have any "escAI~e~" characters. It should be noted that using esr~pe~l characters will work equally well. Total message integrity is assured by the digital ~ign~tllres in the PKCS-7 wrapper. This does not, however, preclude the use of other 30 checksllmming schemes for additional pinpointing of tr~n~mi~sion or encoding errors. The messagetype and ESETversion name/value pairs fA~ilit~te Gateway lo~kup of what name/value pairs are expected in the "logon" message. Some name/value pairs may be mAn~lAt~ry, and others may be optional.

35 Figure 18E is an example of a simple m~osSAge between vPOS and Gateway using the Extended SET çh~nnçl lonAhling an employee to sign on, or "logon" to a given terminal in accordance with the subject invention. In response to the logon request CA 022~8648 1998-12-16 W Og7/49050 rcTrusg7/lo402 mess~ge from a vPOS, the Gateway may respond with a "logon accepted" messRge 1894, as depicted in Figure 18E, which vPOS, upon receipt and authentication, then uses to unlock the terminal for that user.

5 Figure 49 shows how the vPOS auth~nti~Ates an in~omine respon~e to a request in accordance with a preferred embodiment. Processing co-mm~onces at function block4930 when a messRee is r ceived by the HTTPS, SET server, or other listener thatorigin~tefl the request to which this reponse co..~ onds. The m~ossRee is passed to ~leri.~i~ n block 4940 to determine if the sen-line Gateway has trRn-cmitte~l an10 authentic message and if the gateway is authorized to communicate with this vPOS.
If the message is not authentic, then the mess~e is logged as an error or possible attack and the error is hRn~ l as shown in function block 4970. If the message is authentic, then the message is decrypted at fi]n~tion block 4950 and the PDU
parses the message into name/value pairs. Then, based on the message type and 15 the ~rten~1ed SET version information, the r~mRining message is parsed at function block 4960 and the messRg~ is ~~h~ k~-l for conformance to the a~,ulupliate sperific~tinn as shown at decision block 4980. If the message does not conform, then it is logged and the error hRn~lle~l at function block 4970. If the meSsRgeconforms to the proper specification in decision block 4980 then the message is 20 trRn~lRte~l into a standardized argument string to be passed to the ap~u,upliale executable or code entry point in the vPOS, as shown in function block 4990. Thus, when a vPOS receives an incoming message from a Gateway and parses the h'~ten~1e~l SET portion of the message, the message may cause vPOS to execute a ~JlU~51alll that takes action or queries the user to take action.
3. Gatewav-intitiated messa~es Since all SET messages beL~ . a merchant and an acquirer are currently merchant-initiated las specified in the SET documentation), there must be a separate merhRnism for initi~ting a mess~g~ from a gateway, for example to request 30 the upload of management information base (MIB) data, or to download new parameters. This is accomplished by requiring the gateway to send a message to the merchant via a MIME-encapsulated PKCS-7 conformant message containing name-value pairs to the merchant server directly, rather than to the SET module. This~-hRnnel is shown in Figure 18A at block 1860.
The message is verified for origination from the acquirer, and is utilized to either initialize a merchant action, such as to update the merchant's R-lmini~tration page CA 022~8648 l998-l2-l6 W O 97/49050 PCTrUS97/10402 (for (".tu~-plc by l~linkine a message saying, ~PLEASE RE-INITIALIZE YOUR
TERMINAL"), or by initiating a request/response message pair ori inAting from the merchant (for ~rzlmrle, ~HERE ARE THE CONTENTS OF MY MIB~). This is achieved by calling one of the ~rt~n-le~l terminal transaction interfaces (Figure 18A at 1834), S which in turn initiztt~s a SET or ~Yte~ Prl SET trztn~strtirtn C~t~ ~y C- 7~c~ t~.. vla the F'-~er~A 8ET ~
Gateway cllstomi7Sttion in eYtencle~ SET is extremely powerful and a novel concept for vPOS l)lucesx;..g. Each vPOS contains one or more ~serial numbers~ unique tol0 each copy of the sofLw~ (a serial number may be embedded in the sorlwal-e, or may be a co--lpo-lent of a public key certificate used in the sorLw~c). Once a merchant has selected an acquirer and obtained the ~pplo~.iate certifirzttes, the vPOS can be customi7ed utili_ing the commnnicztti~)n link and messages containing customi7ation applications. A bank distributes vPOS via different sales ~hztnnel.~ The first is 15 direct from a bank to an ~oyisting merchant with whom the bank already has an~xi~:ting r~ tion~hip. In this case, a version of vPOS already cus~ol..;~l for a bank is sent to the merchant, either directly by a bank, or through a third-party distributor or service bureau. The customi7.zttion~ may involve motlificzttion or repl~- ~mPnt of, for example, a store front 1822, shopping cart 1824, pay page 1826, standard terminal Atlmini.~tration transaction interface 1828-1830 or an extended terminal transaction interface 1834. This is a standard model of distribution of software that is cu~ll t~ e~l for small target market seEm~nts. The more interesting case, and the one that concerns the novel use of the ~rtenflerl SET
~hztnnel, is where the potential merchant acquires, through some non-bank r~hztnnel, a "generic~ vPOS which has not yet been customi_ed to interact with a specific bank.
This vPOS can communicate with a "test gateway~, which the merchant may use to ~;Alue,fi,~ent with the various features of vPOS and to test the integration of the vPOS
into a total online ~oleLu..t. In order to actually transact business over the Internet, the merchant must first obtain a merchant ID from the merchant bank 30 with which he signs an acquiring agreement. For online payment proces~ing, the merchant must also obtain an a~plo~-iate set of digital credentials in the form of public key certificzlt~s and possibly additional passwords, depending on the finztn institution. Once these credentials are obtained, the merchant is ready to customize the already-obtained vPOS to communicate with a merchant bank's gateway.
Using the built-in Lserial number" certificate and the Test Gateway public key certificate (which is "hard-wired" into the vPOS sofware), it is possihle to securely . .

CA 022~8648 1998-12-16 W O 97/49050 PCT~US97/1'J402 download a particular bank's cllQtomi7~tif~n applir~tirJrlc to a specific copy of the vPOS software . Once the vPOS is dp~lol"iately configured, the last stage of cust~mi~tif n download is to configure the vPOS so that it only responds to a public key certificate of the merchant's acquirer. This process is illustrated here in the 5 context of a merchant who obtains a vPOS that talks to the VeriFone test gateway, and desires to customize the vPOS to interact with a gateway at a bank. The merchant has purchased a vPOS from a non-bank c h~nnel The version comml~nic~tf s with the VeriFone Test Gateway. The merchant uses the gateway to learn about using vPOS, and to test the integration of his ~loleLu.lt system with his 10 payment system. The merchant also obtains c~. Lificates for payment processing from a bank, the merchant bank of choise for the merchant. The merchant is now ready to customize vPOS to talk to the bank gateway. The flowchart for the merchant interaction with the Test Gateway is shown in Figure 50.

l 5 The merchant begins at function block 5000, where the newly-obtained merchant SET certificates are inQt~lled in the vPOS. The merchant then directs the vPOS to connect to the VeriFone Test Gateway, by selecting this option from the vPOS
terminal ~fl,--;,,i~LIdtion home page 5005. The choice of this option invokes anr ~tf~nflefl terminal admin page from the default set of such pages supplied with the 20 generic version of vPOS. This program guides the customi~tif n process. The merchant, interacting with the extended terminal admin page, navigates to the list of gateways which is maintained by the Test Gateway, and selects the bank to connect by selecting from the list of banks, at function block 5015. During this process, the merchantts public key cert;fir~tes are uploaded to the Test Gateway, and checked (at 25 decision block 5025) to verify that the certific~trs have been signed by the bank to customize the bank for the vPOS. If the certificates do not match, the merchant is advised of the situation in function block 5028, and must select a different bank. If the certific~tes are not valid SET certific~tes as detected at decision block 5020, the merchant is advised at function block 5028, and the session terminates. If the 30 certificates are valid and match the selected bank, cUstr~mi7~tion continues at fimcti~n block 5030. The extenfletl terminal ~flminiqtration program in vPOS
receives a list of the cllQtf mi~ti~ns from the Test Gateway that must be performed to speri~li7.e the vPOS for a specific bank. Some of these cUstr~mi~tion~s are mslnf1~tory, while others are optional. In function block 5030, the vPOS advises the 35 merchant of the customizations, plu~ g for any choices that must be made by the merchant. The merchant's actions at this point drive ~leriqir,n block 5035, in which the vPOS either returns itself to the ~generic~ state and terminates the .... .

CA 022~8648 1998-12-16 interaction, or begins the configuration of the vPOS, depentling on the merchant's co.,rl,-llation of the request to begin the configuration. If the merchant has authorized the changes, control is passed to function block 5040 where, the POS
storesthe certifirat-?s of any gateways that it will allow future configuration rh~n~l~s 5 to be initiP~te-l from in its ~i~t~b~Re. This may be only a specific bank, such as a bank and the Test Gateway, or other comhin~tions If only a single, non-Test, bank-owned, gateway is allowed to download changes, the vPOS is no longer cu~c...li7.~hlf for any other bank. Then, a new copy would be purchased by the merchant to have it customized for another bank. If the Test Gateway is still allowed to cu~ .e the l0 vPOS, the merchant could switch to another merchant bank and have the current vPOS updated to work with the new bank. In function block 5050, the customi~tion~ are downloaded to the vPOS. The downloads comprise a set of HTML
pages and a set of executable programs or scripts that read data from the merchant, perform various functions, and present data to the merchant. In general, the 15 custnmi~tion~ downloaded may augment or replace in part or in whole any and all of function blocks 1822, 1824, 1826, 1828, 1830, or 1834 in Figure 18A. At a minimum, the terminal "home page~ will be replaced so that it points to the new functionality.At this point, the customi7~tirn of the vPOS has been completed, and the merchant may now begin sen~in~ payment requests to the merchant bank or 20 p,(,ccssor through the vPOS.

Thread Safe vPOS - TID Anocnt~
Physical terminals process a single tr~n~rtir,n at a time since clerks are usually only able to process one transaction at a time. Web Servers can l.~ocess many 25 transactions at a time, so payment requests can often occur simultaneously. Thus, the vPOS Software must have support for multi-tasking and provide ~iU~pOl l for multiple threads to be active at the same time in the same system as well as thesame process. This requirement is relatively straight forward. However, the authorizing banks require that all transaction requests include a Terminal ID (TID), 30 and, for many banks, no single TID may be active in any two transaction requests that overlap in time. Thus, the vPOS requires dynamic allocation of TIDs to requesting threads. One way of providing for multiple TID's is to assign a "base~
TID, and either an ''P~rten~irln~ (a set of extra digits appended to the base), or an increment (a number which is added to the base to obtain the complete TID). While 35 such a solution can be used for the majority of banks and ~,ocessol~, not all banks/processors can accomodate this solution. One r~mrle is First Data Corporation. For its ENVOY protocol, the terminal ID must use the Luhn check as CA 022~8648 1998-12-16 recited in an ISO ransrk, which adds a checksum digit to the the terminal ID to reduce ~~h~nces of fraud or of mi:jly~ed inform~tinn Thus, to be general enough to handle all bank/~.l ocessol sitll~ti~n~s~ a pool of TID's is used. The TlD's stored in the pool need not be a sequential set of numbers; in fact they can be 5 alpha/special/numeric ct~mhin~tinn~ and the TID's need have no relation to oneanother. In a plef~ d embo-lim.ont, a TID is le~l~s. ..ted as a token in a pool that can be a~sori~te~ with a particular transaction. To provide for this requirement, the vPOS provides a TID pool in tabular form in a (l~t~h~e m~n~g~ment system (DBMS~. This table has two colums: TID NAME & Allocation date/time. If the TID
10 date is null, then the TID is not in use and may be ~igne-l A date/time field is utilized to allow TID ~lloc~ti- n~ to expire. TID requests are made utilizing a SQL
query on the TID Pool to find the first null or expired date/time, which is replaced with the current date/time and the TID name returned.

REMOTE vPOS
The unique archtitecture of the Cardholder 120, Merchant 130 and Gateway 140, as shown in Figure lB, provides commllnil~ti--n c~r~bility between the modules utilizing the Internet to support linkages 150 and 170. Since the Internet is sopervasive, and access is available from virtually any computer, utilizing the Internet 20 as the comml]nic~tinn backbone for connecting the cardholder, merchant and access to the authorizing bank through a gateway allows the merchant vPOS software to be remotely located from the merchant's premises. For ~ mple, the cardholder could pay for goods from any computer system attached to the Internet at any loc~tir~n in the world. Similarly, the merchant vPOS system could be located at a central host 25 site where merchant vPOS systems for various merchants all resided on a single host with their separate access points to the Internet. The merchant could utilize any other computer ~ttached to the Internet utilizing a SSL or SET protocol to query the remote vPOS system and obtain capture information, payment ~llministration inform~tion, inventory control information, audit information and process customer 30 satisfaction information. Thus, without having to incur the overhead of maintaining sufficient computer processing power to support the vPOS software, a merchant can obtain the information necess~ry to run a business smoothly and avoid hiring IS
personnel to maintain the vPOS system.
vPOS Multi-Merchant P~vce ~S.-g 35 Multiple merchant ploces~ g refers to the ability of a plurality of merchants to process their individual vPOS tr~n~cti-n~ securely on a single computer. The architecture relies on each payment page obtaining the merchant name in a hidden . . . ~ . .

CA 022~8648 1998-12-16 field on the payment page. The vPOS engine .ece;~,s the merchant name with a particular tr~n~ ti~ln and synchronizes the processing utilizing a Set Merchant method. This comm~nd causes the vPOS API to look up a unique registry tree basedon the merchant name. This process causes the vPOS engine to engage the 5 applopliate configuration to ~,loces~ the tr~n~tiorl at hand utilizing a Registry Tree. A ~ lly tree contains Card D~finitinn Tables (CDT~s, Acquirer Definiti-r~
Tables (ADT)s, Merchant Definition Tables (MDT)s, Protocol Configuration Tables (PCT)s, etc. The CDTs point to specific ADTs since each supported card can be supplied by a distinct acquirer. This is one form of split connection. Each of the 10 ADTs in turn point to PCTs, and some acquirers can support multiple parallel ~;~t~w~y~. A merchant's name refers to a unique cl~t~ba~e in the rl~t~h~e management system which contains for ~x~mple~ TIDs. So, for ~Ampl~, to fully qualify a particular merchant in a multi-merchant system, the Acquirer Definition Table is queried to ascertain the particular Gateway (VFITest), then if Bank of 15 America requires verific~tinn of network communication information, the particular CardDT is accessed with for example VISA. The particular merchant will service VISA tr~n~acti~ns utilizing a particular acquirer. The particular piece of mer~h~n-lise will also be detailed in a data base. Finally, the merchant Configurations wil 1 also be stored in the rl~t~h~F.e to facilitate E-mail and name 20 lookup.

vPOS CLIENT
The interaction between the vPOS and a client commences when a pay page solicitsparameters of a transaction. Then, the parameters are validated to be sure the 25 payment instrument, for example, cardnumber is not null. Then, a transaction object is created, eg. AUTHONLY, and the object is initialized and stuffed with parameters of the transaction, eg. ao.setp~n(~-~çnum), and the object is executed.
This execution invokes the vPOS engine. The vPOS engine further v~licl~tes the parameters based on the particular merchant's configuration. For example, some 30 merchans do not accept American Express Cards, but will take Visa, and all merchants check the expiration date of the card. Assuming a valid and acceptablecard has been tendered, then a TID is as~ign~-l (expiring, existing TIDs) or block a new TID from the TID Pool. This generates a STAN, XID, RRPID unique tag and creates an initial record in the transaction tlz~t~h~e which is flagged as before 35 gateway proces~ing in case the tr~n~ction crashes and must be backed out. Then the protocol parameters are identified in the registry based on card type, and aparticular acquirer irll~ntifi~cl. Then, a protocol object is created and executed to CA 022~8648 1998-12-16 extract results from the protoco} object and the before gateway "bit~ is flipped to again flag the location of the tr~nsaction in the process as it is submitte-l to the Gateway. The results I ~ceived back from the Gateway are placed into a transaction object with is reported back to the pay page and ultimately back to the pay pageS user.

vPOS Merchant Pay Cu I ' '-A novel feature of the vPOS sorlw~e provides payment page customi7~ti- n based on a merchant's ~-crelences. This feature autom~tir~lly lists cards that are accepted by 10 a particular merchant based on the active terminal configuration. Each ~p~lc.ved card for a particular merchant is linked to the display via an URL that provides a pointer to the credit card information ~u~po~ L~d by the merchant. Each card has an entry in a data structure referred to as the Card D~finitio~ Table (CDT). A preferred embodiment of the vPOS merchant pay customi7Ation software in accordance with a 15 ~lefelled embodiment is provided in Figure 19 which illustrates the logic utilizing a flowchart, and a listing of the source code below. Processing co.. ~.. ces at terminal 1900 and immer~ ely flows to function block 1910 where an index variable is initi~ e-l for stepping through each of the accepted payment instruments for the merchant's page. Then, at function block 1930, a URL key is obtained 20 ~soci~terl with the current merchant pay page and index value. The URL key is a l~;isLl~ key name that points to a picture of a credit card that the merchant has associated with the pay page and which the merchant accepts as payment. At output block 1940 the card image associated with the URL key is obtained and displayed on the terminal. The CDT entry is obtained at function block 1950 25 utilizing the URL key. The CDT is utilized for storing information associated with each card. Then, at decision block 1960, a test is p~.rolllled to determine if the last payment method card has been processed and displayed on the merchant display. Ifnot, then the index is incremented at function block 1920 and the loop reiterated to process the next card at function block 1930. If all the cards have been processed, 30 then control is returned to the merchant program for processing the transaction at terminal 1970.

Figures 20A through 20H are block diagrams and flowcharts setting forth the det~iled logic of thread ~loces~ g in accordance with a preferred embodiment.
35 Figure 20A illustrates a prior art approach to POS processing utilized in most grocery stores and department stores today. POS Terminal 2001 accepts transactions provided to it one at a time by customers 2000. For each transaction, .. . . ~ . ~

CA 022~8648 1998-12-16 W O 97/49050 PCTrUS97/10402 POS Terminal 2001 builds a tr~ns~.-tion request 2002 and transmit it to acquiring bank 2004 over commllnic~tions link 2003.

Figure 20B is a data structure 2002 le~resellting a POS transaction request in 5 accordance with a preferred embodiment. The data structure 2002 includes a TIDfield 2005, which identifies the physical terminal from which the transaction origin~t~s In addition to the TID field, the data structure also includes other data 2006 necessd-y to process a tr~nS~tion~ This data includes such fields as a transaction type, a transaction amount, a currency type (such as U.S. dollars), 10 credit card account number, credit card expiration date, etc.

Figure 20C illustrates a vPOS architecture with account requests being processed by a single acquiring bank. vPOS 2007 processes a plurality of customers 2000 concurrently. For each such customer 2000, vPOS 2007 builds a data structure 15 2010, lcplesellting the transaction to be pt:lrol,.,cd for that customer. Each data structure 2010 contains a unique "virtual terminal" ID. vPOS 2007 selects a virtual terminal ID using ~i~t~h~.$e 2008. For each data structure 2010, vPOS 2007 initiates communication with acquiring bank 2004 using commnni~tinn link 2003.

Figure 20D is a data structure 2010 leplescllting a vPOS transaction request in accordance with a plefel,èd embodiment. The data structure 2010 includes a TID
field 2012, which identifies a virtual terminal ID ~.~soci~t~cl with a particular transaction. In atl-litinn to the TID field 2012, the data structure also includes other data 2006 necess~y to process a tr~n~a~ti- n. This data includes such fields as a transaction type, a transaction amount, a currency type (such as U.S. dollars), credit card account number, credit card expiration date, etc.

Figure 20E illustrates a TID allocation ~i~t~hAse 2008 in accordance with a ~lerelled embofliment. D~t~h~se 2008 includes a TID allocation table 2011. TID
allocation table 2011 includes a plurality of rows, one for each TID used by each acquiring bank. One such row 2013 is illustrated in detail. Row 2013 includes a good/service order (GSO) identifier 2014, which identifies the order being transmitted; a TID field 2015, which identifies a terminal ID that may be used with a particular acquiring bank; and an acquiring bank field 2016, which identifies the acquiring bank for which the TID is valid. In ~ 1itir~n, row 2013 may optionallyinclude other fields 2017 that may be used in conjunction with the order procesc~ing , CA 022~8648 1998-12-16 W O 97/49050 PCT~US97/10402 A null GS0 value inr~ tes that the TID/Acquirer combinAtion is not currently in use.

Figures 20F through 20H are flowcharts of the detailed logic used to perform virtual 5 terminal ID allocation. Figure 20F illustrates the main line operation of virtual TID
allocation. In step 2020, execution begins. In step 2021, a skeletal transactionrequest structure is ~le~alcd. In step 2022, the main line routine obtains a virtual TID for inclusion within the trQns~ction request structure, as will be more fully disclosed with lefe~ ce to Figure 20G, below. In step 2023, the routine verifiesl O that a TID was obtained. If the TID was not obtained, for example, if more tr~n~s~ctinnS are currently being processed than there are TIDs, then execution continues to step 2024. In step 2024, the transaction request is put on a queue for future proces~ing In step 2025, the routine waits for a transaction process to end, which would free up a TID in use. At that point, control resumes from step 2022,15 and the routine again attempts to obtain a TID.

If the TID was successfully obtained in step 2023, control proceeds to step 2026. In step 2026, the routine submits the transaction to the acquiring bank. In step 2027, the transaction is p~ucessed. In step 2028, the routine makes a database call to free 20 up the TID that was used in the trans~ctinn. In step 2029, transaction processing ends.

~igure 20G depicts in detail the process of obtaining a TID from the d~t~h~e Execution begins in step 2040. In step 2041, the routine constructs a ~iAtQhQ~e call 25 to reserve a TID for processing, for example, by constructing an SQL statement to retrieve a TID row from the riat~h~e. In step 2042, the routine executes the ~AtQhQ~e call that was constructed in step 2041. In step 2043, the routine constructs a second ~i~t~h~se call to extract the TID from the row that was l~s~.v~d in step 2042. In step 2044, the ~l~t~h~e call constructed in step 2043 is executed 30 to obtain the TID. In step 2045, a return code is checked to verify whether the TID
was successfully obtained. If the TID was successfully obtained, control proceeds to step 2046, which returns to the calling plU~;ld.rll. If, however the TID was notobtained, control proceeds to step 2047. In step 2047, the routine checks to seewhether an e~es~iv~ number of retries have already been attempted. If there have35 been an ~"ces~ive number of retries, control proceeds to step 2048, which exits with an error inriic~ti~n If there has not been an ~"cessiv~ number of retries, control proceeds once again to step 2043 to retry the extraction operation.

~ ... . _ . . .

CA 022~8648 1998-12-16 .
Figure 20H depicts the operation of r~le~inE a TID that had been used in a priortransaction. Execution begins in step 2060. In step 2062, the routine constructs a database call to update the row for the selected TID so that the value for the good 5 and service order is null, thereby in~ir~ting that the s~lectecl TID is not associated with any good or service order, and is therefore free for reuse. In step 2064, the routine executes the SQL stS-tem~nts constructed in step 2062, thereby rele~ing the TID for use in future transactions. In step 2069, the routine returns to thecalling program.
Default Gateway Configuration The vPOS is initially shipped ~n~bl~-1 to connect to a default gateway with a single instance of a gateway defined that ~~cesses a pre~ fine~l site for testing of aninst~ tion before bringing it online in a production mode. The test inst~ tinn 15 contacts and converses with an actual gateway that simulates live transactions.
After the installation checks out utilizing a set of test transactions, the test gateway downloads the pre-checked customizations to the instAll~tit n so that it can switch over to the production acquirer. This download processing is ~n~bl~d in eYten.~ ns to SET.
T.~le ~ t TrP~ ~tinn Gateway Payment methods that issue cards for conducting business utilize four major entities. These entities are the issuer, consumer, merchant and the acquirer. The issuing bank that provides the consumer with a credit card are usually not the same 25 bank as the acquiring bank that serves the merchant. When the consumer utilizes a credit card to pay for a purchase, the merchant swipes the card through the POS
terminal which makes a connection to the merchant's acquirer via the telephone network and tr~n.~mits an authorization request with data read from the magneticstripe. The acquirer's host processor, depending on the card number, will either30 p~lfu~ local processing or switch the request to the correct issuing bank's host prûcessùn through the interchange network. In a few seconds, the authorization response is returned to the origin~ting POS inrlic~ting either an approval or a rejection. The Internet is a viable infrastructure for eleuLlollic commerce.
Ubiquitous bl UW~ l software for the World Wide Web provides around-the-clock 35 access to a large base of information content provided by Web servers. Utilizing a plefe..ed embodiment, consumers using L)lUW:~.,l;i can shop at virtual stores and malls presented as Web pages m~n~gecl by the merchants' servers. Consumers can CA 022~8648 1998-12-16 make purchases and pay for them using credit cards or other digital payment instruments in a secure manner. For such Internet-based payments to be authorized, a "gateway" is necess~ry at the back end to ch~nn~l transactions to legacy l.,ocessors and interchange neLwulL~. Figure 21 is a detailed diagram of a 5 multithreaded gateway engine in accordance with a ~,~ere~d embo-liment ProcesQing commences when a TCP transaction 2100 is received by a HTTPS Server 2102 and parsed to an a~,op,iate Web Adaptor 2104 which posts an encrypted set tr~ns~ction to the multithreaded gateway engine 2110. The encrypted SET request is received at a de~,y~tol 2120, decrypted into a standard SET transaction and authenticated for CUI1VC:I Lillg by the forward CO~ lel 2124. Inside the forwardconverter 2124, decides if the request is an original request, and honest retry attempt or a replay attack. The co".,~. Led transaction is passed to the socket multiplexor 2130 to communicate via an existing commnnic~tion link 2140 to a host computer. A security logger 2150 is also utilized for p~ ing security records back via a ti~tQh~e server 2160 to a rl~t~hA~e Rrimini~tration application 2190. A
transaction logger 2155 also utilizes the ~l~t~h~Re server 2160 to capture transaction logs in a ~i~t~hR~e 2180. Other system ~imini~tration tasks 2195 include a web server ~lmini~tration task 2190 which logs web hits in a log 2170.
~ 20 Figure 22 is a flow diagram in accordance with a l~lef~ d embo~1iment Processing flows from customers 2200 that are paying for products over the lnternet or other comm-]nic~tinn medium utilizing HTTPS or other protocols to one or more merchants 2210, 2220 or 2230 to a gateway 2240 which directs transactions to a particular host processor 2250 for authorization p-ocessing in accordance with the present invention.
Internet r. _ ~. .t Author{zation The Gateway is a secure computer system that merli~tes transactions between the merchants' servers and a payment processor. The Gateway supports secure comm-~ni~tinns belween merchants using the Internet on one side, and a processorusing standard secure financial networks on the other side. Between the two interfaces, the Gateway maintains a detailed log of all transactions, whether in-progress, completed, or failed. The Gateway accepts transactions from merchants and C~ lLs them into legacy compatible formats before forwarding them to the host processor. Responses from the host, after the reverse collvel:iions~ will be returned to the origin~ting merchants.
The Gateway performs many functions, including:

CA 022~8648 1998-12-16 W O 97/49050 PCTrUS97/10402 ~ Receives encrypted credit card tr~n~rtion~ from the merchants via the Internet ~ Unwraps and decrypts transactions ~ Authentir~tes digital sign~tllres of tr~n~ tinn~ based on certifiçates ~ Supports all transaction types and card types ~ Accepts concurrent transactions from each of the merchant servers ~ Converts transaction data to legacy formats; forwards the mapped requests (in the clear) to a payment ~ cessor over ~riRtinE comml~ni~tion links ~ Converts transaction responses, correlates them with the original requests, and sends the mapped respon~es back to the merchants ~ Provides logging, monitoring, l~oHi,~g, and system ~-lmini~tration Figure 23 illustrates a Gateway's 2330 role in a network in accordance with a preferred embodiment. The Gateway 2330 strictly conforms to all SET stipl]l~tirn~3 regarding certificate management, PKCS signed data encapsulation, PKCS encrypteddata encapsulation, ASN.l le~les~lltation, DER encoding, MIME encaps-ll~tion, and message sequencing. A merchant server 2300 communicates via the Internet 2310 using the SET protocol 2320 through a gateway server 2330 using a network interface processor 2340 to communicate to a legacy network 2360 in, for e~mrle the X.25 protocol 2350. The legacy host 2370 llltimAtely receives and processes the tr~n~ tion from the merchant server 2300 without mnrlifir~tion to its code.

Inte. -t Commu -ir~t:~ P~otocolc As discussed above, the TCP/IP protocol suite is utilized at the transport level. At the application level, in compliance with SET, all requests arrive at the Gateway in MIME encapsulated HTTP format. Similarly, all responses from the Gateway to the merchant servers will be transferred in HTTP. The HlVrP protocol stipulates that a request-response pair will go through the same TCP connecti~ n and that the originator, in this case a merchant server, will est~hli~h a connection to send the request and will talce down the connection when it has received the response.

Host Payment r~otocols Message con~ Yions performed by the Gateway will be ~igni~lc~ntly more than forrnat transliterations: per-protocol differences in data elements and message semantics must be considered carefully. Some of the transaction types that are supported are listed below.

CA 022~8648 1998-12-16 Credit card sale with capture Credit card sale without capture - Credit card sale with capture including AVS (MasterCard and VISA) Credit card sale v.~ithout capture including AVS (MasterCard and VISA) Credit card return (Credit) Credit card post authorization (Force Post) Credit card post authorization (Force Post) with partial reversal support, enhanced authorization data, and AVS result code (VISA) Credit card sale with capture - Void Credit card return (Credit) - Void Totals request (for balancing~

Host Comml~n~ ~s P.utocols A virtual, private network between the Gateway and the host processor is established to expedite host commt~nic~tinn~ In addition, two Network Interface S Processors (NIP)s - a "near end" NIP that interfaces to the Gateway and a "far end"
NIP that interfaces to the host. The NIPs will handle virtual connections between th~m~l-]ves. The far-end NIP will take care of specific commllnir~tinn details. The near-end NIP is an IP-addressable device that ~:Dl~v~,l LS between TCP messages and packets. It is installed on a public network 2330, which is a LAN outside the 10 corporate firewall. The Gateway, on the secure public network 2330, uti}izes TCP/IP
2320 to communicate with the near-end NIP.

GATE WAY FEATURES
Because the Gateway must sustain reliable operations and enable graceful evolution, 15 it is ~le~igned with some important attributes, including: Security, Availability, Performance, Scalability, and Manageability.
Secur~ty Channel Secuntu At the application level, SET provides signed and encrypted data encapslll~tinns of 20 p~yl~lellt information portions of the transaction meSS~ge~S. Transport-levelencryption of the entire message packet is required for ~ tion~l security. The HTTPS protocol - i.e., HTTP over SSL 3.0 - is utilized between the merchants and the Gateway. The virtual connections between the near-end NIP and the host are part of a private network. The termination will occur outside the firewall. Data between the . , ." . ... .. . .... . . .

CA 022~8648 1998-12-16 Gateway and the host is sent in the clear with no encryption. In this network configuration, a transaction between a merchant's vPOS and the host will cross the firewall four times: SET request from vPOS to Gateway, legacy request from Gateway to NIP, LEGACY response from NIP back to Gateway, and SET respon~e from Gateway back to vPOS.
Certificate Manaqement P~ - ' P~tocol Co,LIrc~t~s The Gateway uses certific~t~s to authenticate the two parties involved in each MOSET transaction. Through a Certificate Authority, one certificate is issued for the 10 Gateway and one certificate for each of the merchant servers.
Secure C-h~nn~l Certifi~st~
SSL will require separate certific~tes for the Gateway and the merchants.
A~i7~htlity Site redundancy and location redundancy allows the Gateway to sustain service 15 through virtually instantaneous l ecuveI ~ from internal failures or external disasters that cause physical damages to the system. Minimum-outage recovery is possible v~ith redundant configurations of important components.
Site Redundancu The Gateway supports connections to a proprietary bank network and supports 20 lllil l ul ed disk arrays.
Locahon ~edundanc7l The Gateway architecture supports location redundancy where a secondary remote system is connected to the primary system via dedicated WAN links for software-driven database duplication.
25 Scala~ilitll The Gateway software architecture, the choice of third-party software coIllpc.llents, and the selection of hardware platforms enable the system to gracefully adapt and evolve to take on new demands in different tiim~n.eiions.
The Gateway resides on an HP 9000 that is housed in a standard 19" EIA rack.
Gateway Hardware CG~r.g~ tl ~ Se~cr Hardwarc DC~ tlG~
K-CIass SNlr Scrvcr- Modcl K420- ~;ts~ .d Confi~ura~ion 120 MHz PA-RISC 7200 CPU

Built-in I/O includes Fast/Wide/Differential SCSI-2, EtherTwist 802.3 LAN, WO 97/49050 PCT~US97/10402 - AUI, RS-232C Connectors, Centronics Parallel Port, and Internal Modem 650 MB CD-ROM Drive HP-UX 10. 10 Operating System (with two-user license)

4 HP-PB Slots SCSI-2 Disk Controller to support disk ~Lrl~ g over dual SCSI-2 buses 2 GB Internal SCSI-2 Disk Dnve, 20MB/s transfer rate, not mirrored for systems so~ware and swap space 4 GB External High-Availability Disk Arrays for d~2tabases - total of 4 x 2 MB mo~ules re~uired 4 GB DAT drive with data CO~ s~ion HP-PB Slot Expansion Option provides 4 additional HP-PB slots for penpheral controllers 2 FDDI interface cards (each card uses 2 HP-PB slots) Option for eight-user license for HP-UX

C~ !~Luy~ .~hic N.., ~w~, ~
The encly~Lio-l and decryption algorithms used in processing SEI/SSL messages require ~ nifir~nt computational power. A "security ~ulocessol" is deployed with the

5 Gateway to boost the p~lrul~llance of cryptographic algorithms. The ~roccssor is a networked peripheral device to the HP 9000 server. It provides cryptographic services suitable for SET/SSL processing, and its services are accessible via calls to software libraries running on HP-UX. Figure 24 is a block diagram of the Gatewayin accordance with a plcrtllcd embodiment.
Gateway Archi~ct~e 0~ Li,~g System So~ware The Gateway runs under the HP-UX Version 10.10 operating system and is upgraded to support future ~ignifi-~nt system releases. HP-UX 10.10 conforms to 15 major standards, including:
~ X/Open UNIX 95 (conforming with the Single UNIX Specifi~tion, SPEC 1170) ~ X/Open Portability Guide Issue 4 Base Profile (XPG4) OSF AES
IEEE POSIX 1003.1 and 1003.2 AT&T System V Interface Definition (SVID3 base and kernel ~ten.cions subset) 20 I,evel 1 API support , . , . ._.. .. .

CA 022~8648 1998-12-16 W 097/49050 PCT~US97/10402 ~ UC Berkeley Software Distribution 4.3 (BSD 4.3) including such features as jobcontrol, fast file system, symbolic links, long file names, and the C shell System V.4 File System DirecLol~ Layout This compliance with various sofLw~re standards assures that while a ,ureft.-~,dembodiment of the invention is tii~clf~sec~ in association with a best mode of practicing the invention other similar software and hardware ~llvi.ulllllents can be readily substituted without undue CA~ t~tion F~1~7tton~l na~Ah~-se Manas- ~. t ~ystem ~RDBMSJ Software The Gateway uses Oracle7 Server version 7.3 as the RDMBS and will be upgraded to10 use future si~nifi~nt system releases. The multi-threaded, multi-server architecture of Oracle7 provides applications with scAl~hility to high-volume trz.n~ ti~n workloads. When deployed with the HP 9000 K-Class platform, Oracle7 performs a symmetrically parallel ~i~t~h~e operation across all available processors.
In addition, Oracle7 includes options for creating high-availability systems:
15 . The Oracle7 Parallel Seruer option extends the reliability of applications by transparently harnessing the power of clustered computers in a single logical processing complex that can tolerate individual machine failures.
~ Oracle7 Symmetnc Replication provides high data availability. Data can be replic~tefl from the primary system to one or more alternative sites.
~TTP Seruer The Gateway utilizes Netscape's Entel,ulise Server 2.0 as the HTTP server. The server is designed for large-scale Internet commerce deployment, Enterprise Server 2.0 achieves ~.rc,llllance and reliability with such features as o~Lilllized c~hing, SMP support, enhanced memory management, and SNMP-based performance 25 monitoring. liffit~i~nt process management features minimi7e system load and increase server reliability. Security features are provided using the SSL 3.0 protocol.
~ otocol Stacks Internet and LAN - The TCP/IP protocol stack will be provided as part of the HP-UX
operating system.
30 Other Application-Level Protocols Application-level protocols enable client-server interoperability. Each of the following protocols are transported using TCP or UDP.
HTML. HTML will be used to define screens for Gateway system ~imini~tration~
HTTP. The HTTP layer is part of Enterprise Server 2Ø The server is 35 ~rimini~tered with a Web bluw~el .

~ 8QL*Net. The Gateway's Oracle7 rl~t~h~e can be ~-~cesse-l by ~lmini~tration clients using SQL~Net. Administration software can est~hlish database connectivity to leLli~ve data for generating transaction reports.
~ SNMP. Enterprise Server 2.0 can be monitored using SNMP. The Gateway 5 utilizes SNMP for remote system management.
~ransaction Performance Monitorinq and Measurement ~ The ~hits~ performance indicators are available from the Web server. Statistics can be generated at any time to hi~hlight the load pattern or to pinpoint the time when the server was most active.
10 ~ Gateway statistics about transaction requests (by transaction type) and transaction results (e.g., success, failed due to host, failed due to authentication, etc.) can be determined at any time for a particular time interval by generating a report.
The Gateway is upgradeable to interoperate with a real-time event monitoring 15 system such as OpenVision's F~lro,l"ance Manager.
Basic Request/~esF~ -e M~
The following table shows the basic request/response mapping between the SET
protocol and the LEGACY protocol.

SET ; LE~C~Re~. -~/12rsF~ ~
-~squé~ 1 ~~~F i . . .: .F!~d I - ' Codc AuthReq, AuthRes LEG/CTR (05) AuthRevReq, AuthRevRes LEG/CTR (99) CapReq, CapRes LEG/CTR (42 or 44) CapRevReq, CapRevRes LEG/ CTR (41) CredReq, CredRes LEG/ CTR (40) CredRevReq, CredRevRes LEG/CTR (90) BalReq, BalRes CTA/CTL (48) ~ t~ Analysis for SEr r-eg~lge T~7~n~ g This section tackles general design considerations of the Gateway software and is not limited to LEGACY (unless specifically mentioned). The complete functional 25 behavior of the Gateway will be described in a separate document.
~2eplay Attack Handling A replay attack at the Gateway is a request where either:

... ... . . . . . . . . . .

CA 022~8648 1998-12-16 W O 97149050 PCTrUS97/10402 a) the request is stale; the request was received ~too late" with respect to the~- g.l~ in the request. This window is specified by a configurable Gateway policy.
b) the request is not stale but the exact rrpid (Request/Response Pair Id) has already been seen before in a request and still logged in the Gateway database. The C~dd, m~d, rrp~d> tuple will be the primary key that determine whether a request had already been received. This will allow the possibility of the same rrpid to be generated from the same merchant but for a xid and also allow the same rrpid to be generated by a totally different merchant.
New Attempt vs. Retry A~
It is possible that messages sent between the vPOS and Gateway may be lost in transit. This could happen either because of hardware/software problems in the Internet or for hardware/software reasons local to the Gateway or Merchant System.
15 The question is then "How does a Gateway recognize an honest retry attempt from an initiator?~ First a little background into the nature of a SET request. All SET
requests have the following fields:
xid merchant's tr~ns~-~tion id mid merchant id (contained in certificate) tid terminal id ~from Merchant System) rrp{d request response pair id reqdate request date (from Merchant System) regdata request specific data 25 Let the following tuple represent a generic SET request:
cxid, mid, tid, rrpid, reqdate, reqdata>

The merchant establishes the xld during the shopping phase with the consumer.
The same xld is used for both the AuthReq and the CapReq and subsequent 30 CreditReq requests. Using the same xid for many requests makes it impossible for the Gateway to distinguish beLw~ repeated transactions vs. new transactions.

For ~ox~mple~ how could a Gateway possibly determine whether two valid CredReq requests were to be int~ led as two individual credits or a retry of a single 35 request.

request 1: ~xidl, midm~ t~dt, rrpidl, reqdatel, reqdatal~ (perhaps a CredReq for $10.00) CA 022~8648 1998-12-16 request 2: <xidl, midm~ tidt,rrpid~,reqd~te~,reqdatal> (perhaps a new CredReq for $10.00 could also be interpreted as...

5 request 1: ~x~d~, midm, ~dt,rrpidl,reqdatez,re~t~l~ (perhaps a CredReqfor $ 1 0.00) request 2: ~xidl, midm~ tidt,rrpid2,req~ ,req~t~l~ (perhaps a retry of above~

The reqdates are different in both cases because the date is generated along with the rrpid to thwart replay attacks. In this example the Gatewav will not be able to determine whether the second CreditReq should be pt,rol"led or whether it is simplv a retr to request 1 with rrpid~. The Gateway must know whether or not to apply ane-~ credit or to deliver a response that it may already have from the host (it may have came too late for the first attempt or have been lost on the wav to vPOS). If no response was logged from the host for request 1, the Gateway could repeat its ori~inal request to the host when receiving request 2. In a sense, the Gateway will act as an intelligent request/response cache.

The Gateway splits the rrp{d number space into two parts. One main part that will remain the same for the same request across all its retry attempts and a smallerportion to indicate the number of retrv attempts. Then, rrpidRetryCount _ rrpid MOD MAXRETRIES (0 for initial request, >0 for a retry) NOTE: The initial rrpids generated by vPOS software are equal to 0 MOD
MAXRETRIES and in subsequent retries the lower order digits are incremented by one for each retry attempt. This requires extra stored in the vPOS application. The vPOS software must persistentlv store the rrpid used ~which contains the retry count of the transaction) so that repeated attempts will follow the correct semantics.

In general the Gateway will support the following logic ~assuming the second request is fresh and not a replay attack]:
If two requests, request 1 :<xidl, midm,tidt,r~pidl reqdate~,reqdatal>
request 2: <xidl, midm,tidt,rrpid2 reqdate2,reqdatal>

CA 022~8648 1998-12-16 W O 97/49050 PCT~US97/10402 .
are received at t, and t2 (where t2>t,) and, (rrpidl - (r7pidl MOD MAXRETRIES)) e (rrp~d2 ~ pid2 MOD MAXRETRIES)) then the Gateway will interpret the second request as a retrv request.
But if, (rrptdl - (rrp{d~ MOD 100)) ~ (r7pid2 - (rrp~d2 MOD MAXRETRIES)) then the Gateway will interpret the second request as a new request.

In addition to being able to distinguish between a retry and a new request, the proposed r7pid scheme can be used to determine how many vPOS requests got lost in the Internet. This is a useful value-added service for system management.
Ro~ stn~ss and Error Handling Issues There are several robustness issues that need to addressed. The basic flow is that vPOS sends a request to the Gateway, the Gateway logs the SET key fields from the incoming attempt in the tlAtAhAse The Gateway then generates a host request which it logs completely in the ~lA~Ah~se The host hA~ s the request and generates a response that is directed towards the Gateway which, when received is logged completely in the Gateway flAtAhAse. Finally the Gateway generates an SETresponse to vPOS, the contents of which is not logged in the ~l~A~tA~se If the Gateway has not received the request or receives the request but is not able to log the request in the ~lAtAh~e it is easily h~nf~l~A by a vPOS retry attempt. This lecov~ly action needs no further discussion. In general, if the vPOS does not receive a reply to a request it has sent to the Gateway it must retry persistently until a response is received. All retry attempts from vPOS for the same request must have the same base poffion of the rrpid but a different value in the retrl/ counter.

The Gateway must handle replay attacks as outlined previously in this document.
If the Gateway receives a request that it has already .~c~ d from vPOS there could be several possible dispositions:
a) the request had already been h~ntlle-l completely with the host and a host response is in the Gateway database. In this case the Gateway can simply translate the host response to a SET response and send it to vPOS.
b) the request had been sent to the host before (as determined by a ~lAtAhASe field) but a response from the host is not on file. In this case the Gateway must retry the host request.

CA 022~8648 1998-12-16 WO 97/49050 PCTrUS97/10402 If the vPOS times-out for any reason, it must retry later using an rrp~d that inflic~tes a retry attempt. If the Gateway r~ce,./es a late-response (after vPOS has given up) it simply logs it in the ~i~t~h~ce for that retry attempt (if no retry attempt for the tr~nc~rti~n is still outst~n-ling at the host). There is a glare situation where the original response could arrive so late that it could be confused with the response from a currently outstAn-~ing retry attempt with the host. This situation is logged and the first response not sent back to vPOS.

A response from the host in~lic~tinf~ a successful transaction may get lost on the way 10 back to the Gateway or not be able to be logged in persistent storage in the Gateway.
In either case vPOS is in a situation where the retry request when received by the host may result in a response from the host inrlit~ting that the request is a dl~plic~te. The vPOS software must be able to handle this. In the LEGACY case when a duplicate post is received by the host the second one automAtic~lly causes 15 the first one to void and the second transaction fails too. In this case vPOS should retry the transaction under a new rrp{d. If the transaction goes through end-to-end all effects of the previous tr~nc~qctinns will not matter.

TokenOpaque Contc,.L~
20 The Gateway requires information captured at the time of an AuthReq that must be repeated to the host at the time of the associated Cap}~eq. The mech~ni.cm of choice (built into SET) for this is enabled utilizing this data in the TokenOpaque token of the CapToken which is sent in an AuthRes. This CapToken is stored at the Merchant system and It:plcsellted to the Gateway at the time of the Cap~eq. The format of an 25 TokenOpaclue is an OctetStnng.

The following data structure is utilized to deliver the AVS data. \

StreetAddressl=800 El Camino Real\n StreetAddress2=Suite 400 \n City=Menlo Park\n StateProvince-CA \n Country=USA\n PostOfficeBox= \n ZipPostalCode=94025 \n \n . .

CA 022~8648 1998-12-16 W 097/49050 PCTrUS97/10402 An empty line in~lic~tes the end of AVSData The detailed information that is available for the Address Verific~tion Service depends on the Payment Window that captures the data from the consumer.

5 AVS Data (LEGACY-onlv) For ULEGACY~ version ~l.Or only the ZipPostalCode name value pair is required. The Gateway will only use the first 5 characters of this value.

Tr~nos~tio-. Replay A'' ~L-Q
10 The processing of Internet-based payment transactions is a coor linAt~-l interaction between the Internet Transaction Gateway and the vPOS servers that is based on the following principles. A vPOS terminal, as the initiator of the payment transaction, is responsible for the round-trip logical closure of the transaction. vPOS will retry a transaction that has been initiated with the Gateway but where the response for the 15 request was never received from the Gateway. A vPOS terminal selects -- out of a pre-assigned range -- aTerminaZ-Id that is to be used by the Gateway in a request to the host processor. This data element must be transported from the vPOS to the Gateway along with the payment-related information. The '1~. ,..Z,.al-Ids must be unique among the concurrent vPOS instances on a vPOS server system. However, 20 the T~. ,..l. (77-Ids have no history. For ~Y~mple, a subsequent Force Post transaction need not use the same Terrn{nat-Id as the original Authorization tr~n~tinn The vPOS will be responsible for making sure that only one request is outstanding for the same 'Il- chant-id, Terrnfnal-fd> data elements from a vPOS
server system. The Gateway does not know that a response was successfully 25 received by vPOS. This means that the vPOS must be responsible for initi~tinE~ any retry attempts. The Gateway never initiates a retry attempt with the host processor without an explicit retry request from vPOS. The Gateway when asked to retry a request with the host, ~clrolllls a r~l~ti~n~l database look-up and delivers a response that has already been received from the host processor but was previously 30 missed by vPOS. This behavior of the Gateway is also known as the "transaction response cache." The Gateway will need to know that a vPOS request is a retry ofsomething already sent. The prior request may or may not have been received. A
solution for determining the difference belwc~en a retry attempt and a new request was described earlier in this document. vPOS must understand the "canonical" error 35 codes that it v~ill receive via the Gateway and be able to initiate the proper recovery action and/or generate the app.u~liate user-interface dialog.

CA 022~8648 1998-12-16 Ce,L"~- ~1 e P~e~ ' ¢
Merchants require a merh~ni~m for verifying l~gitim~tr cardholders is of valid, branded b~nkr~rd account numbers. A preferred embodiment utilizes technology to link a cardholder to a specific b~nkr~rd account number and reduce the incirlence of 5 fraud and thereby the overall cost of paylllellt p-ocess;.~g. ~occs~i"g includes a merh~ni~m that allows cardholder confirmation that a merchant has a rrl~tit7n.~hir with a fin~nci~l institution allowing it to accept bAnkr~rd payments. Cardholders must also be provided with a way to identify merchants they can securely conductelectronic commerce. Merchant authentication is ensured by the use of digital 10 signatures and merchant certificate~ In a preferred embodi~nent, a holder of a payment instrument (cardholder) surfs the web (Internet) for required items. This is typically accomplished by using a bluw~l to view on-line catalog information on the merchant's World Wide Web page. However, order numbers can be selected from paper catalogs or a CD-ROM and entered manually into the system. This method 15 allows a cardholder to select the items to be purchased either autnm~tic~l1y or manually. Then, the cardholder is presented with an order form containing the list of items, their prices, and totals. The totals could include shipping, h~ntllin~ and taxes for r~mplr. The order form is delivered cle~LIu.fically from the merchant's server or created on the cardholder's computer by electronic shopping software. An 20 alternative embodiment supports a negotiation for goods by presenting frequent shopper identification and information about a competitor's prices. Once the price of goods sold and the means of payment has been selected, the merchant submits acompleted order and the means for payment. The order and payment instructions are digitally signed by cardholders who possess certific~te~. The merchant then 25 requests payment authorization from the cardholder's fin~nci~l institution. Then, the merchant sends confirmation of the order, and eventually ships the goods or performs the requested services from the order. The merchant also requests payment from the cardholder's fin~nri~l institution.

30 Figure lC is a block diagram of a payment processing system in accordance with a preferred embodiment. The Certificate Issuance at the Bank Web Site 162 resides at the bank web site 182. It is utilized for issuing SET complaint / X.500 certi~lcates to consumers. The impl~ment~tinn of this system may vary from one bank to another.
However, the system gathers consumer's personal information, and after processing 35 the information, the system issues a certificate along with a payment instrument to the consumer. The Single Account Wallet 160 at the bank web site 182 lC,~JlCSClltS
the MIME message that is created by the Certificate Issuance system. This MIME

, . .. . , . . , . . , ... . ~ ~, ........... .

CA 022~8648 1998-12-16 W O 97/49050 PCTrUS97/10402 message contains a VeriFone wallet. The VeriFone wallet contains a single payment instrument and the certificate ~ssot~i~te(l with it. For security reasons, the private key is not included in the wallet. The has to specify a private key before using the instrument for payment. When the consumer is issued the certificate, this MIME
5 message is sent to the bluw;,~,~. The blu..~e~ launches the Certificate Instz~ ti~n application 174, 144 which is defined as a helper applicAtinn in the b-uw~e.. The Certificate Inst~llatinn application 174, 144 reads the MIME message and install the wallet into the wallet rlRt~h~e 158.

Various helper applications 198, 172, 174, 176 are provided to make the consumer's shopping experience easy and efficient including the following helperapplications. The Paywindow helper application 188 is utilized by the consumer to authorize the payment to the merchant, to Rrimini~ter their wallets, to review their previously completed payment transactions and to perform housekeeping activitieson the wallets. This application is defined as a 'helper' applirati--n on the consumer's desktop. The bluw~el~ launches this application when the merchant system sends aMIME mess~ge requesting payment. The PayWindow Setup Helper application 172 is used by the consumer to install helper applications and other modules from the web site onto the consumer desktop. When a consumer aLl~.npts to install an application for a first time, the consumer does not have a helper applir~tinn on the desktop. Thus, the first time inst~ tion of an appli~fltinn requires a consumer to perform two steps. First the user must download the system p~-~k~ge to their desktop and then the user must run setup to decompress and install the system.
Thereafter, whenever the consumer gets a new release of system software, the l)~c)w~r launches this helper application which in turn installs the a~plop~iate other system modules.

The Certificate Installation Helper Applie~ti-m 174 is utilized to install a wallet that is issued by a bank. When the bank's certificate issuance web system sends the MIME message containing the VeriFone wallet, the b1UW:~.,1 launches this application. This application queries a consumer to determine if the payment instrument contained in the wallet is to be copied to an existing wallet or to be kept in the new wallet. This application then installs the payment instrument and thecertificate into the wallet rl~t~h~e 158. The Certificate Issuance CGI scripts 162 and the Single Account Wallet 160 at the Bank Web Site 182 is l~rocessed as described in the native system. The Certificate Inst~ ti- n Applet of the Bank Web CA 022~8648 l998-l2-l6 Site 182 is utilized by the Certificate Tssn~n-~e CGI scripts 162 system to deliver a consumer's certificate to the consumer's desktop.

Figure 26 is an architecture block diagram in accordance with a preferred 5 embo-lim~nt of the subject invention. Processing commences at function block 2600 where the Graphical User Interface (GUI~ part of the appli-~tion is initi~ rl The GUI application 2600 provides the consumer with support for ordering and m~king payments during the shopping process. There are also GUI colllponcllts provided for wallet creation; importing, certificate and payment method creation and 10 mainten~nce; and for tr~ns~ction register review and reporting. The screen designs, and their associated logic, for the helper applications and applets are individually discussed in detail below. The Certificate l~n~gtor 2604 m~n~s the automatic down]o~-iing of a consumer's certificate from a bank, v~]il1~ti-~n of a consumer's and a merchant's certificates and automatic requisition of certificate renewal. The 15 Payment M~n~r 2606 coordinates and completes the payment request that is lt:c~ d from the merchant system. The payment request is leceivcd via a MIME
message in the native code im~]çmentation or via an applet in the Java implernentation The payment request leceivcd contains the final GSO, Ship-To name, merchant certificate, merchant URL, coupons and the payment amount. The 20 manager 2606 then commnni-~tes with the payment related GUI col,lpollent to interact with the consumer to authorize and complete the payment tr~ns~ction. The manager is also responsible for determining the payment protocol based on the consumer's payment instrument and the merchant's preferred payment protocol.
The manager 2606 includes a well defined Application Progr~mming Interface (API~25 which enables OEMs to interface with the payment manager 2606 to make payments to specific HTTP sites. The detailed logic associated with the payment manager 2606 is presented in Figure 27. The payment manager 2606 enforces standard operations in the payment process. For example the receipt and the transaction record can autf~m~tic~]ly be transferred to the Wallet ffle once the30 payment is completed. The payment manager architecture in accordance with a plercllcd embodiment is presented in Figure 27. A user interfaces with the payment manager 2730 via a user interface 2700 that responds to and sends a variety of transactions 2710, 2708, 2706, 2704 and 2702. The transactions include obtaining the next record, payment record, receipt, acceptance of the payment 35 instrument and GSO components. In turn, the payment m~n~eer 2730 sends transactions 2714 and l~CC;~,t~ 2720 to the wallet manager 2722 and lCC~ ,S
payment instruments, certificates and private keys from the wallet manager 2722.

CA 022~8648 1998-12-16 The payment manager 2730 also sends and I ec~;ves transactions to the protocol m:~ns~r 2770 including a merchant's payment message 2760, a consumer certificate and PK handle 2750, a merchant URL 2742, a payment 2740, a signed 5 receipt 2734 and a GSO, Sele~ed Payment Protocol and Selected Payment Instrument 2732. The payment manager 2730 also accepts input from the payment applet or MIME message from the merchant as shown at function block 2780. One aspect of the payment ~luces~ing is a Consumer Payments Class Library (CPCL) 2770 which encapsulates the payment protocols into a single API. By encapsulating 10 the payment protocols, applications are insulated from protocol variations. A SET
Protocol provides an implementation of the client-side co.ll~ullent of the Secure Electronic Transaction (SET) Protocol. A complete implementation of the client-side component of the CyberCash micro-payment protocol is also provided.

15 The Wallet Manager 2722 provides a standard interface to the wallet. It defines the wallet fl~t~ha~e structures and the payment instrument data structures, controlsthe access to the wallet and provides concurrency r he~king if more than one application attempts to open the same wallet. The interface to the wallet manager 2722 is published to allow OEMs to interface with the wallet manager and access 20 the wallet ~l~t~b~se.
The wallet manager consists of the following sub-components:
Wallet Access. This component provides an interface to read and write wallet information.
l r e~ inn Manager. This col~ onent provides an interface to read and write 25 transaction corresponding to a wallet into the wallet database.
Y~a~ ' h~ol~ cnt Manager. This component m~n~r provides a common interface to the specific payment instrument access components.
Credit Card Ac cess, Debit Card A~ ce~, Check A~ cess. These components deal with a specific payment instrument.
A Data Manager provides storage and retrieval of generic data items and databaserecords. It is assumed that data fields, index fields or entire data records can be marked as encrypted and the encryption process is largely autom~te~l The data manager has no specific knowledge of ~l~t~h~e records appropriate to different 35 payment methods. This layer is separated out so as to reduce changes requiredwhen new payment methods are introduced. However RSA key pairs and certificates might be considered as "simple" data types. This component also provides an CA 022~8648 1998-12-16 abstraction which supports wallet files on computer disk or contained in smart cards.

The Open Data Base Connectivity ~ODBC)/Java Data Base Connectivity (JDBC) 5 co-l-pc--ent provides Data Base Colll-e~liviLy where formal ~l~t~h~Qe co-llpol-ents are c~lui.~d. An lomhotliment of the Smart Card Wallet allows wallet data to be stored and/or secured by a cryptographic token.

A preferred embo-lim~nt in~ des a single file or di-G-;lu-y of files comprising a 10 "wallet" which contains personal information and information about multiple payment methods with the preferred impl~mentation. These payment methods ( Visa cards, debit cards, smart cards, micro-payments etc. ) also contain information such as account numbers, certifi~t~s~ key pairs, expiration dates etc. The wallet is envisaged to also contain all the receipts and transaction records pertaining to every 15 payment made using the wallet. A Cryptographic API component provides a standard interface for RSA and related cryptographic software or hardware. This support includes encryption, sien~tnre~ and key generation. Choice of key ~o~rrh~nee algorithm, symmetric encryption algorithm, and ~ign~tllre algorithm should all be configurable. A base class stipulates generic behavior, derived classes handle 20 various semantic options (e.g. software based cryptography versus hardware based ulylJLo~l~phy.) The Cryptographic Software portion provides RSA and DES support. This may be provided utilizing the SUN, RSA or Microsoft system co...po-.ents depending on the 25 implementation selected for a particular customer. Cly~to~ ,uhic Hardware creates a lower level API which can underpin the Clyl~to~ lduhy API and be utilized to replace Cryptography Software with an off the shelf u~y,uLO~I~phy engine. The me~s~e~
sequence charts describe the flow of messages/data between the consumer, the bl~w:iel and/or the various major components of the Semeru system. The major 30 colll~-onents of the system are the Merchant system which includes the vPOS, the PayWindow, and the Payment Gateway. The merchant system allows a consumer to shop, accept the payment tr~n~ tion~ sent by the PayWindow application, and sendpayment transactions to the acquiring bank. The Consumer Payments Class Library (CPCL) module is a layer within the application which sends the payment 35 tr~n~rti~ns~ securely, from the consumer to the merchant.

, ., ... .. . . , -- ~ ... . .

CA 022~8648 1998-12-16 Figure 28 is a Consl1mPr Payment Message Sequence Diagram in accordance with a preferred embodiment of the invention. The diagram presents the flow of meSc~s belweell the consumer, the blUW~t:l, the merchant system, the PayWindow appli-~A~inn, and CPCL. This message flow describes the payment ~rucess from the5 time an order is co.1l~l~L~:d and the consumer elects to pay, to the time the ~ ylllent is a},~lu.,~,d and the receipt is returned to the consumer. The difference between the Native implementation and Java impl~ tion of the PayWindow applic~ti-7n is in the delivery of the order information to the PayWindow. Once the order information is received by the PayWindow, the flow of mes~E~s/data is the same for both 10 ;,.,~ ",rntations. In the case of the Native impl~om~ntRtion, the order information is delivered via a MIME message. This MIME message is sent to the PayWindow by the blUW;:iel via a document file. In the Java implementation, the order information is delivered to the PayWindow by an applet. The merchant system sends an applet with the order information to the blUW'iel which in turn delivers the order to the 15 PayWindow. Once the order is received, the PayWindow interacts with the consumer and the Protocol modules for the completion of the payment pl'OCe,SS.
Enters Order and Clicks Calculate Order 2820 This message represent the consumer order entry and the f~ king of the 'Calculate Order' button. The consumer's shopping experience is all con~len~ed into this one 20 message flow for the purpose of highlighting the payment process. The actual implementation of the shopping process varies, however, the purpose does not, which is the creation of the order.
Order 2830 This message le~.esel1ts the order information which is sent by the IJ1UWX~. to the 25 merchant via an HTML form.
Pavment Applet with GSO, PPPs, AIs, merchant certificate and URL 2840 On receipt of the order, the merchant system calculates the payment amount. Thismessage rel~lcscl-ts the HTML page which is sent by the merchant system detailing the payment amount along with the Java payment applet which contains the GSO, 30 PPPs, AIs, merchant certificate and URL.
Run Pavment Applet 2845 The Java en~hlecl l~luw~el runs the Payment applet. The applet displays a buttoncalled "Pay~ for the consumer to click. This is embedded in the HTML page delivered by the merchant.
35 Clicks Pav 2850 This message represents the clicking of the Pay button on the l)~UW~ I by the consumer after confirming the payment amount.

CA 022~8648 1998-12-16 WO 97/49050 PCT/US97tlO402 GSO, PPPs, AIs. merchant certificate and URL 2860 This message le~lc~,ellts the GSO, PPPs, AIs, merchant certificate and the merchant URL carried by the Java applet. The Java applet now delivers these to the PayWindow appli~tinn 5 Merchant cel lirlcate 2862 This message le~ ts the merchant's certificate which is sent to the CPCL module for checking the validity of the merchant.
Merchant's validity 2864 The CPCL modules examines the merchant's ce~ cate and send this message to the 10 PayWindow in~lic~ting whether or not the merchant is a valid merchant.
Wallet, PaYment Instruments 2866 This message ~ep,~:sellts the wallets and payment instruments that is displayed to the consumer. Not all payment instruments from a wallet is shown to the consumer.
Only the ones accepted by the merchant is shown.
15 Pavment Instrument 2868 This mess~g~ Jl~ellts the payment instrument selected by the consumer. This message is created in the current design when the user double clicks on the payment image in the ~Select Payment Methodn Window.

20 This inflic~tes that the GSO is displayed to the consumer in the aMake Payment Authorization~ screen.
Authorization of Payment 2872 This message represents the authorization of the payment by the consumer. The consumer authorizes the payment by ~licking the 'Accept' button on the ~Payment 25 Authorization" screen.
Decide PaYment Protocol 2874 Once the consumer authorizes the payment, the p~ylllcllt protocol is decided by PayWindow based on the merchant's Payment Protocol Preferences and the consumer selected payment instrument.
30 Pavment Authorization 2875 These messages represent the merchant's URL, the GSO, payment protocol (PP) to use, account number, certificate and the private key handle (PK) associated with the payment instrument which is sent to the protocol module.
GSO with Pavment Authorization 2876 35 This message leplcscnts the payment instructions which is sent by the protocol module to the Merchant system. The GSO, PI, con~ lm.or certificate and PK is packaged based on the payment protocol.

~ .

CA 022~8648 1998-12-16 W O 97/49050 PCTrUS97/10402 Si~ned ReceiPt 2878 This message lel~lesel.ts the digitally signed transaction receipt received by the protocol module from the merchant.
Save ReceiPt with hash value 2880 5 The digitally signed transaction receipt is saved by the PayWindow for future 1 ef;~. ~ nce.
Pavment Successful 2882 This indicates that the transaction receipt and the payment successful' have been displayed to the consumer.
Cc-L;~te F~ce B~
A payment instrument must be certified by a "certificate issuing authority" before it can be used on a computer network. In the case of credit card payments, the issuer may be one of the card issuing banks, but it might also be a merchant (eg SEARS), a transaction aquiring bank or an association such as VISA or Mastercard. Payment 15 instrument information is stored in the consumer's wallet. The certificate which authorizes the payment instrument will be stored along with that data in a secured t~h~e The process of acquiring a certificate is described below. A certificate can be delivered to a consumer in a preconfigured wallet. The consumer receives a wallet which contains the certificate together with the necessary details associated 20 with a payment instrument including a payment instrument bitmap which is authorized by a certificate issuing authority or the agencies l~prcs~.lted by the issuing authority.

Obtaining a cc,Li~cate 25 A consumer will deliver or cause to be delivered information to a certificate issuing authority. Figure 29 is an illustration of a certificate issuance form in accordance with a ~lcf~ d embodiment. A user may fill out the form on-line, on paper and mail it in, or get his bank or credit card company to deliver it. The consumer delivered data will usually contain a public key belonging to a security key pair 30 generated by consumer software. This information will normally be mailed to the consumer's address and actuated by a telephone call from the consumer. The certificate authority takes this information and uses it to validate that he is indeed entitled to use the payment method. This processin~ normally takes a few days toaccomplish. Information will normally be ~x~h~nged with the org~ni~tion issuing 35 the payment method in the physical space if there is one, and with credit agencies.
The certificate information is loaded into the consumer's software to enable payment processing to proceed online. In some cases the consumer will be able to select CA 022~8648 1998-12-16 W O 97/49050 PCT~US97/10402 details about a payment in~tllmçnt holder (wallet) he desires to own. This may be the icon Ic~le~.lting a holder, the access password or other information. After creating the certificate, the issuing authority can use information received in the certificate application to create a custom payment instrument holder ready to use.
This payment instrument holder will contain the following inform~ti- n Payment instrument information including card number 2900 and expiration date 2902.
Personal information including name 2904, address 2906, social security number 2908 and date of birth 2910. The associated certificate ( eg X509 standard ), anassociated public key or in some cases public/private key pair ( eg RSAl, and anl O approved bitmap representing the payment instrument are provided to the requesting consumer. Figure 30 illustrates a certificate issuance response in accordance with a preferred embo~lim~nt. An approved bitmap for a VISA card is shown at 3000. Also a default payment holder 3010 and a default payment holder name are provided with the certificate i~sll~nce. After the consumer aquires thepayment instrument holder 3010, the payment instrument holder is immediately visible to him in his collection of payment instrument holders. Figure 31 illustrates a collection of payment instrument holders in accordance with a preferred embodiment. The predefined payment instrument holder 3100 is the same JOHN's WALLET that was predefined based on def~ult~ by the certificate issuance form.
Figure 32 illustrates the default payment instrument bitmap 3200 associated withthe pre~l~fined payment instrument holder 3210 resulting from the consumer filling in and obtaining approval for a VISA card. Figure 33 illustrates a selected payment instrument with a fill in the blanks for the cardholder in accordance with a preferred embodiment. Next time the payment instrument holder is opened in a payment context the certificate issuing authorty's applov~d instrument bitmap can be used to select the payment instrument and utilize it to make purchases. Figure 34 illustrates a coffee purchase utilizing the newly defined VISA card in accordance with a ~ler~ d embodiment of the invention.

Figure 35 is a flowchart of con~litio~l authorization of payment in accordance with a preferred embodiment. Processing commenres at 3500 where the program initi~ es the connectinn bc~wt:een the cardholder and the merchant for the purposes of shopping. After the cardholder completes shopping, a new SSL connection is est~hli~hed which provides authenticating information to the merchant. At this point the merchant is able to execute payment fi~ncti~n~lity (based on SSL or SET) conditionally, based upon the quality and character of the digital ~ign~tllre and the certificate used to validate said .~ign~tllre Then, at function block 3510, the .. ~ .. ~ .. .... . . ... .. ...... ...

CA 022~8648 1998-12-16 WO 97/49050 PCT~US97/10402 cardholder selects the payment instrument for the particular transaction. Payment instruments could include VISA, MASTERCARD, AMERICAN EXPRESS, CHECK, SMARTCARD or DEBIT CARDS. The payment method is then submitted to the merchant at function block 3520. The merchant then initi~ s the SET connection 5 to the acquiring bank at function block 3530 if the connection is not already est~bli~he~l Then, at function block 3540, the certificate is submitted to the merchant from the acquiring bank. The certificate includes a public key portion and a private key used as an irrebutable digital signature to authenticate the parties to the transaction. The certiflcate also includes information on the level of credit risk 10 which allows a merchant to conditionally decide on the authorization or rejection of credit under a particular payment instrument based on their risk level and the merchant's personal comfort level with the ability of the cardholder to pay. This processing has not previously been possible because the information returned from the authorizing bank did not include a level of credit risk a cardholder posed, it only l5 contained credit rejected or approved. A detailed description of the gateway internals is presented below in accordance with a ~,Gr~ d embodiment.

Gw ClearSetRequestT~n.ll..~
Figure 51 depicts a flow diagram for the GatewayClearSetRequestHandler routine.
Execution begins in Step 5105. In Step 5110 an SEI' analysis routine is called to analyze the SET request, as will be more fully disclosed below. Step 5110 sets astatus flag indicating the next stage to be ~.~,rol",ed by the Gateway. In Step 5120 the Gateway checks to see whether the status is set to intlic~te that a responseshould be provided to the user. If so, execution proceeds to Step 5 l90, which ends the request h~n~1linE~ routine and returns control to a calling routine, which then provides a response to the user. Otherwise execution proceeds to Step 5130. In Step 5130, the Gateway checks to see if the status is set to inllic~t~ that forward tr~n.~l~tion is required. Forward tr~n~ tion is necessal y to translate an outgoing message into a format that can be understood by the host computer. If forward tr~ns1~ti- n is indicated, execution proceeds to Step 5135. In Step 5135, the outgoing message is forwarded tr~qnsl~t~d, as more fully disclosed below with respect to Figure 53. If no forward tr~n~ti-n is in~ terl, for example, if an already-tr~n~lAte-l transaction is being retried, execution proceeds to Step 5140. In Step 5140, the Gateway checks to see if the next step is comml]nic~tinn to the host. If so, the Gateway proceeds to Step 5145, and initiates host commllnic.qtion as will be more fully discussed below with respect to Figure 54. If not, execution proceeds to Step S150. In Step 5150, the Gateway checks to see whether reverse tr~n~l~tion is CA 022~8648 1998-12-16 intlics~t~d. Reverse trz~n~lzltioî~ trS~n~l~tes a response from a host into a format useable by the calling routine. If reverse tr~ncl~tion is in~ At~-l, execution proceeds to Step 5155, and the reverse tr~ncl~tion is performed, as will be more fully discussed below with respect to Figure 55. In any case, after either for~,vard S tr~n~l~tion in Step 5135, host comml~nic~tion in Step 5145, or reverse tr~ncl~tion in Step 5155, control returns to Step 5120 for further procescinf~ As will be more fully rli~closed below, the forward tr~n.cl~tirn, host communicRtion, and reverse translation routines manipulate status in~ic~tors to prevent the occurrence of an infinite loop.
AnalvzeSetRequest Figures 52A and 52B describe the AnalyzeSetRequest routine. This routine is by Step 5110 as illustrated in Figure 51. Execution begins in Step 5200. In Step 5205 the various fields in the SET record are obtained, as will be more fully disclosed below with respect to Figures 56A and 56B. In Step 5210 the Gateway checks the retry count. A retry count is zero inrlil~tes that the request being analyzed is a new request, and control proceeds to Step 5212, in~ ting a new request. If the retry account is non-zero, this means that the request is a retry of a prior request, and control proceeds to Step 5214 where a retry is indicated.
Following either step 5212 or 5214, execution proceeds to Step 5215. In Step 5215 the Gateway checks to see whether the request lel.lesents a "stale request," as will be more fully described below with respect to Figure 57. In Step 5220, the Gateway tests the result of the stale check from Step 5215. If the request is stale it is marked as stale in Step 5222. Otherwise the record is marked as not stale in Step 5224. Following either Step 5222 or Step 5224, control proceeds to Step 5230. InStep 5230 a message leprts~ g the SET request is inserted into the ri~t~h~.ce for tracking purposes, and control proceeds to Step 5240.

In Step 5240 the Gateway checks to see if the request had been marked stale in Step 5222. If so, it proceeds to Step 5242, exiting with an error con~litinn. In Step 5245, the Gateway attempts to retrieve from the ~i~t~h~.ce a message corresponding to the current SET request, as will be fully ~lieclosed below with respect to ~igure 59.
Step 5260 checks to see whether the message was successfully retrieved from the database. If the message was not found in the d~tAh~.~e, this indicates that the SET
request represents a new message, and control proceeds to Step 5270. In Step 5270 a new message ~ s~-.ting the SET request is added to the ~l~t;sbplce~ as is CA 022~8648 1998-12-16 W O 97/49050 PCT~US97/10402 more fully tli.~close-l below with respect to Figure 60. Because this is a new request, it must be processed from the beginning, including forward tr~n~1~tion- Therefore, after the new me.S.s~ is added in Step 5270, control ploceeds to Step 5275. In step 5275, where a status flag is set inrlir~ting that the next step to be performed 5 for this m~Ss~ge is for tr~n~l~ti--n. If the message was found in Step 5260, this inrlif~zlt~-s that the request leprese.lts a request that is already in ~ro~ ,ss.
Therefore, control pl~,ceeds to Step 5280 to update the ~1~t~b~e with current information ~ s~ . .ting the request status. The update process is described in further detail with respect to Figure 61, below. Following Step 5280, control proceeds to Step 5282. In Step 5282 the Gateway checks to see the disposition inwhich the SET request was left as a result of partial processing. This is done, for mple, by interrogating fields in the ~1~t~hR~e record that in~lic~te the steps that have already been performed for this request. In Step 5283, based upon this status information, the Gateway indicates the next stage of processing to be performed:either forward tr~n~lPtion~ reverse translation, or communication with the host.After this status has been set, whether for a new request in Step 5275, or for an already-existing request in Step 5283, control proceeds to Step 5290, which exits the AnalyzeSetRequest routine, returning control to Step 5110 in Figure 51.

~ F~ d Figure 53 depicts the execution of the Tr~n~l~teForward routine, which is called by Step 5135 in Figure 51. Execution begins at Step 5310. In Step 5320, the Gatewayforward-translates the request to prepare it for tr~n~nni~sion to the host. Forward tr~n~l~ti~n consists of p~ck~ging the fields in the request into a format that is understandable by the legacy system at the financial institution. The exact format of the translated request will vary from institution to institution. However, ingeneral, the format will consist of a fixed length record with predetermined fields, using a standard character set such as ASCII or EBCDIC. In Step 5330, the Gateway checks to see whether the tr~n~1~ti~-n was successfully ~elro~ ed. If not control proceeds to Step 5340, which returns an error cf~n(lition If the tr~nsl~ti~ n was successful, control proceeds to Step 5350. In Step 5350, the Gateway sets a status flag to inrlic~te that the next stage to be pelro-llled for this SET request is to proceed to host commllnic~ti~n This will be used in the next iteration of the Gw_ClearSetRequestHandler routine as depicted in Figure 51. After the status is set in Step 5350, the translate forward routine returns control in Step 5360.
The TranslateForward routine as depicted in Figure 51 may be implemented using the following C++ code:

CA 022~8648 1998-12-16 -l03-gwAction CGW_Engine::TrAn~l~trForward(CPCLCCRequest *pVehicle) {

gwRC rc;
S gwDBRC dbrc;

rc = HM_Tr~n~lsteForward(m_hostS~,e~ c~/le.s~s~gr, pVehicle);

if (rc == GW_SUCCESS) {
l 0 return (GW_PROCEED_WITH_HOST_COMMS);
}

m_hostRequestDisposition = GW_HREQDI_FWD_XLAT_FAILED;
BuildSetErrorResponse(pVehicle, ISO_RESP_FORMAT_ERR~;
dbrc = Gwdb_UpdateHostM.~gRequestDisp();
if (dbrc ~= GWDB_SUCCESS) {
GW_LogError( LOG_ER~, "Gwdb_UpdateHostMsgRequestDisp(): %d", dbrc);
}

return (GW_PROCEED_TO_RESPOND);
}

noI~~stCc.. :r~
Figure 54 depicts the step of host commlmic~ti~n, as shown in Step 5145 in Figure 51. Execution begins in Step 5400. In Step 5405 the Gateway obtains from the request object the string lc~lesellting the request text. In Step 5410 it obtains the sequence number for the request. In Step 5415 the Gateway determines the current30 time, in order to record the time at which the request is made. In Step 5420 the Gateway sends the request to the host and waits for a response from the host.
When a response is received, execution continues in Step 5425. In Step 5425, theGateway again checks the current time, thereby determining the time at which a response was received. In Step 5430, the Gateway checks to see whether the 35 communication was successfully performed. If a comm~lnir~tir~n was not successful, the Gateway records that an error occurred in Step 5432. If the commllnic~tion was successful, the Gateway, in Step 5435, in~lirates that the request was successfully CA 022~8648 1998-12-16 W 097/490~0 PCT~US97/10402 sent and responded to. In Step 5437, the Gateway sets the response string based upon the response received in Step 5420. In Step 5439 the Gateway sets a status to intli~Ate that reverse translation of the received response is required. Regardless of whether the communic~tion was successful or unsuccessful, execution continuesS to Step 5450. In Step 5450, the ~1~t~ha~e is updated with status information from the host commllnic~tion. In Step 5490, control is returned to the calling routine.

Tr~ c~ n~verse lO Figure 55 depicts the operation of the TrRn~l~t~Reverse routine, as executed in Step 5155 in Figure 51. Execution begins at Step 5500. In Step 5510 the Gateway reverse-tr~n~l~tes the response l~ceiv~d from the legacy system host. Reverse tr~n~l~tinn consists of extracting data from the data records received from the legacy system, and placing them in objects so that they are useable by the Gateway. In 15 Step 5520, the Gateway checks to verify that tr~n~l~tinn was successful. If translation was successful control proceeds to Step 5530, where a status flag is set intlic~ting a successful tr~nsl~inn~ If translation was not successful, control proceeds to Step 5540, in which the Status Flag is set to indicate an unsuccessful tr~n.~l~tion Regardless of whether trAn~l~tion was successful or unsuccessful, 20 execution proceeds to Step 5550. In Step 5550, a status nag is set to intlic~te that the next stage for the request is to provide a response from the Gateway. This step is always executed, because, regardless of whether the tr~n~l~tinn or any other aspect of the transaction was successful, a response in~lic~ting either success or failure must be returned by the Gateway. Control then proceeds to Step 5590, in 25 which the TranslateReverse routine returns control to the calling routine in Figure 51. It will be seen that the TranslateForward routine in Figure 53, the DoHostCommunication routine depicted in Figure 54, and the TranslateReverse routine depicted in Figure 55, each alter the status of the request. As a result as the loop depicted in Figure 51 executes a particular request will proceed through all 30 three stages and finally to exit in Step 5190.

Get8etK ~,F;clds Figures 56A and 56B describe the GetSetKeyFields routine. This routine is called by Step 5205 as illustrated in Figure 52A. Execution begins in Step 6600. In Step 35 5610, the Gateway interrogates the request object to determine the request type. In Step 5620, the Gateway determines whether the request type is for authorization only. If the request type is not for authorization only, execution proceeds to Step ... .. . . .

CA 022~8648 1998-12-16 W O 97/49050 PCTrUS97/10402 5625. In Step 5625, the Gateway checks to see whether the request type is for a sale. If the request type is neither for authorization only nor for a sale, execution proceeds to Step 5630. In Step 5360, the Gateway in~lic~tes that the request type is not a supported request, and proceeds to Step 5635, where it returns to the caller.
s If the request type is either for authorization only or for a sale, execution ~loceeds with Step 5640. In step 5640, the Gateway initi~ es a container object to represent the request. In Step 5650, the Gateway extracts the ltransaction identifier?] (XID) for the trAnS~rtion In Step 5652, the Gateway extracts the merchant identifier (MID) for the tr~ns~ctir~n In Step 5654, the Gateway extracts the lwhat is the RRPID?] (RRPID) and the terminal identifier (TID) for the request. In Step 5656, the Gateway extracts the retry count associated with the current request. In Step 5660, a me~s~Z~ge data area is initi~li7e-1 with the extracted contents. The message area can then be used for further processing by the calledl 5 routine. In Step 5690, the GetSetKeyFields routine returns control to the caller.

G~lrdb r ~c~ t91~
Figure 57 depicts the Gwdb_IsSetMsgStale routine. This routine is called by Step5215 as illustrated in Figure 52A. Execution begins in Step 5700. In Step 5710, the Gateway checks to see whether this is the first time the Gwdb_IsSetMsgStale has been called for this request. If this is the first time, Steps 5715 through 5730 are performed; otherwise those steps are skipped. In Step 5715, a field representing the message life is initialized to a predetermined duration. The message life is a field that will be used to determine how long the message l~ul~sellting the transaction will remain valid. The use of the message life field prevents a transaction that is erre~-Lively lost due to extensive processing delays from being processed. In Step 5720, the Gateway checks to see if the value of the message life is equal to zero. If the message life is equal to zero, a default value, i.e., 300 seconds or 5 minutes, is assigned to the message life in Step 5725. In Step 5730, an in~ tor for this request is set to inr~ te that first time proces~ing has already been performed for this request. This flag is the same flag interrogated in Step 5710, and is used to prevent successive reinit;~ ti-n of the message life field.

In Step 5740, the Gateway checks to see whether the merchant's time starnp, plus the value of the message life, is less than the time of the request. If so, then the request is cnn.~irl.ored stale, and is marked stale in Step 5750. If not, the request is not stale, and is marked not stale W O 97/49050 PCTrUS97/10402 in Step 5755. Following either of Step 5750 or 5755, the Gwdb_TqSetMqgStale exits in Step 5790.

Gwdb'--- L5ctMs~
S Figure 58 depicts the Gwdb_lnsertSetMsg routine. This routine is called from Step 5230 as illustrated in Figure 52A. Execution begins in 5800. In Step 5810, the routine invokes a ~~t~hA~e insert function by, for ~..,plr, executing an SQL
INSERT comm~n~l In Step 5820, the ~t~h~e return code is obtained in order to be used as a return code from the Gwbd_InsertSetMsg routine. In Step 5830, a 10 ~lAt~h~qe commit function is l t:,rul-l-ed, thereby instructing the ~l~t~b~qe engine to commit the database changes to a permanent lecoldi,.g, i.e., by writing the information to the file, and/or by journ~li7.ing the change made by INSERT function.
In Step 5890, the routine returns control to the calling program.

15 Gwbd f'~ T~ T~
Figure 59 depicts the Gwbd_GetHostMsg routine. This routine is called by Step 5245 as shown in Figure 52B. Execution begins in Step 5900. In Step 5910, the routine invokes a ~l~t~h~qe select function by, for ~x~mp~e, executing an SQL
SELECT comm~n-l. In Step 5920, the tl~t~h~se return code is obtained in order to20 be used as a return code from the Gwbd_lnsertSetMsg routine. In Step 5930, the Gateway checks to see whether the ~lAt~h~qe retrieve operation was successfully performed. If so, execution proceeds to Step 5935.. In Step 5935, the Gateway sets a number of status variables from the values lcll;~./ed from the rl~t~h~qe records.
This includes the time the request was made, the time a response was received, the 25 contents of the request string, the contents of the response string, and a sequence number for this request. In Step 5940, a commit operation is performed. lWhat isthe point of a commit operation following a retrieval, as opposed to an insert or an update?] In Step 5900, control returns to the calling prograrn.

30 Gwdb InsertHostMs~
Figure 60 depicts the Gwdb_InsertHostMsg routine. This routine is called by Step5270 as illustrated in Figure 52B. Execution begins in Step 6000. In Step 6010, the routine invokes a rl~t~h~.qe insert function by, for example, executing an SQL
INSERT c~m mslntl. In Step 6020, the ~l~t~h~qe return code is obtained in order to 35 be used as a return code from the Gwbd_InsertSetMsg routine. in Step 6040, a commit operation is performed. In Step 6090, the routine returns control to the calling prograrn.

CA 022~8648 1998-12-16 Ghvdb U~st~etMs~R~ Tnfo Figure 61 depicts a flow diagram for the Gwdb_UpdateSetMsgResponseInfo routine.
Execution begins at Step 6100. In Step 6110, the routine invokes a dAtAh~se 5 update function by, for lo~rAmple, t.~:cuLing an SQL UPDATE cnmmSInd. In Step 6120, the ~l~tAhAQe return code is obtained in order to be used as a return codefrom the Gwbd_UpdateSetMsgResponselnfo routine. In Step 6190, the routine returns control to the calling plO~l~ll.

10 Figure 62 is the main A~lminiRtration display for the Gateway in accordance with a preferred embodi..lent. A set of menu selections are presented at 6200 which will be described in more detail for each display. Figure 63 is a configuration panel inaccordance with a preferred embodiment. The configuration panel provides access to management information for configuring a gateway management information l5 ~lAt~hARe. The Merchant Identifier (Mid) 6310 is a thirty character, alphanumeric field that uniquely defines a merchant. The Merchant Name 6320 is a fifty character, alphanumeric field, the Edit 6330 and Delete field 6340 are hyperlinks to detailed panels for modifying information in the management information database. Figure 64 is a host commllni~tion display for facilitating communication 20 between the gateway and the acquirer payment host. The IP Address Field 6410 contains the Internet Protocol address for communicating via TCP/IP to the Internet.
The TCP logical port field 6430 uniquely identifies the port for accessing the Internet, and the SAVI~ field 6430 invokes storing of the host comml~nit~Ation information in the database. Figure 65 is a Services display in accordance with a 25 preferred embodiment. This display initiates portions of the Gateway such as the host mnlitpli~r~r 2130 of Figure 21. Figure 66 is a graphical Ic~rcsc-~tation of the gateway transaction ~lAtAhRRe in accordance with a preferred embodiment. Each ofthe fields ~cplesents a portion of the internet ~lAt~b~Re schemA in accordance with a p- efc. . cd embodiment.

.

Claims

-108-What is claimed is:

1. A method for communicating between a gateway, and an existing host payment application, comprising the steps of:
(a) establishing a communication link between the gateway and the host payment application;
(c) receiving a host message in response to a gateway transaction;
(d) parsing one or more transaction response values from the host message;
(e) mapping the one or more transaction response values to a canonical response code; and (f) storing the canonical response code in a transaction log.

2. The method of claim 1, including the steps of;
(g) establishing a communication link between the gateway and the server;
(h) transmitting the canonical response code from the gateway to the server;
(i) indexing a database with the canonical response code to obtain a message; and (j) displaying the message to an end user.

3. The method of claim 1, wherein the messages include payment administration information.

4. The method of claim 1, wherein the messages include payment exception information.

5. The method of claim 1, wherein the messages include payment result information.

6. The method of claim 1, including the step of modifying the database without impacting the system.

7. The method of claim 1, wherein the canonical response code provides support for secure electronic protocol.

8. A method for communicating between a server, a gateway and a host as recited in claim 1, including the steps of:
(a) establishing a first communication link between the server and the gateway;
(b) logging transaction information in a first transaction database at the server;
(c) transmitting a transaction from the server to the gateway over the first communication link;
(d) establishing a second communication link between the gateway and the host;(e) logging transaction information in a second transaction database at the gateway;
transmitting a transaction from the gateway to the host over the second communication link;
(g) receiving a transaction response from the host;
(h) parsing the transaction response to obtain an index to the corresponding logged transaction information in the second transaction database in the gateway;
(i) updating the transaction response in the second transaction database in the gateway with information from the response transaction from the host;
(j) transmitting the response transaction to the server over the first communication link;
(k) parsing the transaction response to obtain an index to the corresponding logged transaction information in the first transaction database in the server;
(l) updating the transaction response in the second transaction database in the server with information from the response transaction from the host; and (m) displaying payment information corresponding to the transaction on a display.

9. The method of claim 8, including the step of the server detecting a transaction response failure and resending the corresponding transaction from first transaction database with appropriate modifications.

10. The method of claim 8, including the step of detecting a valid retry transaction, retrieving information from the second transaction database at the gateway and updating the transaction with previously received host transaction results from the retrieved information before transmitting the transaction to the server.

11. The method of claim 8, including the step of detecting an invalid transaction by parsing a transaction to obtain a key and comparing the key to keys in the second transaction database at the gateway, determining that a key from the transaction is identical to a key in the second transaction database and rejecting the transaction.

12. The method of claim 8, including the step of detecting a stale transaction by comparing a time stamp field in the transaction to a current time and rejecting the transaction if the differential exceeds a predefined value.

13. The method of claim 12, including the step of modifying the predefined value dynamically.

14. The method of claim 8, including the step of providing support for a secure electronic protocol.

15. An apparatus for communicating between a gateway, and an existing host payment application, comprising:
(a) program means for establishing a communication link between the gateway and the host payment application;
(c) program means for receiving a host message in response to a gateway transaction;
(d) program means for parsing one or more transaction response values from the host message;
(e) program means for mapping the one or more transaction response values to a canonical response code; and program means for storing the canonical response code in a transaction log.

16. The apparatus of claim 15, including:
(g) program means for establishing a communication link between the gateway and the server;
(h) program means for transmitting the canonical response code from the gateway to the server;
(i) program means for including a database with the canonical response code to obtain a message; and (j) program means for displaying the message to an end user.

17. The apparatus of claim 15, wherein the messages include payment administration information.

18. The apparatus of claim 15, wherein the messages include payment exception information.

19. The apparatus of claim 15, wherein the messages include payment result information.

20. The apparatus of claim 15, including program means for modifying the database without impacting the system.

21. The apparatus of claim 15, wherein the canonical response code provides support for secure electronic protocol.

22. The apparatus for communicating between a server, a gateway and a host as recited in claim 15, further comprising:
(a) means for establishing a first communication link between the server and the gateway;
(b) means for logging transaction information in a first transaction database at the server;
(c) means for transmitting a transaction from the server to the gateway over the first communication link;
(d) means for establishing a second communication link between the gateway and the host;
(e) means for logging transaction information in a second transaction database at the gateway;
means for transmitting a transaction from the gateway to the host over the second communication link;
(g) means for receiving a transaction response from the host;
(h) means for parsing the transaction response to obtain an index to the corresponding logged transaction information in the second transaction database in the gateway;
(i) means for updating the transaction response in the second transaction database in the gateway with information from the response transaction from the host;
(j) means for transmitting the response transaction to the server over the first communication link;
(k) means for parsing the transaction response to obtain an index to the corresponding logged transaction information in the first transaction database in the server;
(l) means for updating the transaction response in the second transaction database in the server with information from the response transaction from the host; and (m) means for displaying payment information corresponding to the transaction on a display.