CA2559048A1 - Method and system for processing electronic payment transactions - Google Patents
Method and system for processing electronic payment transactions Download PDFInfo
- Publication number
- CA2559048A1 CA2559048A1 CA002559048A CA2559048A CA2559048A1 CA 2559048 A1 CA2559048 A1 CA 2559048A1 CA 002559048 A CA002559048 A CA 002559048A CA 2559048 A CA2559048 A CA 2559048A CA 2559048 A1 CA2559048 A1 CA 2559048A1
- Authority
- CA
- Canada
- Prior art keywords
- request
- transaction
- data
- settlement
- notification
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Abandoned
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/02—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP]
- G06Q20/023—Payment architectures, schemes or protocols involving a neutral party, e.g. certification authority, notary or trusted third party [TTP] the neutral party being a clearing house
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/102—Bill distribution or payments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/12—Payment architectures specially adapted for electronic shopping systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/38—Payment protocols; Details thereof
- G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
Abstract
Systems and methods are provided for processing transactions, and more specifically for receiving, processing and transmitting electronic payment transaction information. The system and method accesses a transaction software engine that effectuates the authorization of electronic payment requests and the settlement of authorized electronic payments. The transaction software engine, in accordance with an embodiment of the invention, resides at a merchant's site and more specifically within the merchant's server or computer which is in communication with one or more network terminals. With such a system, authorization requests may be sent by a terminal as each transaction occurs. Batches of settlement requests are processed after a predetermined time, although the transactions are processed on a transaction-by-transaction basis. In addition, the software engine enables the transmission of data over the Internet. As a result, the amount of time to process payment authorization and settlement is reduced as compared with the exclusive use of traditional telephone lines. Moreover, the transaction software engine is capable of accepting data of varying formats and re~encoding such data so that it can be processed by the transaction software engine. As a result, the transaction software engine can process data that is received from and sent to a variety of terminals as well as data that is sent to and received from a variety of data transaction providers host.
Description
METHOD AND SYSTEM FOR PROCESSING
Field of the Invention The invention relates to systems and methods for processing electronic transactions, and more specifically to a system and method for receiving, processing and transmitting electronic payment transaction information.
Background of the Invention Merchants typically accept various forms of payments from consumers in the course of engaging in the sale of goods andlor services. Some of these transactions include payments by cash, by check, debit card, credit card and the like.
Many of these forms of payments are electronic in nature (e.g., credit card, debit card, electronic check payments, stored value cards, loyalty points redemptions, electronic benefits transfers) and afford certain conveniences to consumers. For example, when electronic payments are accepted, consumers do not have to determine whether they have a sufficient amount of cash on their person, they often do not have to transfer funds to the merchant immediately, and at times, can purchase goods or services utilizing a line of credit.
0 Such electronic payment offerings also benefits merchants. For example, by offering an array of payment options to consumers, merchants typically recognize an increase in sales.
Nevertlxeless, present electronic payment systems have various drawbacks. For example, electronic payment systems that are located at a merchant
Field of the Invention The invention relates to systems and methods for processing electronic transactions, and more specifically to a system and method for receiving, processing and transmitting electronic payment transaction information.
Background of the Invention Merchants typically accept various forms of payments from consumers in the course of engaging in the sale of goods andlor services. Some of these transactions include payments by cash, by check, debit card, credit card and the like.
Many of these forms of payments are electronic in nature (e.g., credit card, debit card, electronic check payments, stored value cards, loyalty points redemptions, electronic benefits transfers) and afford certain conveniences to consumers. For example, when electronic payments are accepted, consumers do not have to determine whether they have a sufficient amount of cash on their person, they often do not have to transfer funds to the merchant immediately, and at times, can purchase goods or services utilizing a line of credit.
0 Such electronic payment offerings also benefits merchants. For example, by offering an array of payment options to consumers, merchants typically recognize an increase in sales.
Nevertlxeless, present electronic payment systems have various drawbacks. For example, electronic payment systems that are located at a merchant
2 5 site can have limitations with respect to the type of terminals that can interact with such system. Typically, a merchant site has one or more central computers or servers that support electronic payment terminals that are used at the merchant. Only those terminals that are configured to interact with the merchant computer or server can be used. One solution is to have multiple servers or computers, but such a system can be
3 0 expensive and cumbersome.
4 PCT/US2005/004738 Another solution is continuously modify the server or computer as new terminals are desired to be used at the merchant site. Such a solution, however, can require significant maintenance of the merchant's computer software and hardware.
In addition, electronic payment systems typically communicated via a dial-up modem. Such a system is inconvenient to consumers and merchants as transactions can take a long time to be completed, causing delay to the consumer and merchant. 1n addition, such systems do not support certain encryption techniques which provides increased security to the data transmitted over the electronic payment system. Moreover, using a dial-up modem requires that a plurality of telephone lines be used if a merchant desires to support transactions using numerous electronic payment terminals.
Also, many electronic terminals are configured such that transaction data relating to the settlement process is stored by such terminals and only sent to the merchant server as a batch. Such an arrangement results in delay when the settlement process is effectuated.
Summary of the Invention The invention relates to systems and methods for processing transactions, and more specifically to a system and method for receiving, processing 2 0 and transmitting electronic payment transaction information which overcomes the above-mentioned disadvantages. The system and method accesses a transaction software engine that effectuates the authorization of electronic payment requests and the settlement of authorized electronic payments. The transaction software engine, in accordance with an embodiment of the invention, resides at a merchant's site and 2 5 more specifically within the merchant's server or computer which is in communication with one or more network terminals. With such a system, data respecting certain transactions (e.g., authorization, settlement, etc.) are sent by a terminal to the software engine. Typically, authorization requests are processed when the electronic payment request is made. Settlement requests, in accordance with an 3 0 embodiment of the invention, are stored by the merchant's terminal until a predetermined time, and then each of the requests are transmitted on a transaction-by-transaction basis from the engine to a data transaction host for processing.
In addition, the software engine enables the transmission of data over the Internet. As a result, the amount of time to process payment authorization and settlement is reduced as compared with the exclusive use of traditional telephone lines.
Moreover, the transaction software engine is capable of accepting data of varying formats and re-encoding such data so that it may be processed by the transaction software engine. As a result, the transaction software engine can process data that is received from and sent to a variety of terminals as well as data that is sent to and received from a variety of data transaction providers host.
Brief Description of the Drawings Further objects, features and advantages of the invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings showing illustrative embodiments of the invention, in which:
Fig. 1 is a block diagram of an electronic payment transaction system, in accordance with an embodiment of the invention;
Fig. 2 is a block diagram of an electronic payment transaction system, 2 0 in accordance with another embodiment of the invention;
Fig. 3 is a block diagram of modules incorporated within a transaction software engine that processes electronic payment transactions, in accordance with an embodiment of the invention;
Fig. 4 illustrates data fields that are populated when processing 2 5 electronic payment transactions, in accordance with an embodiment of the invention;
Fig. 5 is a flowchart illustrating the method of authorizing an electronic payment request, in accordance with an embodiment of the invention; and Fig. 6 is a flowchart illustrating the method of settling electronic transactions, in accordance with an embodiment of the invention.
Detailed Description The invention relates to systems and methods for processing transactions, and more specifically to a system and method for receiving, processing and transmitting electronic payment transaction information. The system and method accesses a transaction software engine that effectuates the authorization of electronic payment requests and the settlement of authorized electronic payments. The transaction software engine, in accordance with an embodiment of the invention, resides at a merchant's site and more specifically within the merchant's server or computer which is in communication with one or more network or serial terminals.
With such a system, data respecting certain transactions (e.g., authorization, settlement, etc.) may be sent by a terminal to the software engine as each transaction occurs (as opposed to a group of transaction which are sent in a batch).
In addition, the software engine enables the transmission of data over the Internet. As a result, the amount of time to process payment authorization and settlement is reduced as compared with the exclusive use of traditional telephone lines.
Moreover, the transaction software engine is capable of accepting data of varying formats and re-encoding such data so that it may be processed by the transaction software engine. As a result, the transaction software engine can process 2 0 data that is received from and sent to a variety of terminals as well as data that is sent to and received from a variety of data transaction providers host.
The S s Fig. 1 is a block diagram illustrating electronic payment transaction 2 5 system 10 that incorporates features of the present invention. System 10, among other things, handles authorization of electronic payment transactions and settlement of such transactions by supporting communication between merchants, such as merchant 100, and payment processors, such as data transaction provider 140. As shown in Fig. l, various entities may be involved in such processing. For example, system 10 3 0 enables communication between merchant 100 and data transaction provider through a public network, such as the Internet 120, and, for example, a third party Internet Protocol Network (IPN) 130. In one embodiment, IPN 130 may be provided by Datawire Communication Network's Transaction Delivery Network.
Merchant 100 is any individual or entity that makes a request for authorization and/or settlement of an electronic payment transaction. It should be noted that the term "payment" used herein may include a transaction involving the payment of funds or the credit of funds. Typically, merchant 100 has one or more credit/debit card processing terminals for processing electronic payment requests. For example, in Fig. 1, merchant 100 has several terminals 102-1 to 102-N which are in communication with merchant server 110. In Fig. l, terminals 102-1 to 102 N
are connected to merchant server 110 by a serial connection, and therefore these terminals are referred to as "serial terminals." An example of a serial terminal 102 is Verifone's TRANZ model number 380.
When, for example, an electronic payment transaction request is generated by, let's say, serial terminal 102-1, data packets are sent from terminal 102, via a serial connection, to merchant server 110. Merchant server 110 comprises at least the following components: a central processing unit 112, transaction software engine 111 and Internet router 113.
CPU 112 may be embodied as a single commercially available 2 0 processor. Alternatively, in another embodiment, CPU 112 may be embodied as a number of such processors operating in parallel.
Transaction software engine 111 is operable to store one or more instructions, discussed further below in conjunction with Figs. 3-6, which the CPU
112 is operable to retrieve, interpret and execute. For example, engine 111 preferably 2 5 stores processes for authorizing and settling electronic payments as described below.
CPU 112 preferably includes a control unit, an arithmetic logic unit (ALU), and a CPU local memory storage device, such as, for example, a stackable cache or a plurality of registers, in a known manner. The control unit is operable to retrieve instructions from transaction software engine 111. The ALU is operable to 3 0 perform a plurality of operations needed to carry out instructions. The CPU local
In addition, electronic payment systems typically communicated via a dial-up modem. Such a system is inconvenient to consumers and merchants as transactions can take a long time to be completed, causing delay to the consumer and merchant. 1n addition, such systems do not support certain encryption techniques which provides increased security to the data transmitted over the electronic payment system. Moreover, using a dial-up modem requires that a plurality of telephone lines be used if a merchant desires to support transactions using numerous electronic payment terminals.
Also, many electronic terminals are configured such that transaction data relating to the settlement process is stored by such terminals and only sent to the merchant server as a batch. Such an arrangement results in delay when the settlement process is effectuated.
Summary of the Invention The invention relates to systems and methods for processing transactions, and more specifically to a system and method for receiving, processing 2 0 and transmitting electronic payment transaction information which overcomes the above-mentioned disadvantages. The system and method accesses a transaction software engine that effectuates the authorization of electronic payment requests and the settlement of authorized electronic payments. The transaction software engine, in accordance with an embodiment of the invention, resides at a merchant's site and 2 5 more specifically within the merchant's server or computer which is in communication with one or more network terminals. With such a system, data respecting certain transactions (e.g., authorization, settlement, etc.) are sent by a terminal to the software engine. Typically, authorization requests are processed when the electronic payment request is made. Settlement requests, in accordance with an 3 0 embodiment of the invention, are stored by the merchant's terminal until a predetermined time, and then each of the requests are transmitted on a transaction-by-transaction basis from the engine to a data transaction host for processing.
In addition, the software engine enables the transmission of data over the Internet. As a result, the amount of time to process payment authorization and settlement is reduced as compared with the exclusive use of traditional telephone lines.
Moreover, the transaction software engine is capable of accepting data of varying formats and re-encoding such data so that it may be processed by the transaction software engine. As a result, the transaction software engine can process data that is received from and sent to a variety of terminals as well as data that is sent to and received from a variety of data transaction providers host.
Brief Description of the Drawings Further objects, features and advantages of the invention will become apparent from the following detailed description taken in conjunction with the accompanying drawings showing illustrative embodiments of the invention, in which:
Fig. 1 is a block diagram of an electronic payment transaction system, in accordance with an embodiment of the invention;
Fig. 2 is a block diagram of an electronic payment transaction system, 2 0 in accordance with another embodiment of the invention;
Fig. 3 is a block diagram of modules incorporated within a transaction software engine that processes electronic payment transactions, in accordance with an embodiment of the invention;
Fig. 4 illustrates data fields that are populated when processing 2 5 electronic payment transactions, in accordance with an embodiment of the invention;
Fig. 5 is a flowchart illustrating the method of authorizing an electronic payment request, in accordance with an embodiment of the invention; and Fig. 6 is a flowchart illustrating the method of settling electronic transactions, in accordance with an embodiment of the invention.
Detailed Description The invention relates to systems and methods for processing transactions, and more specifically to a system and method for receiving, processing and transmitting electronic payment transaction information. The system and method accesses a transaction software engine that effectuates the authorization of electronic payment requests and the settlement of authorized electronic payments. The transaction software engine, in accordance with an embodiment of the invention, resides at a merchant's site and more specifically within the merchant's server or computer which is in communication with one or more network or serial terminals.
With such a system, data respecting certain transactions (e.g., authorization, settlement, etc.) may be sent by a terminal to the software engine as each transaction occurs (as opposed to a group of transaction which are sent in a batch).
In addition, the software engine enables the transmission of data over the Internet. As a result, the amount of time to process payment authorization and settlement is reduced as compared with the exclusive use of traditional telephone lines.
Moreover, the transaction software engine is capable of accepting data of varying formats and re-encoding such data so that it may be processed by the transaction software engine. As a result, the transaction software engine can process 2 0 data that is received from and sent to a variety of terminals as well as data that is sent to and received from a variety of data transaction providers host.
The S s Fig. 1 is a block diagram illustrating electronic payment transaction 2 5 system 10 that incorporates features of the present invention. System 10, among other things, handles authorization of electronic payment transactions and settlement of such transactions by supporting communication between merchants, such as merchant 100, and payment processors, such as data transaction provider 140. As shown in Fig. l, various entities may be involved in such processing. For example, system 10 3 0 enables communication between merchant 100 and data transaction provider through a public network, such as the Internet 120, and, for example, a third party Internet Protocol Network (IPN) 130. In one embodiment, IPN 130 may be provided by Datawire Communication Network's Transaction Delivery Network.
Merchant 100 is any individual or entity that makes a request for authorization and/or settlement of an electronic payment transaction. It should be noted that the term "payment" used herein may include a transaction involving the payment of funds or the credit of funds. Typically, merchant 100 has one or more credit/debit card processing terminals for processing electronic payment requests. For example, in Fig. 1, merchant 100 has several terminals 102-1 to 102-N which are in communication with merchant server 110. In Fig. l, terminals 102-1 to 102 N
are connected to merchant server 110 by a serial connection, and therefore these terminals are referred to as "serial terminals." An example of a serial terminal 102 is Verifone's TRANZ model number 380.
When, for example, an electronic payment transaction request is generated by, let's say, serial terminal 102-1, data packets are sent from terminal 102, via a serial connection, to merchant server 110. Merchant server 110 comprises at least the following components: a central processing unit 112, transaction software engine 111 and Internet router 113.
CPU 112 may be embodied as a single commercially available 2 0 processor. Alternatively, in another embodiment, CPU 112 may be embodied as a number of such processors operating in parallel.
Transaction software engine 111 is operable to store one or more instructions, discussed further below in conjunction with Figs. 3-6, which the CPU
112 is operable to retrieve, interpret and execute. For example, engine 111 preferably 2 5 stores processes for authorizing and settling electronic payments as described below.
CPU 112 preferably includes a control unit, an arithmetic logic unit (ALU), and a CPU local memory storage device, such as, for example, a stackable cache or a plurality of registers, in a known manner. The control unit is operable to retrieve instructions from transaction software engine 111. The ALU is operable to 3 0 perform a plurality of operations needed to carry out instructions. The CPU local
- 5 -memory storage device is operable to provide high-speed storage used for storing temporary results and control information.
Internet router 113 connects merchant server 110 to Internet 120, and may be, for example, a D-Link Router Model DI 704. In addition, merchant server 110 may also be connected to hosts 142-1 through 142-N via dial-up modem (not shown). In accordance with an embodiment of the invention, the communication between merchant server 110 and host 142 is, by default, attempted via Internet 110 and IPN 130. Thus, in such case, dial-up modem communication between transaction merchant server 110 and host 142 is only used when communication cannot be established by private network 130.
As discussed more fully below, data transaction provider hosts 142-1 through 142-N are configured for, among other things, receiving a request to process electronic payment transactions, determining the type of electronic payment transactions that are requested, authorizing or rejecting the electronic payment transactions, and settling the transactions. Data transaction provider hosts through 142-N is configured to process conventional credit card and debit card transactions, electronic checks, gift cards, and the like.
Fig. 2 is a block diagram illustrating electronic payment transaction system 20 in accordance with an embodiment of the invention. Payment transaction 2 0 system 20 is similar to system 10 - in that a merchant (e.g., merchant 101) communicates with host 142 of data transaction provider 140 - via Internet 120 and IPN 130 but system 20 provides for a Transmission Control Protocol/Internet Protocol (TCP/IP) connection between the terminals and the merchant server. Thus, as illustrated by Fig. 2, system 20 supports communication between TCP terminals 2 5 through 103-N and merchant server 110 via Ethernet switch 104. An example of TCP
terminal 103 is the Omni 3750. Like merchant server 100 of system 10, merchant server 110 of system 20 comprises transaction software engine 11 l, CPU 112 and Internet router 113.
Internet router 113 connects merchant server 110 to Internet 120, and may be, for example, a D-Link Router Model DI 704. In addition, merchant server 110 may also be connected to hosts 142-1 through 142-N via dial-up modem (not shown). In accordance with an embodiment of the invention, the communication between merchant server 110 and host 142 is, by default, attempted via Internet 110 and IPN 130. Thus, in such case, dial-up modem communication between transaction merchant server 110 and host 142 is only used when communication cannot be established by private network 130.
As discussed more fully below, data transaction provider hosts 142-1 through 142-N are configured for, among other things, receiving a request to process electronic payment transactions, determining the type of electronic payment transactions that are requested, authorizing or rejecting the electronic payment transactions, and settling the transactions. Data transaction provider hosts through 142-N is configured to process conventional credit card and debit card transactions, electronic checks, gift cards, and the like.
Fig. 2 is a block diagram illustrating electronic payment transaction system 20 in accordance with an embodiment of the invention. Payment transaction 2 0 system 20 is similar to system 10 - in that a merchant (e.g., merchant 101) communicates with host 142 of data transaction provider 140 - via Internet 120 and IPN 130 but system 20 provides for a Transmission Control Protocol/Internet Protocol (TCP/IP) connection between the terminals and the merchant server. Thus, as illustrated by Fig. 2, system 20 supports communication between TCP terminals 2 5 through 103-N and merchant server 110 via Ethernet switch 104. An example of TCP
terminal 103 is the Omni 3750. Like merchant server 100 of system 10, merchant server 110 of system 20 comprises transaction software engine 11 l, CPU 112 and Internet router 113.
- 6 -The Transaction Software Engine Transaction software engine 111 is operable to store instructions for, among other things, authorizing and settling electronic payments as described below.
Transaction software engine 111 is capable of providing such instructions by, in accordance with an embodiment of the invention, accessing one or more transaction modules instantiated by engine 111. Such modules are illustrated in Fig. 3 and include: work item module 302, packet resolver module 304, receiver module 306, sender module 308, format generator module 310, NBDot formatter module 312, DBDot formatter module 314, authorization handler module 316, settlement handler module 318, command handler module 320, IPN transporter module 322 and dial transporter module 324. These modules will now be described below with reference to Fig. 3. The process of authorizing and settling electronic payment transactions, by utilizing modules 302 through 324 of engine 111, is described below with reference to Figs. 5 and 6.
It should be noted that DBDot, NBDot and SVDot are data format types that comprise one or more data fields described below with reference to Fig. 4 and processed by one or more of hosts 142-1 to 142-N. These data formats typically differ with respect to length and/or order of the data fields included by the respective format type and may, in some instances, include additional information useful in 2 0 authorization and settlement processing.
Referring to Fig. 3, work item module 302 is responsible for temporarily storing data that is received by merchant server 110 from, for example, serial terminal 102, TCP terminal 103 or host 142. The data is temporarily stored such that engine 111 can process the data by one or more of the other modules 2 5 illustrated in Fig. 3. Work item module 302 is accessed each time terminal device 102 or 103 establishes a communication session with transaction software engine 111.
Thus, each time data is sent to engine 111, a work item is created by work item module 302 and, by accessing the other modules, enables the processing of such data.
Packet resolver 302 determines the request type that is associated with 3 0 the received data. Thus, packet resolver 302 determines whether the received data relates to a request for payment authorization, settlement request or a command.
It should be noted that the term "authorization" refers to approval by data transaction provider 140 to validate a transaction for a merchant 100 or 101.
Such authorization indicates, for example, the availability of a purchaser's credit limit at the time the authorization is requested or the validity of the consumer's account number. "Settlement" refers to the process of exchanging financial data resulting from sales transactions, cash disbursements, or merchandise credits, which are ultimately billed to an account of purchaser making an electronic payment. A
"command" is an instruction that controls transaction software engine 111, and may include the "stop" command which terminates one or more communications, a "start"
command which restores data flow of system 10 or 20, "power off' which shuts down engine 111, "power on" which turns on engine 111, and the like.
Receiver module 306 enables the processing of data that is received from transaction software engine 111. These devices include serial terminals through 102-N, TCP terminals 103-1 through 103-N or hosts 142-1 through 142-N.
Sender module 308, however, enables the processing of data that is received by transaction software engine 111, such as serial terminals 102- through 102-N, TCP
terminals 103-1 through 103-N or hosts 142-1 through 142-N. Handling incoming and outgoing information streams, by receiver module 306 and sender module 308, 2 0 respectively, facilitates the implementation of maintenance and enhancements to engine 111.
A built-in timer is incorporated into modules 306 and 308, such that communications made by systems 10 or 20 may be terminated in the event of a communication failure. In accordance with one embodiment of the invention, the 2 5 time is set to 60 seconds.
Format generator 310 identifies the manner in which the received data should be formatted. The format that is designated for data received and processed by transaction software engine 111 is, in accordance with an embodiment of the invention, dictated by the host 142 that is targeted for the transaction.
Thus, format 3 0 generator 310 determines which host 142 is designated to handle the transaction and _ g _ identifies the data format that is supported by such host 142. Determining which host 142 is designated to handle the transaction is accomplished by reading the data stored in the header of a packet for the data format (e.g., NBDot, SVDot, etc.) and the target host designated to process such data format. Thus, in such a manner, when receiving data from terminal 102 or 103, engine 111 determines whether the received data is in, for example, the DBDot, NBDot, SVDot or some other data format type. Upon identifying the data format of the received data, format generator identifies the appropriate formatter to be accessed to process received data. Two examples of formatter modules illustrated in Fig. 3 are NBDot formatter module 312 and DBDot formatter module 314, although of course transaction software engine 111 may be provided with additional formatter modules such that additional data formats may be supported by engine 111 as required by hosts 142-1 through 142-N.
Formatter modules 312 and 314 receive data, which is typically received in the form of packets in a stream, and parse such packets based on the packet's fields. A list of fields that, in accordance with an embodiment of the invention, may be included in communicated data packets and used by formatter modules 312 and 314 are described below with reference to Fig. 4.
Authorization handler module 316 is responsible for processing authorization requests. Authorization module handler 316 generates the packet header 2 0 for data packets relating to authorization. Such header includes, among other things, identification information for identifying the packet as carrying data for an authorization request. In addition, authorization handler module 316 delegates the authorization request data to the appropriate transporter. (See description of IPN
transporter module 322 and dial transporter module 324 below.) 2 5 Settlement handler module 318 is responsible for processing settlement requests. Settlement handler module 318 generates the packet header for data packets relating to settlement requests. Such header includes, among other things, identification information for identifying the packet as carrying data for a settlement request. In addition, settlement handler module 318 delegates the authorization 3 0 request data to the appropriate transporter. (See description of IPN
transporter module 322 and dial transporter module 324 below.) Command handler module 320 processes data that is received from a remote computer for controlling transaction software engine 111. This module parses and executes commands that allow for the remote control of transaction software engine 111. Thus, if a merchant desires to issue a command to stop or start transaction software enginel l l from, for example, a remote computer, commands issued from such computers are detected and processed by handler 320 of engine 111.
IPN transporter module 322 provides formatting for transmitting and receiving data packets over the Internet and dial transporter module 324 provides formatting for transmitting and receiving data packets using a dial-up modem.
In accordance with an embodiment of the invention, the data format used is an XML-based packet format.
NBDot Data Fields Fig. 4 illustrates fields that are incorporated in data packets that are handled by systems 10 and 20 to process authorization and settlement requests.
When data packets axe communicated among the various devices shown in Figs. 1 and 2, these fields either store information pertinent to the request or the field remains empty. In another embodiment of the invention, one or more fields may store null 2 0 data (such as the number 0) rather than being empty, such that each field either stores pertinent data or null data.
The fields incorporated in the data packets used by systems 10 and 20 are as follows: merchant number field 402, terminal serial number field 404, message type identifier field 406, account number field 408, expiration date field 410, transck-2 5 2 data field 412, track-1 data field 414, transaction amount field 416, transaction number 418, transaction date field 420, transaction time field 422 and error message field 424.
Merchant number field 402 refers to a unique merchant number that is assigned by data transaction provider 140 for each merchant 100, 101 that has access 3 0 to system 10, 20, respectively. Terminal serial number 404 refers to a unique terminal number that is stored by each of terminals 102-1 through 102-N and 103-1 through 103-N and is provided to engine 111 to indicate the source of a transmitted data packet each time a data packet is transmitted to engine 111.
Message type identifier field 406 identifies the type of message that is being transmitted across system 10 or 20. Message type may include:
authorization (i.e., a request for authorization from terminal 102 or 103 to engine 111, or from engine 111 to host 142), authorization response (i.e., an authorization response from host 142 to engine 11 l, or from engine 111 to terminal 102 or 103), settlement (i.e., a request for settlement from terminal 102 or 103 to engine 11 l, or from engine 111 to host 142), settlement response (i.e., an settlement response from host 142 to engine 111), close session (i.e., a request to terminate a session), close session response (i.e., a confirmation to a request for terminating a session).
Account number field 408 refers to the identification number of the account from which the funds are to be transferred to effectuate an electronic payment. Expiration date field 410 refers to the date in which the electronic payment card (e.g., credit card, debit card, gift card) is to expire.
Track 1 field 412 and track 2 field 414 comprise information that is stored on the magnetic strip of user's credit card, debit card, gift card, etc. In accordance with an embodiment of the invention, track 1 field is 79 bytes and 2 0 comprises the account number, expiration date, name and discretionary data. Track 2 field 414, in accordance with an embodiment of the invention, is 40 bytes in length and includes the account number, expiration date and discretionary number associated with the user's card.
Transaction amount field 416 refers to the amount of funds that are 2 5 involved in the electronic payment for which an authorization or settlement request is made. Transaction number field 418 refers to a unique identifier that is used to identify each transaction processed by systems 10 and 20.
Transaction date field 420 and transaction time field 422 refer to the date and time, respectively, upon which each electronic payment transaction was 3 0 processed by systems 10 and 20.
Error message field 424 stores information containing one or more error notifications which are communicated to merchant 100, 101 when one or more errors occur. In accordance with an embodiment of the invention, transaction software engine stores the error message in error message field 424 inside the same data packet that terminal 102 or 103 is expecting, and therefore the terminal can automatically display the received error message.
Other format types -- such as DBDot or SVDot -- may be used. DBDot and SVDot utilize many of the same data fields as described above with respect to NBDot. These data formats may differ with respect to length andlor order of the data fields included by the respective type and may, in some instances, include additional information useful in authorization and settlement processing.
Authorization Reguests When an electronic payment is effectuated, merchant 100 or 101 typically inputs the pertinent transaction information relating to the purchase (e.g., merchant identification information, consumer identification information, consumer account information, payment type, transaction amount, date, time) into an electronic payment processing terminal, such as serial terminal 102 or TCP/IP terminal 103.
This may be accomplished by, for example, swiping a card that contains the consumer 2 0 identification information, consumer account information and entering the transaction amount by a keypad situated on terminal 102 or 103. The remaining information may be generated automatically by terminals 102 or 103.
The inputted information is then entered thereby allowing merchant 100 or 101 to make a request for authorizing the payment transaction. As described 2 5 above, the authorization process enables approval by data transaction provider 140 to validate a transaction for a merchant 100 or 101. This validation ensures, for example, the availability of a purchaser's credit limit at the time the authorization is requested, that the account data that is provided is valid, and the like.
Fig. 5 is a flowchart which illustrates the process of performing an 3 0 authorization request, in accordance with an embodiment of the invention.
Such process is described with further reference to systems 10 and 20 of Figs. 1 and 2, respectively, and the software modules of Fig. 3.
At step 505, work item module 302 of transaction software engine 111 receives authorization data packets which includes data relating to a transaction that occurred at merchant 100 or 101. The authorization data populates at least the following fields of the data packets: merchant number 402, terminal serial number 404, message type identifier 406 (indicating that, in this instance, the message type relates to an authorization request), account number 408, expiration date 410, transaction amount 416, transaction number 418, transaction date 420 and transaction time 422.
Next, at step 510, format generator module 310, analyzes the formatted authorization packets to determine which of host 142-1 through 142-N is delegated to receive the authorization request. Upon determining the target host, format generator module 310 transmits the authorization data packets to the formatter that is associated with the target host 142, such that the authorization data packets can be read and processed by the target host 142. Thus, the data packets are forwarded from the format generator module 310 to NBDot Formatter 312 or DBDot formatter 314 (or some other formatter instantiated by transaction software engine 111 and associated with one or more of hosts 142-1 through 142-N).
2 0 At step 515, formatter 312 or 314 (depending on the targeted host data formatting requirements) encodes the header of the received authorization data packets for transmission to the target host 142. In so doing, authorization handler module 316 chooses either IPN transporter module 322 (if the data packets are transmitted over a IPN 130) or dial transporter module 324 (if the data packets are 2 5 transmitted over a dial-up modem). In accordance with an embodiment of the invention, the communication of data packets between engine 111 to host 142 is, by default, attempted via IPN 130. Thus, in such case, dial-up modem communication between transaction software engine 111 and host 142 is only used when communication cannot be established by private network 130. In accordance with 3 0 an embodiment of the invention, the header is encoded into Extensible Markup Language (XMII) -- a well known markup language which facilitates the interchange of structured data. In addition, the XML formatted data packets are communicated between transaction software engine 111 and host 142 over the Internet 120 using, in accordance with an embodiment of the invention, the Secured Sockets Layer (SSL) protocol. SSL is a well know protocol that transmits communications over the Internet in an encrypted form. SSL ensures that the information is sent, unchanged, and only to the host that is intended by merchant 100 or 101.
After transaction software engine 111 sends the authorization request to host 142 (at step 515), engine 111 then awaits a response from host 142. In accordance with an embodiment of the invention, the response is also in XML
language. Upon receiving the response, at step 520, engine 111 decodes the response received from host 142 via IPN 130 and then forwards the response to terminal 102 or 103 (step 525). The authorization response is typically in the form of transaction acceptance or rejection. Once the authorization response is received at terminal 102 or 103 of merchant 100 or 101, respectively, such merchant is informed of the authorization response as provided by terminal 102 or 103 and the authorization request process is complete.
It should be noted that the method for processing an authorization request for a serial terminal 102 versus a TCP terminal 103 are quite similar.
With 2 0 TCP terminal 103, however, connection and disconnection steps arte typically provided by system 20. When terminal 103 initially receives transaction data for transmission to software engine 11 l, terminal 103 opens a TCP/IP socket and connects to engine 111 using a configured Il' address. Similarly, after the authorization request is processed, engine 111 sends a signal to close the connection 2 5 between engine 111 and terminal 103.
Settlement Requests Authorized transactions are then settled by systems 10 and 20. In accordance with an embodiment of the invention, once a transaction is authorized, the 3 0 data required for settlement of such transaction is communicated to transaction software engine 111. Engine 111 is configured to store the authorization data for transactions that occurred during a predetermined period -- e.g., for a given day until midnight -- and when such predetermined period is met, engine 111 receives the settlement data from terminals 102 and 103 and then engine 11 land transmits to the data to host 142 on a transaction-by-transaction basis for the transactions that transpired for that period. Thus, each authorization request may be sent by engine 111 to host 142 via Internet 120 and IPN 130 as its own request. This is so even though more than one of the transaction-by-transaction requests may be in transmission and/or processed by, for example, host 142 at a given time.
As described above, the settlement process refers to the process of exchanging financial data resulting from a sales transactions, cash disbursements, or merchandise credits, which are ultimately billed to an account of the purchaser making an electronic payment.
Fig. 6 is a flowchart which illustrates the process of performing a settlement request, in accordance with an embodiment of the invention. Such process is described with further reference to systems 10 and 20 of Figs. 1 and 2, respectively, and the software modules of Fig. 3.
At step 605, work item module 302 of transaction software engine 111 receives settlement data packets which include data relating to a transaction that 2 0 occurred at merchant 100 or 101. The settlement data populates at least the following fields of the data packets for each transmission to be settled: merchant number 402, terminal serial number 404, message type identifier 406 (indicating that, in this instance, the message type relates to a settlement request), account number 408, expiration date 410, transaction amount 416, transaction number 418, transaction date 2 5 420 and transaction time 422.
Next, at step 610, format generator module 310, analyzes the formatted settlement packets to determine which of host 142-1 through 142-N is delegated to receive the settlement request. Upon determining the target host, format generator module 310 transmits the settlement data packets to the formatter that is associated 3 0 with the target host 142, such that the settlement data packets can be read and processed by the target host 142. Thus, the data packets are forwarded from the format generator module 310 to NBDot Formatter 312 or DBDot formatter 314 (or some other formatter stored by transaction software engine 111 and associated with one or more of hosts 142-1 through 142-N).
Next, at step 615, transaction software engine 111 transmits a settlement initiation request to host 142 and, at step 620, engine 111 awaits to receive an initiation response back from host 142.
Once such initiation handshake occurs, at step 625, transporter 322 or 324 encodes the header of the received settlement data packets for transmission to the target host 142. In so doing, settlement handler module 318 chooses either IPN
transporter module 322 (if the data packets are transmitted over IPN 130) or dial transporter module 324 (if the data packets are transmitted over a dial-up modem). In accordance with an embodiment of the invention, the communication of data packets between engine 111 to host 142 is, by default, attempted via IPN 130. Thus, in such case, dial-up modem communication between transaction software engine 111 and host 142 is only used when communication cannot be established by private network 130.
In accordance with an embodiment of the invention, the header is encoded into XML. In addition, the ~~ML, formatted data packets are communicated 2 0 between transaction software engine 111 and host 142 over the Internet 120 using, in accordance with an embodiment of the invention, the SSL protocol to ensure that the information is sent, unchanged, and only to the host that is intended by merchant 100 or 101.
After transaction software engine 111 sends the settlement request to 2 5 host 142 (at step 625), engine 111 then awaits a response from host 142 via IPN 130.
In accordance with an embodiment of the invention, the response is also in XML
language. Upon receiving the response, at step 630, engine 111 then sends a packet header response to terminal 102 or 103 (step 635) requesting the settlement information (described above) which is sent to host 142. Transaction software engine 3 0 111 then receives the settlement detail from terminal 102 and 103 (step 640). The settlement detail is then encoded at the instruction of format generator module 310 and sent to the targeted host 142 (step 645). Once the complete batch of settlement data is received and processed by host 142, engine 111 receives a settlement packet trailer indicating the end of settlement data packets (step 650). This trailer is then forwarded by engine 111 to terminal 102 or 103 (step 655) and then a settlement session termination request is sent to host 142 (step 660) indicating the end of the settlement process.
It should be noted that the method for processing a settlement request for a serial terminal 102 versus a TCP terminal 103 are quite similar. With TCP
terminal 103, however, connection and disconnection steps ante typically provided by system 20. Thus, when terminal 103 initially receives transaction data for transmission to transaction software engine 111, terminal 103 opens a TCP/IP
socket and connects to engine 111 using a configured IP address. Similarly, after the settlement request is processed, engine 111 sends a signal to close the connection between engine 111 and terminal 103.
The foregoing merely illustrates the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise numerous other arrangements which embody the principles of the invention and are thus within its spirit and scope.
2 0 For example, although the electronic payment processing terminals described herein are the Tranz 380 and Omni 3750, other types of terminals may be used. In addition the connections of these devices to merchant server 110 may be, in addition to an Ethernet or TCP/IP connection, a WI-FI hub with USB
connectivity, a wireless connection, or the like.
Transaction software engine 111 is capable of providing such instructions by, in accordance with an embodiment of the invention, accessing one or more transaction modules instantiated by engine 111. Such modules are illustrated in Fig. 3 and include: work item module 302, packet resolver module 304, receiver module 306, sender module 308, format generator module 310, NBDot formatter module 312, DBDot formatter module 314, authorization handler module 316, settlement handler module 318, command handler module 320, IPN transporter module 322 and dial transporter module 324. These modules will now be described below with reference to Fig. 3. The process of authorizing and settling electronic payment transactions, by utilizing modules 302 through 324 of engine 111, is described below with reference to Figs. 5 and 6.
It should be noted that DBDot, NBDot and SVDot are data format types that comprise one or more data fields described below with reference to Fig. 4 and processed by one or more of hosts 142-1 to 142-N. These data formats typically differ with respect to length and/or order of the data fields included by the respective format type and may, in some instances, include additional information useful in 2 0 authorization and settlement processing.
Referring to Fig. 3, work item module 302 is responsible for temporarily storing data that is received by merchant server 110 from, for example, serial terminal 102, TCP terminal 103 or host 142. The data is temporarily stored such that engine 111 can process the data by one or more of the other modules 2 5 illustrated in Fig. 3. Work item module 302 is accessed each time terminal device 102 or 103 establishes a communication session with transaction software engine 111.
Thus, each time data is sent to engine 111, a work item is created by work item module 302 and, by accessing the other modules, enables the processing of such data.
Packet resolver 302 determines the request type that is associated with 3 0 the received data. Thus, packet resolver 302 determines whether the received data relates to a request for payment authorization, settlement request or a command.
It should be noted that the term "authorization" refers to approval by data transaction provider 140 to validate a transaction for a merchant 100 or 101.
Such authorization indicates, for example, the availability of a purchaser's credit limit at the time the authorization is requested or the validity of the consumer's account number. "Settlement" refers to the process of exchanging financial data resulting from sales transactions, cash disbursements, or merchandise credits, which are ultimately billed to an account of purchaser making an electronic payment. A
"command" is an instruction that controls transaction software engine 111, and may include the "stop" command which terminates one or more communications, a "start"
command which restores data flow of system 10 or 20, "power off' which shuts down engine 111, "power on" which turns on engine 111, and the like.
Receiver module 306 enables the processing of data that is received from transaction software engine 111. These devices include serial terminals through 102-N, TCP terminals 103-1 through 103-N or hosts 142-1 through 142-N.
Sender module 308, however, enables the processing of data that is received by transaction software engine 111, such as serial terminals 102- through 102-N, TCP
terminals 103-1 through 103-N or hosts 142-1 through 142-N. Handling incoming and outgoing information streams, by receiver module 306 and sender module 308, 2 0 respectively, facilitates the implementation of maintenance and enhancements to engine 111.
A built-in timer is incorporated into modules 306 and 308, such that communications made by systems 10 or 20 may be terminated in the event of a communication failure. In accordance with one embodiment of the invention, the 2 5 time is set to 60 seconds.
Format generator 310 identifies the manner in which the received data should be formatted. The format that is designated for data received and processed by transaction software engine 111 is, in accordance with an embodiment of the invention, dictated by the host 142 that is targeted for the transaction.
Thus, format 3 0 generator 310 determines which host 142 is designated to handle the transaction and _ g _ identifies the data format that is supported by such host 142. Determining which host 142 is designated to handle the transaction is accomplished by reading the data stored in the header of a packet for the data format (e.g., NBDot, SVDot, etc.) and the target host designated to process such data format. Thus, in such a manner, when receiving data from terminal 102 or 103, engine 111 determines whether the received data is in, for example, the DBDot, NBDot, SVDot or some other data format type. Upon identifying the data format of the received data, format generator identifies the appropriate formatter to be accessed to process received data. Two examples of formatter modules illustrated in Fig. 3 are NBDot formatter module 312 and DBDot formatter module 314, although of course transaction software engine 111 may be provided with additional formatter modules such that additional data formats may be supported by engine 111 as required by hosts 142-1 through 142-N.
Formatter modules 312 and 314 receive data, which is typically received in the form of packets in a stream, and parse such packets based on the packet's fields. A list of fields that, in accordance with an embodiment of the invention, may be included in communicated data packets and used by formatter modules 312 and 314 are described below with reference to Fig. 4.
Authorization handler module 316 is responsible for processing authorization requests. Authorization module handler 316 generates the packet header 2 0 for data packets relating to authorization. Such header includes, among other things, identification information for identifying the packet as carrying data for an authorization request. In addition, authorization handler module 316 delegates the authorization request data to the appropriate transporter. (See description of IPN
transporter module 322 and dial transporter module 324 below.) 2 5 Settlement handler module 318 is responsible for processing settlement requests. Settlement handler module 318 generates the packet header for data packets relating to settlement requests. Such header includes, among other things, identification information for identifying the packet as carrying data for a settlement request. In addition, settlement handler module 318 delegates the authorization 3 0 request data to the appropriate transporter. (See description of IPN
transporter module 322 and dial transporter module 324 below.) Command handler module 320 processes data that is received from a remote computer for controlling transaction software engine 111. This module parses and executes commands that allow for the remote control of transaction software engine 111. Thus, if a merchant desires to issue a command to stop or start transaction software enginel l l from, for example, a remote computer, commands issued from such computers are detected and processed by handler 320 of engine 111.
IPN transporter module 322 provides formatting for transmitting and receiving data packets over the Internet and dial transporter module 324 provides formatting for transmitting and receiving data packets using a dial-up modem.
In accordance with an embodiment of the invention, the data format used is an XML-based packet format.
NBDot Data Fields Fig. 4 illustrates fields that are incorporated in data packets that are handled by systems 10 and 20 to process authorization and settlement requests.
When data packets axe communicated among the various devices shown in Figs. 1 and 2, these fields either store information pertinent to the request or the field remains empty. In another embodiment of the invention, one or more fields may store null 2 0 data (such as the number 0) rather than being empty, such that each field either stores pertinent data or null data.
The fields incorporated in the data packets used by systems 10 and 20 are as follows: merchant number field 402, terminal serial number field 404, message type identifier field 406, account number field 408, expiration date field 410, transck-2 5 2 data field 412, track-1 data field 414, transaction amount field 416, transaction number 418, transaction date field 420, transaction time field 422 and error message field 424.
Merchant number field 402 refers to a unique merchant number that is assigned by data transaction provider 140 for each merchant 100, 101 that has access 3 0 to system 10, 20, respectively. Terminal serial number 404 refers to a unique terminal number that is stored by each of terminals 102-1 through 102-N and 103-1 through 103-N and is provided to engine 111 to indicate the source of a transmitted data packet each time a data packet is transmitted to engine 111.
Message type identifier field 406 identifies the type of message that is being transmitted across system 10 or 20. Message type may include:
authorization (i.e., a request for authorization from terminal 102 or 103 to engine 111, or from engine 111 to host 142), authorization response (i.e., an authorization response from host 142 to engine 11 l, or from engine 111 to terminal 102 or 103), settlement (i.e., a request for settlement from terminal 102 or 103 to engine 11 l, or from engine 111 to host 142), settlement response (i.e., an settlement response from host 142 to engine 111), close session (i.e., a request to terminate a session), close session response (i.e., a confirmation to a request for terminating a session).
Account number field 408 refers to the identification number of the account from which the funds are to be transferred to effectuate an electronic payment. Expiration date field 410 refers to the date in which the electronic payment card (e.g., credit card, debit card, gift card) is to expire.
Track 1 field 412 and track 2 field 414 comprise information that is stored on the magnetic strip of user's credit card, debit card, gift card, etc. In accordance with an embodiment of the invention, track 1 field is 79 bytes and 2 0 comprises the account number, expiration date, name and discretionary data. Track 2 field 414, in accordance with an embodiment of the invention, is 40 bytes in length and includes the account number, expiration date and discretionary number associated with the user's card.
Transaction amount field 416 refers to the amount of funds that are 2 5 involved in the electronic payment for which an authorization or settlement request is made. Transaction number field 418 refers to a unique identifier that is used to identify each transaction processed by systems 10 and 20.
Transaction date field 420 and transaction time field 422 refer to the date and time, respectively, upon which each electronic payment transaction was 3 0 processed by systems 10 and 20.
Error message field 424 stores information containing one or more error notifications which are communicated to merchant 100, 101 when one or more errors occur. In accordance with an embodiment of the invention, transaction software engine stores the error message in error message field 424 inside the same data packet that terminal 102 or 103 is expecting, and therefore the terminal can automatically display the received error message.
Other format types -- such as DBDot or SVDot -- may be used. DBDot and SVDot utilize many of the same data fields as described above with respect to NBDot. These data formats may differ with respect to length andlor order of the data fields included by the respective type and may, in some instances, include additional information useful in authorization and settlement processing.
Authorization Reguests When an electronic payment is effectuated, merchant 100 or 101 typically inputs the pertinent transaction information relating to the purchase (e.g., merchant identification information, consumer identification information, consumer account information, payment type, transaction amount, date, time) into an electronic payment processing terminal, such as serial terminal 102 or TCP/IP terminal 103.
This may be accomplished by, for example, swiping a card that contains the consumer 2 0 identification information, consumer account information and entering the transaction amount by a keypad situated on terminal 102 or 103. The remaining information may be generated automatically by terminals 102 or 103.
The inputted information is then entered thereby allowing merchant 100 or 101 to make a request for authorizing the payment transaction. As described 2 5 above, the authorization process enables approval by data transaction provider 140 to validate a transaction for a merchant 100 or 101. This validation ensures, for example, the availability of a purchaser's credit limit at the time the authorization is requested, that the account data that is provided is valid, and the like.
Fig. 5 is a flowchart which illustrates the process of performing an 3 0 authorization request, in accordance with an embodiment of the invention.
Such process is described with further reference to systems 10 and 20 of Figs. 1 and 2, respectively, and the software modules of Fig. 3.
At step 505, work item module 302 of transaction software engine 111 receives authorization data packets which includes data relating to a transaction that occurred at merchant 100 or 101. The authorization data populates at least the following fields of the data packets: merchant number 402, terminal serial number 404, message type identifier 406 (indicating that, in this instance, the message type relates to an authorization request), account number 408, expiration date 410, transaction amount 416, transaction number 418, transaction date 420 and transaction time 422.
Next, at step 510, format generator module 310, analyzes the formatted authorization packets to determine which of host 142-1 through 142-N is delegated to receive the authorization request. Upon determining the target host, format generator module 310 transmits the authorization data packets to the formatter that is associated with the target host 142, such that the authorization data packets can be read and processed by the target host 142. Thus, the data packets are forwarded from the format generator module 310 to NBDot Formatter 312 or DBDot formatter 314 (or some other formatter instantiated by transaction software engine 111 and associated with one or more of hosts 142-1 through 142-N).
2 0 At step 515, formatter 312 or 314 (depending on the targeted host data formatting requirements) encodes the header of the received authorization data packets for transmission to the target host 142. In so doing, authorization handler module 316 chooses either IPN transporter module 322 (if the data packets are transmitted over a IPN 130) or dial transporter module 324 (if the data packets are 2 5 transmitted over a dial-up modem). In accordance with an embodiment of the invention, the communication of data packets between engine 111 to host 142 is, by default, attempted via IPN 130. Thus, in such case, dial-up modem communication between transaction software engine 111 and host 142 is only used when communication cannot be established by private network 130. In accordance with 3 0 an embodiment of the invention, the header is encoded into Extensible Markup Language (XMII) -- a well known markup language which facilitates the interchange of structured data. In addition, the XML formatted data packets are communicated between transaction software engine 111 and host 142 over the Internet 120 using, in accordance with an embodiment of the invention, the Secured Sockets Layer (SSL) protocol. SSL is a well know protocol that transmits communications over the Internet in an encrypted form. SSL ensures that the information is sent, unchanged, and only to the host that is intended by merchant 100 or 101.
After transaction software engine 111 sends the authorization request to host 142 (at step 515), engine 111 then awaits a response from host 142. In accordance with an embodiment of the invention, the response is also in XML
language. Upon receiving the response, at step 520, engine 111 decodes the response received from host 142 via IPN 130 and then forwards the response to terminal 102 or 103 (step 525). The authorization response is typically in the form of transaction acceptance or rejection. Once the authorization response is received at terminal 102 or 103 of merchant 100 or 101, respectively, such merchant is informed of the authorization response as provided by terminal 102 or 103 and the authorization request process is complete.
It should be noted that the method for processing an authorization request for a serial terminal 102 versus a TCP terminal 103 are quite similar.
With 2 0 TCP terminal 103, however, connection and disconnection steps arte typically provided by system 20. When terminal 103 initially receives transaction data for transmission to software engine 11 l, terminal 103 opens a TCP/IP socket and connects to engine 111 using a configured Il' address. Similarly, after the authorization request is processed, engine 111 sends a signal to close the connection 2 5 between engine 111 and terminal 103.
Settlement Requests Authorized transactions are then settled by systems 10 and 20. In accordance with an embodiment of the invention, once a transaction is authorized, the 3 0 data required for settlement of such transaction is communicated to transaction software engine 111. Engine 111 is configured to store the authorization data for transactions that occurred during a predetermined period -- e.g., for a given day until midnight -- and when such predetermined period is met, engine 111 receives the settlement data from terminals 102 and 103 and then engine 11 land transmits to the data to host 142 on a transaction-by-transaction basis for the transactions that transpired for that period. Thus, each authorization request may be sent by engine 111 to host 142 via Internet 120 and IPN 130 as its own request. This is so even though more than one of the transaction-by-transaction requests may be in transmission and/or processed by, for example, host 142 at a given time.
As described above, the settlement process refers to the process of exchanging financial data resulting from a sales transactions, cash disbursements, or merchandise credits, which are ultimately billed to an account of the purchaser making an electronic payment.
Fig. 6 is a flowchart which illustrates the process of performing a settlement request, in accordance with an embodiment of the invention. Such process is described with further reference to systems 10 and 20 of Figs. 1 and 2, respectively, and the software modules of Fig. 3.
At step 605, work item module 302 of transaction software engine 111 receives settlement data packets which include data relating to a transaction that 2 0 occurred at merchant 100 or 101. The settlement data populates at least the following fields of the data packets for each transmission to be settled: merchant number 402, terminal serial number 404, message type identifier 406 (indicating that, in this instance, the message type relates to a settlement request), account number 408, expiration date 410, transaction amount 416, transaction number 418, transaction date 2 5 420 and transaction time 422.
Next, at step 610, format generator module 310, analyzes the formatted settlement packets to determine which of host 142-1 through 142-N is delegated to receive the settlement request. Upon determining the target host, format generator module 310 transmits the settlement data packets to the formatter that is associated 3 0 with the target host 142, such that the settlement data packets can be read and processed by the target host 142. Thus, the data packets are forwarded from the format generator module 310 to NBDot Formatter 312 or DBDot formatter 314 (or some other formatter stored by transaction software engine 111 and associated with one or more of hosts 142-1 through 142-N).
Next, at step 615, transaction software engine 111 transmits a settlement initiation request to host 142 and, at step 620, engine 111 awaits to receive an initiation response back from host 142.
Once such initiation handshake occurs, at step 625, transporter 322 or 324 encodes the header of the received settlement data packets for transmission to the target host 142. In so doing, settlement handler module 318 chooses either IPN
transporter module 322 (if the data packets are transmitted over IPN 130) or dial transporter module 324 (if the data packets are transmitted over a dial-up modem). In accordance with an embodiment of the invention, the communication of data packets between engine 111 to host 142 is, by default, attempted via IPN 130. Thus, in such case, dial-up modem communication between transaction software engine 111 and host 142 is only used when communication cannot be established by private network 130.
In accordance with an embodiment of the invention, the header is encoded into XML. In addition, the ~~ML, formatted data packets are communicated 2 0 between transaction software engine 111 and host 142 over the Internet 120 using, in accordance with an embodiment of the invention, the SSL protocol to ensure that the information is sent, unchanged, and only to the host that is intended by merchant 100 or 101.
After transaction software engine 111 sends the settlement request to 2 5 host 142 (at step 625), engine 111 then awaits a response from host 142 via IPN 130.
In accordance with an embodiment of the invention, the response is also in XML
language. Upon receiving the response, at step 630, engine 111 then sends a packet header response to terminal 102 or 103 (step 635) requesting the settlement information (described above) which is sent to host 142. Transaction software engine 3 0 111 then receives the settlement detail from terminal 102 and 103 (step 640). The settlement detail is then encoded at the instruction of format generator module 310 and sent to the targeted host 142 (step 645). Once the complete batch of settlement data is received and processed by host 142, engine 111 receives a settlement packet trailer indicating the end of settlement data packets (step 650). This trailer is then forwarded by engine 111 to terminal 102 or 103 (step 655) and then a settlement session termination request is sent to host 142 (step 660) indicating the end of the settlement process.
It should be noted that the method for processing a settlement request for a serial terminal 102 versus a TCP terminal 103 are quite similar. With TCP
terminal 103, however, connection and disconnection steps ante typically provided by system 20. Thus, when terminal 103 initially receives transaction data for transmission to transaction software engine 111, terminal 103 opens a TCP/IP
socket and connects to engine 111 using a configured IP address. Similarly, after the settlement request is processed, engine 111 sends a signal to close the connection between engine 111 and terminal 103.
The foregoing merely illustrates the principles of the invention. It will thus be appreciated that those skilled in the art will be able to devise numerous other arrangements which embody the principles of the invention and are thus within its spirit and scope.
2 0 For example, although the electronic payment processing terminals described herein are the Tranz 380 and Omni 3750, other types of terminals may be used. In addition the connections of these devices to merchant server 110 may be, in addition to an Ethernet or TCP/IP connection, a WI-FI hub with USB
connectivity, a wireless connection, or the like.
Claims (41)
1. A method for processing an electronic payment transaction, comprising:
receiving a request for processing the electronic payment transaction from a payment terminal, the request including a format type;
determining the format type of the request;
identifying a host computer configured to process the determined format type; and transmitting the request to the identified host computer.
receiving a request for processing the electronic payment transaction from a payment terminal, the request including a format type;
determining the format type of the request;
identifying a host computer configured to process the determined format type; and transmitting the request to the identified host computer.
2. The method of claim 1 further comprising:
receiving a notification from the identified host indicating whether the request is approved.
receiving a notification from the identified host indicating whether the request is approved.
3. The method of claim 1 further comprising:
receiving a notification from the identified host indicating whether the request contains an error message.
receiving a notification from the identified host indicating whether the request contains an error message.
4. The method of claim 2 further comprising:
sending the notification to the payment terminal.
sending the notification to the payment terminal.
5. The method of claim 3 further comprising:
sending the notification to the payment terminal.
sending the notification to the payment terminal.
6. The method of claim 1, wherein the request comprises data packets having header information.
7. The method of claim 6, further comprising encoding the header information to enable communication of the request between the payment terminal and the host computer.
8. The method of claim 7, wherein the header information is encoded using an Extensible Markup Language.
9. The method of claim 1, wherein the request for processing the electronic payment transaction relates to authorizing the transaction.
10. The method of claim 1, wherein the request for processing the electronic payment transaction relates to settling the transaction.
11. A method for settling a plurality of electronic payments, comprising:
requesting from a terminal information relating to settlement of the plurality of electronic payments;
receiving at least one respective data packet having settlement information for each payment of said plurality of electronic payments;
determining the format type of each respective data packet;
identifying a host computer configured to process the determined format type of each respective data packet; and transmitting each respective data packet to the identified host computer, wherein the identified host computer is configured to process the format type of said each respective data packet.
requesting from a terminal information relating to settlement of the plurality of electronic payments;
receiving at least one respective data packet having settlement information for each payment of said plurality of electronic payments;
determining the format type of each respective data packet;
identifying a host computer configured to process the determined format type of each respective data packet; and transmitting each respective data packet to the identified host computer, wherein the identified host computer is configured to process the format type of said each respective data packet.
12. The method of claim 11 further comprising:
receiving a notification from the identified host indicating whether the settlement is processed.
receiving a notification from the identified host indicating whether the settlement is processed.
13. The method of claim 11 further comprising:
receiving a notification from the identified host indicating whether the settlement generates an error message.
receiving a notification from the identified host indicating whether the settlement generates an error message.
14. The method of claim 12 further comprising:
sending the notification to the payment terminal.
sending the notification to the payment terminal.
15. The method of claim 13 further comprising:
sending the notification to the payment terminal.
sending the notification to the payment terminal.
16. The method of claim 11 wherein the request comprises data packets having header information.
17. The method of claim 16, further comprising encoding the header information to enable communication of the request between the payment terminal and the host computer.
18. The method of claim 17 wherein the header information is encoded using an Extensible Markup Language.
19. A system for processing an electronic payment transaction, comprising:
an interface for receiving a request for processing the electronic payment transaction from a payment terminal, the request including a format type; and a processor for:
determining the format type of the request;
identifying a host computer configured to process the determined format type; and transmitting the request to the identified host computer.
an interface for receiving a request for processing the electronic payment transaction from a payment terminal, the request including a format type; and a processor for:
determining the format type of the request;
identifying a host computer configured to process the determined format type; and transmitting the request to the identified host computer.
20. The system of claim 19 wherein the processor is further configured for receiving a notification from the identified host indicating whether the request is approved.
21. The system of claim 19, wherein the interface is further configured for receiving a notification from the identified host indicating whether the request contains an error message.
22. The system of claim 20, wherein the processor is further configured for sending the notification to the payment terminal.
23. The system of claim 21, wherein the processor is further configured for sending the notification to the payment terminal.
24. The system of claim 19, wherein the request comprises data packets having header information.
25. The system of claim 24, wherein the processor is further configured for encoding the header information to enable communication of the request between the payment terminal and the host computer.
26. The system of claim 25 wherein, the header information is encoded using an Extensible Markup Language.
27. The system of claim 19, wherein the request for processing the electronic payment transaction relates to authorizing the transaction.
28. The system of claim 19, wherein the request for processing the electronic payment transaction relates to settling the transaction.
29. A system for settling a plurality of electronic payments, comprising:
an interface for receiving at least one respective data packet having settlement information for each payment of said plurality of electronic payments; and a processor for:
determining the format type of each respective data packet;
identifying a host computer configured to process the determined format type of each respective data packet; and transmitting each respective data packet to the identified host computer, wherein the identified host computer is configured to process the format type of said each respective data packet.
an interface for receiving at least one respective data packet having settlement information for each payment of said plurality of electronic payments; and a processor for:
determining the format type of each respective data packet;
identifying a host computer configured to process the determined format type of each respective data packet; and transmitting each respective data packet to the identified host computer, wherein the identified host computer is configured to process the format type of said each respective data packet.
30. The system of claim 29 wherein the interface is further configured for receiving a notification from the identified host indicating whether the settlement is processed.
31. The system of claim 29 wherein the interface is further configured for receiving a notification from the identified host indicating whether the settlement generates an error message.
32. The system of claim 30 wherein the processor is further configured for sending the notification to the payment terminal.
33. The system of claim 31 wherein the processor is further configured for sending the notification to the payment terminal.
34. The system of claim 29 wherein the request comprises data packets having header information.
35. The system of claim 34 wherein the processor is further configured for encoding the header information to enable communication of the request between the payment terminal and the host computer.
36. The system of claim 35 wherein the header information is encoded using an Extensible Markup Language.
37. The system of claim 29 wherein the request for processing the electronic payment transaction is received from the payment terminal by a serial connection.
38. The system of claim 29 wherein the request for processing the electronic payment transaction is received from the payment terminal by a an Internet protocol connection.
39. The system of claim 38 wherein the Internet protocol connection comprises a TCP/IP connection.
40. The system of claim 19, wherein the processor transmits the request to the host computer over the Internet.
41. The system of claim 19, wherein the processor transmits the request to the host computer by modem.
Applications Claiming Priority (3)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US10/799,254 | 2004-03-12 | ||
| US10/799,254 US7577599B2 (en) | 2004-03-12 | 2004-03-12 | Method and system for processing electronic payment transactions |
| PCT/US2005/004738 WO2005091814A2 (en) | 2004-03-12 | 2005-02-15 | Method and system for processing electronic payment transactions |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CA2559048A1 true CA2559048A1 (en) | 2005-10-06 |
Family
ID=34920471
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CA002559048A Abandoned CA2559048A1 (en) | 2004-03-12 | 2005-02-15 | Method and system for processing electronic payment transactions |
Country Status (8)
| Country | Link |
|---|---|
| US (1) | US7577599B2 (en) |
| EP (1) | EP1730688A2 (en) |
| CN (1) | CN101124603A (en) |
| AU (1) | AU2005227112B2 (en) |
| BR (1) | BRPI0508450A (en) |
| CA (1) | CA2559048A1 (en) |
| MX (1) | MXPA06010391A (en) |
| WO (1) | WO2005091814A2 (en) |
Families Citing this family (23)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7577599B2 (en) | 2004-03-12 | 2009-08-18 | First Data Corporation | Method and system for processing electronic payment transactions |
| US7774402B2 (en) | 2005-06-29 | 2010-08-10 | Visa U.S.A. | Adaptive gateway for switching transactions and data on unreliable networks using context-based rules |
| US8523069B2 (en) | 2006-09-28 | 2013-09-03 | Visa U.S.A. Inc. | Mobile transit fare payment |
| US20080203170A1 (en) * | 2007-02-28 | 2008-08-28 | Visa U.S.A. Inc. | Fraud prevention for transit fare collection |
| US7527208B2 (en) | 2006-12-04 | 2009-05-05 | Visa U.S.A. Inc. | Bank issued contactless payment card used in transit fare collection |
| US8738485B2 (en) | 2007-12-28 | 2014-05-27 | Visa U.S.A. Inc. | Contactless prepaid product for transit fare collection |
| US8386349B2 (en) | 2007-02-28 | 2013-02-26 | Visa U.S.A. Inc. | Verification of a portable consumer device in an offline environment |
| US8118223B2 (en) | 2006-09-28 | 2012-02-21 | Visa U.S.A. Inc. | Smart sign mobile transit fare payment |
| US8346639B2 (en) | 2007-02-28 | 2013-01-01 | Visa U.S.A. Inc. | Authentication of a data card using a transit verification value |
| US10068220B2 (en) | 2006-10-11 | 2018-09-04 | Visa International Service Association | Systems and methods for brokered authentication express seller links |
| US8335745B2 (en) | 2006-10-11 | 2012-12-18 | Visa International Service Association | Method and system for processing micropayment transactions |
| US7904389B2 (en) * | 2007-05-30 | 2011-03-08 | Visa U.S.A. Inc. | Real time account update |
| US8706622B2 (en) * | 2008-08-05 | 2014-04-22 | Visa U.S.A. Inc. | Account holder demand account update |
| US7827108B2 (en) * | 2008-11-21 | 2010-11-02 | Visa U.S.A. Inc. | System and method of validating a relationship between a user and a user account at a financial institution |
| US8280788B2 (en) | 2009-10-29 | 2012-10-02 | Visa International Service Association | Peer-to-peer and group financial management systems and methods |
| US8676639B2 (en) | 2009-10-29 | 2014-03-18 | Visa International Service Association | System and method for promotion processing and authorization |
| US8347242B2 (en) * | 2010-01-05 | 2013-01-01 | The Boeing Company | Processing wiring diagrams in a data processing system |
| RU2732585C2 (en) | 2010-07-09 | 2020-09-22 | Виза Интернэшнл Сервис Ассосиэйшн | Gateway level of abstraction |
| US8800004B2 (en) * | 2012-03-21 | 2014-08-05 | Gary Martin SHANNON | Computerized authorization system and method |
| CN103903177B (en) * | 2012-12-26 | 2017-12-15 | 远光软件股份有限公司 | A kind of method and system for paying reconciliation |
| US9947007B2 (en) | 2013-01-27 | 2018-04-17 | Barry Greenbaum | Payment information technologies |
| US20150161597A1 (en) * | 2013-12-09 | 2015-06-11 | Kaushik Subramanian | Transactions using temporary credential data |
| US10453136B2 (en) * | 2016-05-25 | 2019-10-22 | StreamingEdge Inc. | Shared memory-based transaction processing |
Family Cites Families (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6711551B1 (en) * | 1996-06-05 | 2004-03-23 | Netzero, Inc. | Information provider, terminal and system and recording medium for the terminal |
| CN1252643C (en) * | 1996-06-05 | 2006-04-19 | 环球媒介股份有限公司 | Terminal information providing device, system and recording medium |
| US6609113B1 (en) | 1999-05-03 | 2003-08-19 | The Chase Manhattan Bank | Method and system for processing internet payments using the electronic funds transfer network |
| US7006993B1 (en) | 1999-05-28 | 2006-02-28 | The Coca-Cola Company | Method and apparatus for surrogate control of network-based electronic transactions |
| US20020026396A1 (en) * | 2000-04-21 | 2002-02-28 | Dent Warren T. | System and method facilitating personal electronic financial transactions |
| ATE452390T1 (en) * | 2001-08-03 | 2010-01-15 | Ericsson Telefon Ab L M | METHOD AND DEVICE FOR PAYMENTS BETWEEN TERMINAL DEVICES |
| CA2492715C (en) * | 2002-06-12 | 2016-12-06 | Cardinalcommerce Corporation | Universal merchant platform for payment authentication |
| US8725607B2 (en) * | 2004-01-30 | 2014-05-13 | The Clearing House Payments Company LLC | Electronic payment clearing and check image exchange systems and methods |
| US7577599B2 (en) | 2004-03-12 | 2009-08-18 | First Data Corporation | Method and system for processing electronic payment transactions |
-
2004
- 2004-03-12 US US10/799,254 patent/US7577599B2/en not_active Expired - Fee Related
-
2005
- 2005-02-15 WO PCT/US2005/004738 patent/WO2005091814A2/en active Application Filing
- 2005-02-15 CN CNA200580008058XA patent/CN101124603A/en active Pending
- 2005-02-15 MX MXPA06010391A patent/MXPA06010391A/en not_active Application Discontinuation
- 2005-02-15 CA CA002559048A patent/CA2559048A1/en not_active Abandoned
- 2005-02-15 AU AU2005227112A patent/AU2005227112B2/en not_active Ceased
- 2005-02-15 EP EP05713573A patent/EP1730688A2/en not_active Withdrawn
- 2005-02-15 BR BRPI0508450-4A patent/BRPI0508450A/en not_active IP Right Cessation
Also Published As
| Publication number | Publication date |
|---|---|
| MXPA06010391A (en) | 2007-01-11 |
| AU2005227112B2 (en) | 2009-04-02 |
| CN101124603A (en) | 2008-02-13 |
| EP1730688A2 (en) | 2006-12-13 |
| US7577599B2 (en) | 2009-08-18 |
| WO2005091814A2 (en) | 2005-10-06 |
| AU2005227112A1 (en) | 2005-10-06 |
| BRPI0508450A (en) | 2007-07-24 |
| US20050203842A1 (en) | 2005-09-15 |
| WO2005091814A3 (en) | 2006-11-02 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| AU2005227112B2 (en) | Method and system for processing electronic payment transactions | |
| US11017393B2 (en) | Direct connection systems and methods | |
| US8650118B2 (en) | Universal merchant platform for payment authentication | |
| RU2323477C2 (en) | System and method for purchasing goods and services through access stations for accessing data transmission network using a network of trading terminals | |
| EP1552447B1 (en) | Universal merchant platform for payment authentication | |
| US7716129B1 (en) | Electronic payment methods | |
| US10157375B2 (en) | Alternative payment implementation for electronic retailers | |
| US8645266B2 (en) | Universal merchant platform for payment authentication | |
| US20120028612A1 (en) | Method and system for verifying an identification of a person | |
| US20060253335A1 (en) | Cash based purchasing using mobile communication | |
| US20020103752A1 (en) | E-commerce payment solution | |
| US20080319913A1 (en) | Anonymous online payment systems and methods | |
| US20130221093A1 (en) | Payment Transaction Receipt System and Method | |
| US20080162366A1 (en) | Authentication data-enabled transfers | |
| US20190050842A1 (en) | Cloud-based on-premise payment method | |
| JP2002056335A (en) | Settlement demanding method in selling/providing commodity/service |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| EEER | Examination request | ||
| FZDE | Discontinued |