AUTHORIZING PAYMENTS USING PAYMENT CARDS

FIELD

This disclosure relates generally to authorizing payments using payment cards. BACKGROUND

Payments for transactions, such as purchases of goods or services, may be conducted using payment cards, such as credit cards or debit cards. However, after such a transaction appears complete, such a payment may sometimes be declined following a challenge to the transaction, such as a challenge to authorization of use of the payment card. In many cases, a merchant will not receive such a payment if the transaction is challenged, so the merchant may assume a risk that a payment using a payment card may not be received after a transaction involving the payment appears complete.

When a merchant obtains a payment using certain card authorization devices in certain ways, such as authorization using an integrated circuit and a personal identification number ("PIN") for example, the merchant may reduce or avoid the risk that the payment may be declined after a transaction involving the payment appears complete. However, security features of such authorization devices have required such card authorization devices to be at or part of a point-of-sale system. Therefore, card authorization devices that allow a merchant to reduce or avoid the risk that the payment may be declined after a transaction involving the payment appears complete have only been available for limited types of point-of-sale systems and, for example, have not been available for cloud-based point-of-sale systems.

SUMMARY

According to one embodiment, there is disclosed a method of authorizing a payment using a payment card. The method comprises receiving, via at least one public network, a card authorization request, and in response to receiving the card authorization request, causing at least one merchant terminal to transmit, via at least one private network, a local card authorization request to at least one card authorization device. The method further comprises, in response to transmitting the local card authorization request, receiving, via the at least one private network, card authorization data from the at least one card authorization device, and in response to receiving the card authorization data, causing the at least one merchant terminal to transmit, via the at least one public network, a card authorization response to a point-of-sale ("POS") device.

Receiving the card authorization request may comprise receiving the card authorization request in response to causing the at least one merchant terminal to initiate a financial transaction comprising the payment.

Causing the at least one merchant terminal to initiate the financial transaction may comprise causing the at least one merchant terminal to transmit, via the at least one public network, a transaction initiation request to the POS device.

The card authorization request may comprise at least one identifier identifying the at least one card authorization device.

The at least one identifier identifying the at least one card authorization device may comprise a private internet protocol ("IP") address identifying the at least one card authorization device.

The local card authorization request may comprise a hypertext transfer protocol ("HTTP") request.

Causing the at least one merchant terminal to transmit the local card authorization request to the at least one card authorization device may comprise causing the at least one merchant terminal to forward the card authorization request to the at least one card authorization device.

The local card authorization request may comprise at least one identifier identifying the at least one merchant terminal.

The at least one identifier identifying the at least one merchant terminal may comprise a private IP address identifying the at least one merchant terminal.

The local card authorization request may comprise a port number of the at least one merchant terminal.

The at least one card authorization device may be configured to obtain the card authorization data in response to interacting with an integrated circuit card ("ICC"). The at least one card authorization device may be restricted to communicating via the at least one private network.

The card authorization response may comprise the card authorization data.

The method may further comprise, in response to transmitting the card authorization response, receiving, from the POS device via the at least one public network, a payment authorization response, wherein the payment authorization response comprises a payment approval message or a payment rejection message.

The method may further comprise, in response to receiving the payment authorization response, causing the at least one merchant terminal to transmit, via the at least one private network, a local payment authorization response to the at least one card authorization device.

Causing the at least one merchant terminal to transmit the local payment authorization response to the at least one card authorization device may comprise causing the at least one merchant terminal to forward the payment authorization response to the at least one card authorization device.

The POS device may comprise at least one web server hosting at least one computer- executable application.

The at least one public network may comprise the Internet.

According to another embodiment, there is disclosed at least one computer-readable medium comprising computer-readable codes which, when executed by at least one processor, cause the at least one processor to carry out any one of the methods as described above.

According to yet another embodiment, there is disclosed a system for authorizing a payment using payment card, the system comprising at least one merchant terminal comprising at least one processor, at least one memory, and at least one communications interface. The at least one memory comprises computer-readable codes which, when executed by the at least one processor, cause the at least one processor to, at least, receive, at the at least one communications interface via at least one public network, a card authorization request, and in response to receiving the card authorization request, cause the at least one communications interface to transmit, via at least one private network, a local card authorization request to at least one card authorization device. The codes further cause the at least one processor to, in response to transmitting the local card authorization request, receive, at the at least one communications interface via the at least one private network, card authorization data from the at least one card authorization device, and in response to receiving the card authorization data, cause the at least one communications interface to transmit, via the at least one public network, a card authorization response to a point-of-sale ("POS") device.

The system may further comprise the at least one card authorization device, wherein the at least one card authorization device is configured to communicate with the at least one merchant terminal over the at least one private network.

The at least one card authorization device may be configured to obtain the card authorization data in response to interacting with an integrated circuit card ("ICC").

The at least one card authorization device may be restricted to communicating via the at least one private network.

The system may further comprise at least one router in network communication with the at least one public network. The at least one private network may comprise a communication network between the at least one router, the at least one merchant terminal, and the at least one card authorization device.

The system may further comprise at least one modem in network communication with the public network. The router may be configured to communicate with the public network via the at least one modem.

The codes which, when executed, cause the at least one processor to receive the card authorization request may comprise codes which, when executed, cause the processor to receive the card authorization request in response to causing the at least one merchant terminal to initiate a financial transaction comprising the payment using the payment card.

The codes which, when executed, cause the at least one merchant terminal to initiate the financial transaction may comprise codes which, when executed, cause the at least one merchant terminal to transmit, via the public network, a transaction initiation request to the POS device.

The card authorization request may comprise at least one identifier identifying the at least one card authorization device. The at least one identifier identifying the at least one card authorization device may comprise a private internet protocol ("IP") address identifying the at least one card authorization device.

The local card authorization request may comprise a hypertext transfer protocol ("HTTP") request.

The codes which, when executed, cause the at least one merchant terminal to transmit the local card authorization request to the at least one card authorization device may comprise codes which, when executed, cause the at least one merchant terminal to forward the card authorization request to the at least one card authorization device.

The local card authorization request may comprise at least one identifier identifying the at least one merchant terminal.

The at least one identifier identifying the at least one merchant terminal may comprise a private IP address identifying the at least one merchant terminal.

The local card authorization request may comprise a port number of the at least one merchant terminal.

The card authorization response may comprise the card authorization data.

The at least one memory may further comprise computer-readable codes which, when executed, cause the at least one processor to, at least, in response to transmitting the card authorization response, receive, at the at least one communications interface from the POS device via the at least one public network, a payment authorization response. The payment authorization response may comprise a payment approval message or a payment rejection message.

The at least one memory may further comprise computer-readable codes which, when executed, cause the at least one processor to, at least, in response to receiving the payment authorization response, cause the at least one communications interface to transmit, via the at least one private network, a local payment authorization response to the at least one card authorization device.

The codes which, when executed, cause the at least one communications interface to transmit the local payment authorization response to the at least one card authorization device may comprise codes which, when executed, cause the at least one communications interface to forward the payment authorization response to the at least one card authorization device.

The POS device may comprise at least one web server hosting at least one computer- executable application.

The at least one public network may comprise the Internet.

According to yet another embodiment, there is disclosed a system for authorizing a payment using payment card, the system comprising a means for receiving, via at least one public network, a card authorization request, and a means for causing, in response to receiving the card authorization request, at least one merchant terminal to transmit, via at least one private network, a local card authorization request to a card authorization device. The system further comprises a means for receiving, via the at least one private network in response to transmitting the local card authorization request, card authorization data from the card authorization device, and a means for causing, in response to receiving the card authorization data, the at least one merchant terminal to transmit, via the at least one public network, a card authorization response to a point-of-sale ("POS") device.

Other aspects and features will become apparent to those ordinarily skilled in the art upon review of the following description of illustrative embodiments in conjunction with the accompanying figures.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a schematic illustration of a payment card authorization system according to an illustrative embodiment.

FIG. 2 is a schematic representation of a merchant terminal of the payment card authorization system of FIG. 1.

FIG. 3 is a schematic representation of a point-of-sale ("POS") device of the payment card authorization system of FIG. 1.

FIG. 4 is a schematic illustration of an account record entry stored in a storage memory of the POS device of FIG. 3.

FIG. 5 is a schematic illustration of illustrative signals transmitted and received in the payment card authorization system of FIG. 1. FIG. 6 is a schematic representation of codes executed by a POS card authorization application on the POS device of FIG. 3.

FIG. 7 is a schematic representation of codes executed by a relay application on the merchant terminal of FIG. 2. DETAILED DESCRIPTION

Referring to FIG. 1, a payment card authorization system according to an illustrative embodiment is shown generally at 100. The payment card authorization system 100 includes merchant terminals 102, 104, and 106, a router 108, card authorization devices 112, 114, and 116, and a modem 118. Each merchant terminal 102, 104, and 106, and each card authorization device 112, 114, and 116, is in network communication with the router 108 and with each other over a private network shown generally at 110.

A "private network" in this context may include a network that uses a private internet protocol ("IP") address space, such as an IP address range of 192.168.0.0 - 192.168.255.255, of 10.0.0.0 - 10.255.255.255, or of 172.16.0.0 - 172.31.255.255, for example, although private networks in alternative embodiments may differ. In the illustrated embodiment, each merchant terminal 102, 104, and 106, and each card authorization device 112, 114, and 116, may have a private IP address between 192.168.0.0 - 192.168.255.255, and such a private IP address may function as an identifier of the merchant terminal or of the card authorization device. In other embodiments, each merchant terminal 102, 104, and 106, and each card authorization device 112, 114, and 116, may have a private IP address in a different private IP address space, or may have a different type of identifier in a different type of private network.

Card authorization devices 112, 114, and 116 may be devices provided by companies such as PAX Technologies Limited, Verifone Incorporated, or Ingenico Group, for example. In one embodiment, one or more of the card authorization devices 112, 114, and 116 may be a PAX™ SP-30 model, for example. In the embodiment shown, the card authorization device 112 includes a processor, a memory, a display screen 140, a keypad 142, a chip card reader 144 for interfacing with integrated circuit payment cards, and a contactless card reader, such as an RFID reader for example, for interfacing with integrated circuit payment cards or other contactless payment cards. In some embodiments, card authorization device 112 may also include a magnetic stripe reader for interfacing with magnetic stripe payment cards. In some embodiments, the card authorization device 112 may be a Europay-Mastercard-Visa, or EMV™, device.

The card authorization device 112 also includes a network interface for communicating with the router 108. In some embodiments, one or more of the card authorization devices 112, 114, and 116 in the payment card authorization system 100 may be restricted to being identified by private IP addresses, such as IP addresses in the range of 192.168.0.0 - 192.168.255.255, for example, or one or more of the card authorization devices 112, 114, and 116 in the payment card authorization system 100 may be restricted in other ways to communicating over one or more different types of private network. As such, those card authorization devices may be restricted to communicating via a private network such as private network 110. In some embodiments, restricting card authorization devices to such private networks may provide additional security for the card authorization devices.

In the embodiment shown, the card authorization devices 114 and 116 function in substantially the same way as the card authorization device 112. However, in alternative embodiments, each of the card authorization devices 112, 114, and 116 may comprise different or additional systems and methods for obtaining card authorization data from payment cards. Further, although the illustrated embodiment describes three card authorization devices 112, 114, and 116, in alternative embodiments, there may be any number of card authorization devices.

The router 108 is also in network communication with a public network 120 (such as the Internet, for example) via the modem 118, and the payment card authorization system 100 further includes a point-of-sale ("POS") device 122 and a payment processor computer system 124 also in network communication with the public network 120. The payment processor computer system 124 is in network communication with a bank computer system 125 (or a computer system of one or more other financial institutions). Although the embodiment shown includes one POS device 122, one payment processor computer system 124, and one bank computer system 125, alternative embodiments may include one or more POS devices, one or more payment processor computer systems, and one or more computer systems of one or more banks or of one or more other financial institutions as described herein, for example. Referring to FIGs. 1 and 2, the merchant terminal 102 is a desktop computer and includes various hardware and software components that enable it to perform various functions of a personal computer. The merchant terminal 102 includes a display screen 126 and input devices including a keyboard 128 and a mouse 130. The merchant terminal 102 also includes a processor circuit, which in the embodiment shown includes microprocessor 146 and a program memory 148 and an input/output ("I/O") interface 150 each in communication with microprocessor 146. The I/O interface 150 includes user input interfaces 152 and 154 for receiving input signals from the keyboard 128 and the mouse 130 respectively, a network interface 156 that allows the merchant terminal 102 to send and receive input and output signals to and from the router 108, and at least one output interface 158 for producing output signals to cause the display screen 126 to display output.

The program memory 148 in the merchant terminal 102 may be implemented in a computer-readable storage medium, which in various embodiments may include one or more of a read-only memory ("ROM"), random access memory ("RAM"), a hard disc drive ("HDD"), and other computer-readable and/or computer-writable storage media. The program memory 148 generally includes codes for directing the microprocessor 146 to execute various functions of the merchant terminal 102. The program memory 148 includes operating system codes 160 for the merchant terminal 102 and WWW browser codes 162 for a World Wide Web ("WWW") browser application in order to allow a user of the merchant terminal 102 to access and interact with various WWW pages hosted on servers and other devices the public network 120 using hyper-text transfer protocol ("HTTP"). The program memory 148 also includes relay codes 164 generally for interfacing with one of card authorization devices 112, 114, and 116 as shown in FIG. 1 and as will be described in further detail below. In some embodiments, the relay codes 164 may be a plug-in or extension of the WWW browser application of the WWW browser codes 162. In alternative embodiments, the merchant terminal 102 may be partly or fully implemented using different hardware logic, which may include discrete logic circuits and/or an application specific integrated circuit ("ASIC") for example. Further, alternative embodiments may include alternatives to the program memory 148. For example, alternative embodiments may include one or more other applications or types of program codes that implement functionality similar to the WWW browser application of the WWW browser codes 162 and the relay codes 164 as described herein.

Referring back to FIG. 1, merchant terminal 104 is a tablet computer including a combination display screen/input device 132. Merchant terminal 106 is a laptop computer having a display screen 134 and input devices including a keyboard 136 and a trackpad 138. Merchant terminals 104 and 106 may include such hardware and software components as to allow them to function in substantially the same way as merchant terminal 102 as described herein, for example.

In the embodiment shown, the card authorization device 112 is positioned near the merchant terminal 102 for use by an individual using or near the merchant terminal 102, the card authorization device 114 is positioned near the merchant terminal 104 for use by an individual using or near the merchant terminal 104, and the card authorization device 116 is positioned near the merchant terminal 106 for use by an individual using or near the merchant terminal 106, so the merchant terminals 102, 104, and 106 are positioned near and associated with respective ones of the card authorization devices 112, 114, and 116 respectively. However, in alternative embodiments, the number of authorization devices may be different from the number of merchant terminals, and one or more authorization devices may or may not be near or associated with a respective one or more merchant terminals.

Further, although the payment card authorization system 100 in the illustrated embodiment includes three merchant terminals 102, 104, and 106, in alternative embodiments the payment card authorization system 100 may include any number of merchant terminals. Still further, although merchant terminals 102, 104, and 106 in the embodiment shown are a desktop computer, a tablet computer, and a laptop computer respectively, in alternative embodiments any merchant terminal may be any type of computer or computing device that may function for example as a merchant terminal as described herein, including but not limited to desktop computers, tablets, laptop computers, smart phones, and wearable technology such as smart watches, for example.

The router 108 is a networking device capable of sending and receiving IP packets via the private network 110 between the merchant terminals 102, 104, and 106, the card authorization devices 112, 114, and 116, and to and from the public network 120 via the modem 118, and the router 108 may provide network address translation services to allow the merchant terminals 102, 104, and 106 to communicate with the public network 120. In the illustrated embodiment, the router 108 is connected by a wire, such as with an Ethernet cable or similar twisted pair networking cable, for example, to the merchant terminal 102, the card authorization device 112, and the card authorization device 114. The router 108 is also wirelessly connected to the merchant terminal 104, the merchant terminal 106, and the card authorization device 116 by a wireless local area networking technology such as WiFi, for example. In other embodiments, the router 108 may be configured to communicate with any merchant terminal or card authorization device through any wired or wireless private network.

The modem 118 receives and modulates IP packets from the router 108 in order to transmit them to the public network 120, or from the public network 120 in order to transmit them to the router 108. The modem 118 may be a cable modem or a digital subscriber line ("DSL") modem, for example. In some embodiments, the router 108 and the modem 118 may be integrated together as a single device. Further, in some embodiments the router 108 may be connected to a switch to provide the payment card authorization system 100 with the ability to support additional merchant terminals and/or card authorization devices.

Referring to FIGs. 1 and 3, the POS device 122 includes a processor circuit, which in the embodiment shown includes a microprocessor 168 and a program memory 170, a storage memory 172, and an I/O interface 174 each in communication with microprocessor 168. The I/O interface 174 includes a network interface 176 that allows the POS device 122 to send and receive signals to and from the public network 120. In some embodiments, the I/O interface 174 may include additional user input/output interfaces for receiving input from user input devices such as a mouse and/or keyboard, and/or for displaying output to a user via a display device such as a screen. In some embodiments, the POS device 122 may also include various hardware and software components that enable it to perform various functions of a personal computer, such as an operating system and a WWW browser application that allow a user to access and interact with various WWW pages using HTTP. Further, in alternative embodiments, the POS device 122 may be partly or fully implemented using different hardware logic, which may include discrete logic circuits and/or an ASIC for example. Referring to FIG. 3, one or both of the program memory 170 and the storage memory 172 in the POS device 122 may be implemented in a computer-readable storage medium, which in various embodiments may include one or more of a ROM, RAM, HDD, and other computer-readable-and/or-writable storage media. The program memory 170 generally includes codes for directing the microprocessor 168 to execute various functions of the POS device 122, including POS login codes 178 and POS card authorization codes 180, which will be described in detail below. More generally, the program memory 170 may include codes for directing the microprocessor 168 to operate as a cloud-based POS, and may include codes for directing the microprocessor 168 to offer products, services, or both to users of computing devices that interact with the POS device 122 using a WWW browser application or other types of applications, for example.

The storage memory 172 includes an account data store 182 for storing account data and a transaction data store 184 for storing transaction data. The account data store 182 includes one or more account records such as account record 200 shown in FIG. 4. An account record may correspond to a user of the payment card authorization system 100, or more generally to a user account. Such user accounts may be maintained by the POS device 122. For example, one or more account records may correspond to respective user accounts associated with a respective one or more of the merchant terminals 102, 104, and 106. In the illustrated embodiment, the account record 200 includes a user ID field 202, a password field 204, a flag 206 indicating whether a local card authorization device is associated with the account record, and a private IP address field 208 for storing a private IP address (or other identifier) of any card authorization device associated with the account record. However, in alternative embodiments, the flag 206 and the private IP address field 208 may be omitted.

Referring back to FIG. 1, the payment processor computer system 124 includes a processor circuit and communications interface in communication with the public network 120 and operated by a payment processor company or service such as Moneris Solutions Corporation, Total System Services, Inc. (or TSYS™), Paymentech, LLC (or Chase Paymentech™), Paypal™, or Stripe™, for example, which acquires payment information from a customer to process a transaction on behalf of one or more banks or other financial institutions. In performing its various functions, the payment processor computer system 124 may communicate directly with the bank processor 125, for example, or may communicate with the bank processor 125 via the public network 120.

In operation, the payment card authorization system 100 may be used in a number of different ways. For example, one or more suppliers may offer products, services, or both on a POS provided by the POS device 122, and such a POS may be a "cloud-based" POS hosted on a WWW server and accessible by various different computing devices via the public network 120. A user of the payment card authorization system 100 may be a customer of such products or services, or may be another individual assisting such a customer. For example, the user may be a concierge of a hotel who uses the merchant terminal 102 in the payment card authorization system 100 to reserve or book a tour for a hotel guest. By way of another example, the user may be a travel agent who uses the merchant terminal 102 in the payment card authorization system 100 to book a flight for a customer. However the payment card authorization system 100 is used, one or more users (who may be a customer or an individual assisting a customer, for example) may use one or more of the merchant terminal 102, 104, and 106 to browse and select one or more products, one or more services, or both of one or more suppliers using the WWW browser application of the WWW browser codes 162 or another application, for example.

Such user interaction with the POS device 122 may cause the POS device 122 to store one or more transaction parameters in the transaction data store 184 in the storage memory 172. Such transaction parameters may include a total cost of the transaction, customer identification information, merchant terminal identification information, customer billing address, customer shipping address, date, time, and/or transaction location, for example. Such transaction parameters may be stored in the transaction data store 184 or modified at various different times.

Before, during, or after selection of any products or services and identification of one or more transaction parameters, a user may access the POS device 122 by "logging in" to a user account of the POS device 122, or more generally, a user account of the payment card authorization system 100. In some embodiments, the user may log into the POS device 122, or more generally into the payment card authorization system 100, by transmitting a signal to the POS device 122 via the WWW browser application of the WWW browser codes 162. In other embodiments, the user may log into the payment card authorization system 100 by causing a standalone application to transmit a signal to the POS device 122.

Referring to FIG. 5, an illustrative sequence of signals transmitted and received in the payment card authorization system 100 according to one embodiment is shown generally at 300. In this embodiment, the user is operating the payment card authorization system 100 to effect a transaction for a customer, whereby the customer will use the card authorization device 112 to authorize a payment for the transaction using a payment card of the customer. The user may log into the payment card authorization system 100. The user may cause the microprocessor 146 of the merchant terminal 102 to execute the WWW browser codes 162 or other program codes, and the user may input (using the keyboard 128, for example) a user ID and a password. A login signal 302 is then transmitted by the network interface 156 to the POS device 122 via the public network 120. In some embodiments, the login signal 302 may be an HTTP signal, may be encrypted, and may include the user ID and password supplied by the user.

Upon receiving the login signal 302 at the network interface 176, the microprocessor

168 in the POS device 122 executes the POS login codes 178 stored in the program memory 170. The POS login codes 178 cause the microprocessor 168 to access the account data store 182 to determine whether an account record 200 exists that indicates a user ID in the user ID field 202 matching the user ID in the login signal 302. If a corresponding account record 200 is located, the password provided in the login signal 302 is compared to the password indicated in the password field 204 of the corresponding account record 200 to determine whether the user at the merchant terminal 102 is to be granted access to the payment card authorization system 100.

If the password in the login signal 302 matches the password indicated in the password field 204 of the corresponding account record 200, the microprocessor 168 will cause the network interface 176 to transmit a login response signal 304 to the merchant terminal 102 via the public network 120 comprising an indication that the user has been granted access to the payment card authorization system 100. The user will then be able to conduct a transaction using the payment card authorization system 100. Alternatively, if the password indicated in the login signal 302 does not match the password in the password field 204 of the corresponding account record 200, or if an account record 200 cannot be found indicating a user ID in the user ID field 202 that matches the user ID provided in the login signal 302, the login response signal 304 will include a message indicating to the user at the merchant terminal 102 that the login attempt was unsuccessful. In some embodiments, the login response signal 304 may prompt the user to undertake one or more methods of resetting one or both of the user's password and user ID, such as by generating an additional webpage in the WWW browser application of the WWW browser codes 162, for example.

In one embodiment, logging into the system 100 may allow the user to modify the attributes of their account record 200 using the WWW browser of the WWW browser codes 162 or a standalone application, including attributes such as the flag 206 indicating whether to use a local card authorization device (as will be described below), and the field 208 indicating the private IP address (or other identifier) of the local card authorization device to be used. In some embodiments, the user may be able to modify different attributes depending on account permission settings, for example.

Once the user has successfully logged into the payment card authorization system 100, the user may use the merchant terminal 102 to process a transaction for the customer. To initiate the transaction, the user may cause the microprocessor 146 of the merchant terminal 102 to cause the network interface 156 to transmit a transaction initiation request signal 306 to the POS device 122 via the public network 120. The transaction initiation request signal 306 may be an HTTP signal transmitted as a result of clicking a "proceed to checkout" or similar link or button on a web page in the WWW browser of the WWW browser codes 162 or in another application, for example.

Referring to FIGs. 5 and 6, upon receiving the transaction initiation request signal 306 at the network interface 176, the microprocessor 168 of the POS device 122 may execute the POS card authorization codes 180 stored in the program memory 170 of the POS device 122 (shown in FIG. 6). In general, the POS card authorization codes 180 include blocks of code according to one embodiment for directing the microprocessor 168 to obtain and transmit card authorization data. The POS card authorization codes 180 are an example only, and in other embodiments, POS card authorization codes may differ. For example, in other embodiments, POS card authorization codes may be stored and executed in one process or thread, or may be stored and executed in different processes or threads, and POS card authorization codes of other embodiments may differ in other ways. In the embodiment shown, the POS card authorization codes 180 begin at 307 in response to receiving the transaction initiation request signal 306 at the network interface 176.

The POS card authorization codes 180 continue at block 402, which includes codes for causing the network interface 176 to transmit a card authorization request signal 308 to the merchant terminal 102 via the public network 120. The format of the card authorization request signal 308 may depend on parameters stored in the user's account record 200. For example, in the illustrated embodiment, block 402 includes codes for directing the microprocessor 168 to query the logged-in user's account record 200 in order to determine whether the flag 206 indicating to use a local card authorization device is set. If the flag 206 is set, the microprocessor 168 may then query field 208 of the user's account record 200 to obtain the private IP address (or other identifier) of the card authorization device 112.

The card authorization request signal 308 may include an amount of a payment to be authorized using the payment card of the customer. The card authorization request signal 308 may also include the private IP address (or other identifier) of the card authorization device 112. However, as indicated above, in alternative embodiments, the flag 206 and the private IP address field 208 may be omitted. In such embodiments, the card authorization request signal 308 may omit the private IP address (or other identifier) of the card authorization device 112.

In some embodiments, the merchant terminal which is to receive the card authorization request signal 308 may be identified according to that merchant terminal's public IP address, which may be identified in the transaction initiation request signal 306. In some embodiments, the card authorization request signal 308 may be in a format known in the art to be compatible with the card authorization device 112, such as, for example, a proprietary format unique to the manufacturer of the card authorization device 112. In some embodiments, the card authorization request signal 308 may be an HTTP signal.

The POS card authorization codes 180 continue at block 404, which includes codes for directing the microprocessor 168 to maintain the transaction parameters stored in the transaction data 184, and for directing the microprocessor 168 to cause the network interface 176 to wait for a card authorization response signal 314 to be transmitted back to the network interface 176 of POS device 122 (explained in greater detail below).

Referring to FIGs. 5 and 7, upon receiving the card authorization request signal 308 at the network interface 156 of merchant terminal 102, the microprocessor 146 of the merchant terminal 102 executes the relay codes 164 (shown in FIG. 7). In general, the relay codes 164 include blocks of code according to one embodiment for directing the microprocessor 146 to obtain and transmit card authorization data. The relay codes 164 are an example only, and in other embodiments, relay codes may differ. For example, in other embodiments, relay codes may be stored and executed in one process or thread, or may be stored and executed in different processes or threads, and relay codes of other embodiments may differ in other ways.

In the embodiment shown, the relay codes 164 begin at 309 in response to receiving the card authorization request signal 308. The relay codes 164 continue at block 502, which includes codes for directing the microprocessor 146 to cause the network interface 156 to transmit a local card authorization request signal 310 to the card authorization device 112 over the private network 110.

In the embodiment shown, the local card authorization request signal 310 may be transmitted to the private IP address (or other identifier) of the card authorization device 112 which was indicated in the card authorization request signal 308. As a result, in such an embodiment, a user account (identified by the account record 200 as shown in FIG. 4, for example) may be associated with a merchant terminal (such as the merchant terminal 102), and the user account may also identify a card authorization device (such as the card authorization device 112) associated with the merchant terminal, such that the local card authorization request signal 310 may be sent to the card authorization device (such as the card authorization device 112) associated with the merchant terminal as identified in the user account associated with the merchant terminal.

However, as indicated above, in alternative embodiments, the flag 206 and the private IP address field 208 may be omitted. In such embodiments, the private IP address (or other identifier) of the card authorization device 112 may be stored in a memory of the merchant terminal 102 or elsewhere, and in such embodiments the local card authorization request signal 310 is transmitted to the private IP address (or other identifier) of the card authorization device 112 as stored in the memory of the merchant terminal 102 or elsewhere, so again the local card authorization request signal 310 may be sent to the card authorization device associated with the merchant terminal.

The local card authorization request signal 310 may include some or all of the same data as the card authorization request signal 308. Alternatively, in some embodiments, the codes at block 502 may cause the microprocessor 146 to cause the network interface 156 to forward the card authorization request signal 308 to the private IP address (or other identifier) corresponding to the card authorization device 112 via the private network 110; in other words, the local card authorization request signal 310 may be substantially identical to the card authorization request signal 308, but for the private IP address to which it is transmitted.

In some embodiments, the local card authorization request signal 310 may include a private IP address of the merchant terminal 102 which generated the local card authorization request signal 310, and the local card authorization request signal 310 may additionally or alternatively include a port number of the merchant terminal 102, for example, a port number associated with the relay codes 164. More generally, in other embodiments, the local card authorization request signal 310 may include one or more identifiers that may allow the card authorization device 112 to return a signal to the merchant terminal 102, and the one or more identifiers may be associated with the relay codes 164 to allow the returned signal to be associated with the relay codes 164.

After receiving the local card authorization request signal 310, the card authorization device 112 may prompt the customer for authorization of payment, using a payment card, in an amount indicated in the card authorization request signal 308 and in the local card authorization request signal 310. For example, the card authorization device 112 may await card authorization using an integrated circuit of a payment card of the customer and a PIN from the customer, or the card authorization device 112 may await contactless interaction with an integrated circuit of a payment card of the customer.

While the card authorization device 112 waits to receive the customer's payment card authorization data, the relay codes 164 continue at block 504, which includes codes for directing the microprocessor 146 to cause the network interface 156 of the merchant terminal 102 to wait for a card authorization data signal 312 to be returned from the card authorization device 112.

Once the payment card authorization data have been received by the card authorization device 112, the card authorization device 112 may generate a card authorization data signal 312, including the payment card authorization data, and the card authorization device 112 may transmit the card authorization data signal 312 back to the network interface 156 of the merchant terminal 102. In some embodiments, one or both of the payment card authorization data and the card authorization data signal 312 may be encrypted.

In some embodiments, the card authorization device 112 may be programmed to automatically transmit the card authorization data signal 312 back to the private IP address which generated the local card authorization request signal 310; i.e. the private IP address corresponding to the merchant terminal 102. Alternatively, if the local card authorization signal 310 included one or more identifiers, such as a private IP address of the merchant terminal 102, a port number of the merchant terminal 102, or both as described above for example, the card authorization device 112 may be programmed to transmit the card authorization data signal 312 using one or more such identifiers.

Once the card authorization data signal 312 is transmitted back to the merchant terminal 102, the relay codes 164 continue at block 506, which includes codes for directing the microprocessor 146 to cause the network interface 156 to transmit a card authorization response signal 314, including the card authorization data provided by the customer via the card authorization device 112, to the POS device 122 via the public network 120. In one embodiment, the codes at block 506 may cause the network interface 156 to forward the card authorization data signal 312 to the public IP address corresponding to the POS device 122 via the public network 120; in other words, the card authorization response signal 314 may be substantially identical to the card authorization data signal 312, but for the public IP address to which it is to be transmitted.

After causing the network interface 156 to transmit the card authorization response signal 314, the relay codes 164 continue at block 508, which includes codes for directing the microprocessor 146 to cause the network interface 156 to wait for a payment authorization response signal 320 to be returned from the POS device 122 via the public network 120. Referring back to FIGs. 5 and 6, upon receiving the card authorization response signal 314, the POS card authorization codes 180 continue at block 406, which includes codes for directing the microprocessor 168 to cause the network interface 176 to transmit a payment authorization request signal 316 to the payment processor computer system 124 via the public network 120. The payment authorization request signal 316 may include the payment card authorization data provided in the card authorization response signal 314, and in some embodiments, may further include one or more of the transaction parameters stored by the POS device 122 as transaction data in the transaction data store 184. In one embodiment, the codes of block 406 may cause the network interface 176 to simply forward the card authorization response signal 314 to the payment processor computer system 124 via the public network 120.

The POS card authorization codes 180 continue at block 408, which includes codes for directing the microprocessor 168 to cause the network interface 176 to wait for a payment authorization data signal 318 to be returned from the payment processor computer system 124 via the public network 120.

Upon receiving the payment authorization request signal 316, the payment processor computer system 124 may communicate with the bank computer system 125 to determine whether the customer is authorized to make a purchase in the amount indicated in the card authorization request signal 308, in the local card authorization request signal 310, in the card authorization data signal 312, in the card authorization response signal 314, and in the payment authorization request signal 316. Once the payment processor computer system 124 has determined, via communication with the bank computer system 125, whether the customer is authorized to conduct the transaction, the payment processor computer system 124 may generate the payment authorization data signal 318 and transmit the payment authorization data signal 318 back to the POS device 122. The payment authorization data signal 318 may include an indication of whether the customer is authorized to conduct the transaction, and may, in some embodiments, include other or further information, such as an indication of why the customer is not authorized to conduct the transaction, for example. If the payment was authorized, the POS device 122 may accordingly process and conclude the transaction by the customer. After the payment authorization data signal 318 is received at block 408, the POS card authorization codes 180 continue at block 410, which includes codes for directing the microprocessor 168 to cause the network interface 176 to transmit a payment authorization response signal 320 to the merchant terminal 102 via the public network 120 in a similar manner as described above. The payment authorization response signal 320 may include the authorization data included in the payment authorization data signal 318, and in some embodiments, may be substantially identical to the payment authorization data signal 318. Therefore, the payment authorization response signal 320 may include either a "payment approval" or a "payment rejection" message, and may, in some embodiments, include any further information that may be provided by the payment processor computer system 124.

Referring back to FIGs. 5 and 7, after the payment authorization response signal 320 is received at the network interface 156, the relay codes 164 continue at block 510, which includes codes for directing the microprocessor 146 to cause the network interface 156 to transmit a local payment authorization response signal 322 to the card authorization device 112 via the private network 110, according to the private IP address (or other identifier) associated with the card authorization device 112 as described above. The local payment authorization response signal 322 may include the payment authorization data included in the payment authorization response signal 320, and in some embodiments, may be substantially identical to the payment authorization response signal 320. When the card authorization device 112 receives the local payment authorization response signal 322, the card authorization device 112 may display a payment approval or payment rejection message to the customer accordingly.

In general, the illustrative embodiments described herein may facilitate a secure and flexible way for a merchant to authorize a customer's payment card without exposing a payment card authorization device to a public network such as the internet. In other words, the relay application on a merchant terminal may provide a means of "insulating" the card authorization device from the threat of hackers or identity theft via the internet.

Although specific embodiments have been described and illustrated, such embodiments should be considered illustrative only and not as limiting the invention as construed according to the accompanying claims.