Architecture, system, and method for card-based transaction

Abstract

To provide an architecture, a system, and a method for card-based transaction.SOLUTION: In a card-based transaction system 200, an entrance server instance 212 generates a deterministic identifier of a card used in transaction from card data received for transaction and encodes the received card data to thereby generate an initial transaction message. A payment server instance 232, in response to a transaction permission determined based at least partially on the card deterministic identifier, updates the initial transaction message with permission data to provide the updated initial transaction message to an exit server instance 252. The exit server instance 252 transmits a final transaction message to a permission network server 280 for processing of a transaction between a seller and a customer based on the card data.SELECTED DRAWING: Figure 2A

Description

[Background technology]

[0001] Merchants, such as grocery stores, car services, dry cleaning services, etc., offer their products and services to customers for a fee. Typically, to collect the charge for the product or service, the merchant enters the amount to be collected into a point of sale (POS) device, which communicates this data to a card reader, which collects card data, such as Europay, Mastercard, Visa data collected from credit cards, debit cards, gift cards, electronic benefits, or other payment instruments provided by the customer. The card reader reads the magnetic strip or integrated circuit of the card to collect the card data. The POS device and / or card reader then use this card data to authorize the transaction using the services of a payment processing system that communicates with, for example, a bank and / or card company, to authorize and charge the merchant's fees for the transaction. Such a transaction can be referred to as a card present transaction, since the card reader used by the merchant collects the data from the customer's card at the time of sale. Similarly, card data may be entered, for example, via a graphical user interface into a POS device, mobile application, kiosk, etc., without collecting the card data from the card or presenting the card to a merchant during the transaction. Such a transaction is referred to as a card not present transaction, since the card data is not physically collected or inspected by the merchant. [Prior art documents] [Patent documents]

[0002] [Patent Document 1] US Patent Application Publication No. 15 / 997,416 [Patent Document 2] U.S. Pat. No. 9,830,596 Summary of the Invention [Problem to be solved by the invention]

[0003] Typically, the card data in any of these types of card-based transactions is then provided to a payment processing system from a card reader, POS device, merchant app, etc., using a communications network such as the Internet. These transactions are subject to risk due to the transmission of the card data, even if encrypted, over a public network, which may be intercepted by a nefarious actor. Additionally, the storage, use, and transmission of card data by a payment processing system, such as storing a set of card data in a repository and then transmitting the card data over a communications network to other systems (e.g., banks, card companies), is vulnerable to exploitation of the public facing interfaces of the payment processing system. [Means for solving the problem]

[0004] The present disclosure will become more fully understood from the following detailed description and the accompanying drawings of various embodiments, which are intended to facilitate explanation and understanding and should not be construed as limiting the embodiments shown and described herein. [Brief description of the drawings]

[0005] [Figure 1] FIG. 1 is a block diagram of an example system for card-based transactions with a commerce platform server(s). [Figure 2A] FIG. 1 is a block diagram of one embodiment of a distributed architecture of a commerce platform that includes an instance of an entry server, an instance of a payment server, and an instance of an exit server that provides controlled network communication flow during a transaction. [Figure 2B]1A-1D are block diagrams of different architectures for distributed execution of entry server instances, payment server instances and exit server instances. [Figure 2C] 1A-1D are block diagrams of different architectures for distributed execution of entry server instances, payment server instances and exit server instances. [Figure 2D] 1A-1D are block diagrams of different architectures for distributed execution of entry server instances, payment server instances and exit server instances. [Figure 2E] 1A-1D are block diagrams of different architectures for distributed execution of entry server instances, payment server instances and exit server instances. [Figure 2F] 1A-1D are block diagrams of different architectures for distributed execution of entry server instances, payment server instances and exit server instances. [Diagram 3] FIG. 1 is a block diagram of one embodiment of processing a card-based transaction using controlled network communication flow with an entry server instance, a payment server instance, and an exit server instance. [Figure 4] 1 illustrates an embodiment of a card-based transaction process executed by an entrance server instance of a commerce platform. [Diagram 5] 1 illustrates an embodiment of a card-based transaction process performed by a payment server instance of a commerce platform. [Figure 6] 1 illustrates an embodiment of a card-based transaction process executed by an exit server instance of a commerce platform. [Figure 7] 1 illustrates one embodiment of a deterministic card identifier generation process by a commerce platform for use during card-based and other transactions. [Figure 8] 1 is one embodiment of a computer system that can be used to support the systems and operations described herein. [Figure 9]1 is one embodiment of a reader device that can be used to assist with the systems and operations described herein. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0006] The following description sets forth numerous details. However, it will be apparent to one skilled in the art having the benefit of this disclosure that the embodiments described herein may be practiced without these specific details. In some instances, well-known structures and devices are shown in block diagram form, rather than in detail, in order to avoid obscuring the embodiments described herein.

[0007] Some of the detailed descriptions which follow are presented in terms of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of steps leading to a desired result. These steps require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0008] It should be noted, however, that these and similar terms are all to be associated with the appropriate physical quantities and are merely convenient labels given to these quantities. As will become apparent from the following description, unless specifically stated otherwise, descriptions utilizing terms such as "generating," "providing," "encrypting," "decrypting," "selecting," or "performing" throughout the description should be understood to refer to operations and processes of a computer system or similar electronic computing device that manipulate and transform data represented as physical (e.g., electronic) quantities in the registers and memory of the computer system into other data similarly represented as physical quantities in the memory, registers, or other such information storage, transmission, or display device of the computer system.

[0009] The embodiments described herein also relate to an apparatus for performing the operations herein. This apparatus may be specially constructed for the required purposes or may comprise a general-purpose computer selectively activated or reconfigured by a computer program stored in the computer. Such a computer program may be stored in a computer-readable storage medium such as any type of disk, including but not limited to floppy disks, optical disks, CD-ROMs, and magneto-optical disks, read-only memory (ROM), random access memory (RAM), EPROM, EEPROM, magnetic or optical cards, or any type of medium suitable for storing electronic instructions.

[0010] The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the methods of some embodiments. The required structure for a variety of these systems will appear from the description below. Additionally, the embodiments described herein are not described with reference to any particular programming language. It will be understood that a variety of programming languages ​​can be used to implement the teachings described herein.

[0011] FIG. 1 is a block diagram of an example system 100 for card-based transactions with a commerce platform server(s) 130.

[0012] In one embodiment, the system 100 includes one or more reader devices 115, one or more merchant point of sale (POS) devices 120, one or more merchant servers 140, one or more commerce platform servers 130, and one or more authorization network servers 150. In one embodiment, the merchant POS device 120 may be a computer device such as a smartphone, tablet computer, laptop computer, or computerized or other hardware device including typical computer hardware such as that shown in FIG. 8. Additionally, the merchant POS device(s) 120 may be configured to implement a merchant payment application that allows an employee or agent of the merchant to collect payment and complete a transaction for goods or services provided by the merchant, such as by entering card data. In an embodiment, the application may be a web-based application provided by one or more of the merchant server(s) 140 or other computer servers (not shown) and may be a web-based application that may be executed on a user device (e.g., a smartphone running a smartphone application, a tablet running a tablet application, etc.).

[0013] Additionally, the merchant server(s) 140, the authorization network server(s) 150 and the trading platform server(s) 130 may also be computer devices, such as server computers, desktop computers, etc., that include typical computer hardware such as that shown in FIG. 8 below.

[0014] The reader device(s) 115 are also computer processing devices that are each communicatively coupled to one of the merchant POS device(s) 120 via a wireless communication link such as Bluetooth, Zigbee, WLAN, etc., or a wired communication link such as LAN, WAN, Ethernet, etc.

[0015] In an embodiment, as shown in FIG. 9, the reader device 115 may include a card reader 902 (e.g., an integrated circuit or smart chip reader, a magnetic strip reader, a near field communication reader, etc.), one or more processors 904, a memory 906, a network interface 908 for establishing a local area or wide area communication link, at least one processor 908, and other hardware components typically associated with a mobile reader device (e.g., a pin pad, a display screen, buttons, a touch pad, etc.).

[0016] In an embodiment, a reader device interacts with a communicatively coupled merchant POS device to perform transactions using the services of the commerce platform server(s) 130, such as financial transaction processing operations using the card data. The reader device(s) 115 are responsible for collecting consumer payment card data (e.g., EMV card data, magnetic strip data, or other card data) by scanning the magnetic strip, reading an integrated circuit, etc., of the payment card 110 for card-based transactions between a merchant and its customer. Once read by the reader device 115, the card data is provided by the reader device over the network 102 to the commerce platform server(s) 130 for performing one or more payment processing operations. In an embodiment, this operation may include one or more of tokenizing, authorizing, and / or approving one or more financial aspects associated with the transaction using a distributed architecture that provides tight control over communication flow and card data protection as described in further detail herein. In other embodiments, the merchant POS device(s) may collect the card data, such as by entering the card data into a user interface of the merchant POS device(s) 120. In yet other embodiments, the merchant server(s) 140 may receive the card data for a transaction from a mobile application interface, a web-based interface, or the like, where a user enters the card data into the interface.

[0017] In an embodiment, communications between the reader device(s) 115, the merchant POS device(s) 120, and / or the merchant server(s) 140 and the commerce platform server(s) 130 for handling any received card data are established in a manner that does not expose the card data to any merchant system (e.g., the merchant POS device(s) 120 and the merchant server(s) 140), thereby preventing the merchant software running the POS checkout application, mobile application, merchant server(s) 140, etc. from violating the scope of PCI compliance requirements. Instead, after authorizing the transaction with the risk assessment system of the commerce platform server(s) 130 and / or after clearing the transaction with the authorization network(s) 150 (e.g., card brand system and issuing bank system), a token is generated by the commerce platform server(s) 130 and provided by the reader device 115 to the merchant system handling the transaction. The merchant system handling the transaction may then use the token authorizing the transaction to complete the transaction with the customer, and further provide the token to merchant server(s) 140 for use in obtaining rewards identified by the token thereafter by interacting with commerce platform server(s) 130. One embodiment of the use of reader devices in conjunction with merchant POS devices is described in U.S. patent application Ser. No. 15 / 997,416, filed Jun. 4, 2018, and entitled "Managed Integrated Payment Environment," the disclosure of which is incorporated by reference in its entirety.Additionally, one embodiment of a technique and system for tokenizing transactions using the services of a commerce platform is described in U.S. Pat. No. 9,830,596, issued Nov. 28, 2017, and entitled “Method for Conducting a Transaction Between a Merchant Site and a Customer's Electronic Device Without Exposing Payment Information to a Server-Side Application of the Merchant Site,” the disclosure of which is incorporated by reference in its entirety.

[0018] The reader device(s) 115, merchant POS device(s) 120, merchant server(s) 140, commerce platform server(s) 130, and authorization network server(s) 150 are coupled to network 102 and may communicate with each other using any of the standard protocols for information exchange. However, in an embodiment, due to the confidentiality of the card data exchanged during a card-based financial transaction, the reader device(s) 115, merchant POS device(s) 120, merchant server(s) 140, commerce platform server(s) 130, and authorization network server(s) 150 may communicate with each other using protocols for secure information exchange, such as Transport Layer Security (TLS), Secure Sockets Layer (SSL), Secure Shell (SSH), etc., as described herein. In an embodiment, one or more of the reader device(s) 115, merchant POS device(s) 120, merchant server(s) 140, trading platform server(s) 130, and authorization network server(s) 150 may operate on a local area network (LAN) and be incorporated in the same physical or logical system or in different physical or logical systems. Alternatively, one or more of the reader device(s) 115, merchant POS device(s) 120, merchant server(s) 140, trading platform server(s) 130, and authorization network server(s) 150 may reside on different LANs, wide area networks, cellular telephone networks, etc. that may be coupled to each other via the Internet but separated by firewalls, routers, and / or other network devices. It should be noted that various other network configurations may also be used, including, for example, hosted, distributed, centralized, etc.

[0019] In one embodiment, the processing nodes of the commerce platform server(s) 130 may reside on a single server or may be distributed among different servers coupled to other devices via a public network (e.g., the Internet) or a private network (e.g., a LAN). In an embodiment, the commerce platform systems executed by the commerce platform server(s) 130 are configured to perform individual stages of card-based transaction payment processing in response to receiving card data and other data for a transaction (e.g., user identifier, PIN number, transaction amount, merchant identifier, etc.) from the reader device(s) 115, merchant POS device(s) 120, and / or merchant server(s) 140. In an embodiment as described herein, the different commerce platform systems executed by the commerce platform server(s) 130 may include an ingress system (e.g., an instance of an ingress server) that accepts new card-based transactions and generates an initial transaction message including an encrypted version of the card data used in the transaction and a deterministic card identifier, a payment system (e.g., an instance of a payment server) that tokenizes the transaction after performing an initial authentication of the transaction based on a risk assessment, and an egress system (e.g., an instance of an egress server) that decrypts the encrypted card data and generates a final transaction message such as an ISO 8583 message for communication with the authorization network server(s) 150 (e.g., settles and provides the payment associated with the card used in the transaction). Each of the ingress, payment and egress servers and the processes executed by each thereof are described herein to protect card data communicated between servers, provide a distributed architecture that enforces strict communication protocols and flows to improve commerce platform data protection of card data, increase the efficiency of transaction processing, and provide a continuously active (e.g., active-active) architecture that maintains transaction processing even in the event of a server failure.

[0020] As described in further detail herein, the cryptographic and deterministic identification methods, information flow control, and distribution of the commerce platform transaction system may be utilized during card-present transactions, card-not-present transactions, and other types of transactions in which sensitive customer information is exchanged using network-based communications.

[0021] 2A is a block diagram of an embodiment of a distributed architecture 200 of a commerce platform including an entry server instance, a payment server instance, and an exit server instance that provide controlled network communication flow during a card-based transaction. In an embodiment, each of the entry server instance 212, the payment server instance 232, and the exit server instance 252 may be an application, a virtual machine, a virtualization server, or the like, executed by one or more computer systems, such as one or more computer system clusters as shown in FIGS. 2B-2F and described in further detail below. Additionally, although only one entry server instance 212, the payment server instance 232, and the exit server instance 252, respectively, are shown, multiple entry server instances 212, the payment server instance 232, and the exit server instance 252, respectively, may be distributed and run simultaneously to provide continuous availability of transaction processing capacity as described herein.

[0022] In an embodiment, the ingress server instance 212, the payment server instance 232, and the exit server instance 252 are each involved in performing operations at different stages of processing a card-based transaction between a merchant and its customer. The different stages refer to the ingress server instance 212 capturing card data, for example from a card reader used by the merchant, a mobile application distributed by the merchant, etc., and then obfuscating this card data in a deterministic manner that can be communicated in an initial transaction message to the payment server instance 232. The payment server instance 232 then receives the obfuscated card data in the initial transaction message, including at least a deterministic identifier for the card and encryption of sensitive card data (e.g., card number, card type, card security code, personal identification number, and other card data), as described in further detail below, and can then perform various processes that occur prior to transmitting the card data to the authorized network, including tokenizing the transaction, performing risk assessments, etc. Upon completion, the payment server instance 232 sends the initial transaction message to the exit server instance 252 which decrypts the sensitive card data before forwarding a final transaction message to one or more authorized network servers (e.g., a bank and / or card issuing server) to settle or complete the transaction.

[0023] Each process executed by the entry server instance 212, the payment server instance 232, and the exit server instance 252 is isolated from the other server instances and follows strict card data communication directions. Such process isolation allows each server instance to provide security from unwanted and potentially fraudulent sources. That is, the payment server instance only receives incoming communications from the entry server instance, and the exit server instance only receives incoming communications from the payment server instance 232. This serves at least two purposes, including providing a layer of isolation between the entry server instance, which communicates with the merchant system over the public network to execute the transaction, and the exit server instance, which should not receive communications from any system other than the payment server instance. To prevent unwanted access to sensitive information held by the exit server instance, it may block receipt of other communications, particularly from the public network. Additionally, the exit server instance may store card data in encrypted form in a card vault data store 266. By isolating the exit server instances from the entry server instances and enforcing strict communication flows, sensitive card data is removed to the greatest extent possible from public access (e.g., merchant system and public network access) to the card vault and / or encryption keys as described herein. As an additional benefit, such as by instantiating the entry and exit server instances in close geographic proximity to the merchant system(s) 290 and the authorization network server(s) 280, respectively, latency times for communications between such systems are improved, thereby further increasing the speed at which card-based transaction systems can process and settle transactions.

[0024] The operations performed by each of the entrance server instance 212, the payment server instance 232, and the exit server instance 252 are described in further detail below.

[0025] In an embodiment, the entry server instance 212 is one of multiple entry server instances instantiated and executed by one or more computer system clusters. In an embodiment, the entry server instance 212 receives and stores one or more encryption keys in a temporary key data store 222 before capturing card 205 data. The encryption keys may include one or more asymmetric public encryption keys associated with an asymmetric private encryption key generated by a temporary key manager 256 of the exit server instance 252. In an embodiment, to limit the time validity of the encryption keys, the entry server instance 212 receives an updated encryption key periodically, such as hourly, daily, weekly, etc. Thus, when the entry server captures card data of a merchant customer's card 205, such as card data read by a card reader associated with the merchant system(s) 290, the encryption engine 218 encrypts the sensitive card data on intrusion.

[0026] Additionally, upon capture of the card 205 data, a deterministic card ID generator 214 of the ingress server instance 212 generates a universal identifier for the card 205 using less sensitive card data, such as a primary account number (PAN). In an embodiment, the universal identifier, referred to herein as a deterministic card identifier, is generated such that the deterministic identifier does not reveal any card data and such that other entities (e.g., the exit server instance 252, other trusted commerce platform systems (not shown), etc.) can regenerate the deterministic identifier from the less sensitive card data. Additionally, the deterministic identifier, which does not reveal sensitive card data, can be used as an identifier for processes such as risk assessment and tokenization performed by the payment server instance 232, and card vaulting performed by the exit server instance 252, which are described in more detail below.

[0027] In one embodiment, the deterministic card ID generator 214 utilizes a salt selector to select a cryptographic salt from a large table of cryptographic salts (e.g., random data used as additional input in a one-way function such as a destructive hash function) maintained by the deterministic card ID generator 214. The table of cryptographic salts can be pre-generated and included in each of the entry, payment and exit server instances at instantiation / start-up time. The PAN can then be provided as input to a salt selection function, such as a function that randomly distributes the PAN to the table of salts so that a cryptographic salt can be iteratively selected from the table. The deterministic card ID generator 214 then runs a hash function using the PAN of the card's 205 and the selected cryptographic salt, e.g., f hash (PAN,f salt Optionally, the card reader computes f h0→m (PAN,f salt (PAN))=identifier initial Then, the deterministic card ID generator 214 executes a series of initial hashing methods such as f hm→n (identifier initial ), where m and n are predefined integers greater than 0. Although hashing is described above, the deterministic card ID generator 214 can use any one-way function that does not allow recovery of the input (e.g., PAN) from the output of the function. The reader device can also optionally encrypt the card data and / or the deterministic identifier to further obfuscate this data before it enters the trusted entry server instance 212, which the encryption engine 218 can decrypt for uses consistent with the description herein.

[0028] The entrance transaction engine 216 uses the deterministic identifier and the encrypted card data to generate an initial transaction message for the card-based transaction. In one embodiment, the initial transaction message includes a string that includes the deterministic card identifier and other data utilized in the card-based transaction. In one embodiment, this string may include at least the following: <encoding_version> _ <first6> _ <last4>_<deterministic_identifier> _<encrypted_card_data> where first6 represents card data such as a primary industry identifier, issuer identification number, bank identification number, etc., last4 includes verification and other information, the deterministic identifier is generated as described above, and the encrypted data is the secret data encrypted using a temporary encryption key. An extensible object such as TIFF2025013798000002.tif130147 can be used. Additionally, the objects described above are extensible to include any number of card data and / or transaction attributes.

[0029] Attributes such as definitions of card network, issuer, origin region, etc. may include data used during the transaction process (e.g., to determine which authorized network server the exit server instance 252 should forward the transaction to), as well as data for selecting transaction processing optimizations, such as selecting among different exit instances so that the exit instance is in a geographically relevant location, in a location specified by legal constraints, or in proximity to the authorized network server.

[0030] The ingress transaction engine 216 then sends the initial transaction message to the intermediary transaction engine 236 of the payment server instance 232, e.g., using a secure communication protocol (e.g., TLS, SSL, SSH, etc.). In an embodiment, the ingress transaction engine 216 can use the card data and further transaction data described above to select from among the multiple payment server instances, e.g., a payment server instance associated with a prevailing exit server instance, for network communication proximity between the associated payment server instance and the associated prevailing exit server instance, for payment server instances associated with card type, transaction type, bank, etc., for load balancing purposes, as well as other factors that can be used to select a payment server instance.

[0031] In one embodiment, the payment server instance 232 utilizes a risk assessment manager 238 to use the deterministic identifier generated for the card 205 to perform a risk assessment based on transaction factors such as transaction amount, transaction origination location, etc. That is, the risk assessment manager 238 utilizes the deterministic identifier to query its own or other risk assessment systems so as not to inadvertently provide card data outside the payment server instance 232. If the risk assessment manager 238 determines that the transaction can proceed, the token generator 240 generates a token (e.g., a non-sensitive data element that is a replacement identifier for the transaction). The token can then be returned to the ingress server instance, which in turn provides the token to the merchant system(s) 290. Alternatively, the token generator 240 can provide the token to another system of the commerce platform system(s) 295 for communication of the token to the commerce system 290. The token can be used by the commerce platform and merchant system(s) to reference the transaction, for example, when receiving an indication that the transaction has been approved, when receiving payment for a cleared transaction, etc.; tokenizing the transaction is described in more detail in U.S. Patent No. 9,830,596, issued Nov. 28, 2017, entitled "Method for Performing a Transaction Between a Merchant Site and a Customer's Electronic Device Without Exposing Payment Information to a Merchant Site's Server-Side Application," the disclosure of which is incorporated by reference in its entirety. As described herein, tokenizing the transaction and transmitting the card data from the reader to the entry server instance 212 can exempt the merchant system(s) (e.g., POS device, cash register, reward server, commerce app, merchant web-based interface, etc.) from PCI compliance requirements.

[0032] The intermediate transaction engine 236 then forwards the initial transaction message, optionally accompanied by authorization data generated during risk assessment, to the exit transaction engine 258, again utilizing a secure communication protocol. The encryption engine 260 can then access the key data store 262 to find the appropriate key to decrypt the sensitive data in the initial transaction message (e.g., based on the time the transaction occurred, the deterministic ID, the ingress identifier of the ingress server instance that encrypted the card data, etc.). In one embodiment, the card vault engine 264 adds an entry to the card vault data store 266 using the decrypted card data, such as the full card data, the card security code, the name on the card, etc. In an embodiment, each entry in the card vault data store is encrypted, and a deterministic identifier (e.g., generated from the PAN) of the card is used to index / access entries in the encrypted card vault. In an embodiment, the vault is utilized by the exit server instance 252 to store credit card information to facilitate the efficiency of subsequent transactions, such as for card-not-present transactions associated with the card 205.

[0033] In one embodiment, the exit transaction engine 258 further generates a final transaction message to communicate the transaction information to the authorization network server(s) 280 (e.g., an issuing bank and card issuing server). In one embodiment, the final transaction message is a PCI compliant message using the ISO8583 protocol. Once the transaction is authorized / cleared by the authorization network server(s) 280, one or more of the authorization network server(s) 280 can communicate authorization to the commerce platform system(s) 295 to use a token to indicate clearance / final authorization of the transaction, provide rewards to the merchant system(s) 290, etc.

[0034] In an embodiment, the ingress server instance 212, the payment server instance 232, and the exit server instance 252 follow a strict data flow for card-based transactions between a merchant and its customers. The strict data flow separates some operations to each of the ingress server instance 212, the payment server instance 232, and the exit server instance 252. Furthermore, each of the ingress server instance 212, the payment server instance 232, and the exit server instance 252 utilizes transaction messages and deterministic identifiers to perform their respective transaction operations to minimize the use of sensitive card data in an unprotected manner. Additionally, no state data needs to be maintained using the data flow and processing techniques described herein, and therefore each of the ingress server instance 212, the payment server instance 232, and the exit server instance 252 performs transaction processing in a stateless manner. Additionally, strict data flows, such as public network access to ingress server instance 212, payment server instance 232 only receiving communications from ingress server instance 212, egress server instance 252 only receiving communications from payment server instance 232, and egress server instance 252 communicating PCI compliant transaction messages to authorized networks, can implement network controls to prevent unwanted and potentially fraudulent network traffic from entering the servers. This is particularly beneficial for an egress server instance that is well away from the public network and only takes in specific traffic from specific trusted sources (e.g., a payment server instance), greatly enhancing protection of sensitive data in the card vault data store.

[0035] In an embodiment, different distributed execution scenarios of entry server instance 212, payment server instance 232, and exit server instance 252 are illustrated in Figures 2B-2F. In each scenario, the security of sensitive card data is maintained by utilizing the encryption and unique deterministic card identifier techniques and communication flow execution described above. In one embodiment, as illustrated in Figure 2B, entry server instance 212, payment server instance 232, and exit server instance 252 each execute within the same computer system cluster and may be executed by the same or different computer systems within the cluster. In another embodiment, as illustrated in Figure 2C, entry server instance 212, payment server instance 232, and exit server instance 252 each execute within different computer system clusters. In yet another embodiment, entry server instance 212 and payment server instance 232 may execute within the same computer system cluster and exit server instance 252 may execute within a different computer system cluster as illustrated in Figure 2D. In yet another embodiment, the entry instance may execute within a computer system cluster and the exit server instance 252 and payment server instance both execute within different computer system clusters as illustrated in Figure 2E. In yet another embodiment, as shown in FIG. 2F, the entrance server instance 212 and the exit server instance 252 may run in the same computer system cluster, and the payment server instance 232 may run in a different computer system cluster.

[0036] In an embodiment, the different clusters on which the entry server instance 212, the payment server instance 232, and the exit server instance 252 run may be selected based on, for example, geographic proximity to the merchant system(s) 290 and / or the authorization network server(s) 280. For example, as shown in FIG. 2C, cluster i may be selected to run the entry server instance 212 based on the geographic proximity between cluster i and the merchant system(s) 280, while the exit server instance 252 of cluster k may be selected to conduct transactions based on the geographic proximity between cluster k and the authorization network server(s) 280. Other selection techniques, such as authorization network requirements, legal constraints, load balancing, cluster capacity, cluster computational cost, network diagnostics, predicted availability, etc., may also be used to select which computer system cluster(s) to select, which server instance(s) to select per cluster, and how many instances of each server to instantiate. Furthermore, because the technology is utilized to ensure continuous (active) availability of the commerce platform's services, multiple distributed entry server instances, payment server instances and exit server instances may be utilized to simultaneously execute any combination of the scenarios depicted and described in Figures 2B-2F based on the current requirements of the commerce platform and the merchants and / or authentication servers with which it interacts.

[0037] For example, the entry server instance 212 may be executed by a computer system cluster in geographic proximity to the merchant system(s) 290 to improve communication speed between the entry server instance 212 and the merchant system(s) 290, while the exit server instance 252 may be executed by a different computer system cluster in geographic proximity to the authorization network server(s) 280 to improve communication speed between the exit server instance 252 and the authorization network server(s) 280. By distributing multiple entry server instances, payment server instances, and exit server instances, respectively, continuous (active-active) availability for payment processing provided by the commerce platform server(s) may be achieved while maintaining data security and controlled information flow as described in more detail below.

[0038] 3 is a block diagram of an embodiment 300 of processing a card-based transaction using controlled network communication flows by an entry server instance, a payment server instance, and an exit server instance. Method 300 may be performed by processing logic that may include hardware (circuitry, dedicated logic, etc.), software (such as running on a general-purpose computer system or a dedicated machine), firmware, or a combination thereof. In one embodiment, method 300 is performed by entry server, payment server, and exit server instances (e.g., entry server instance 212, payment server instance 232, and exit server instance 252 running on processing nodes of a computer system cluster(s).

[0039] With reference to Figure 3, the processing logic begins by receiving card data at an ingress server for a transaction between a merchant and its customer (processing block 302). In one embodiment, the transaction is a card present transaction in which the card data is collected by a card reader used by the merchant, and the card reader can provide the card data to an ingress server instance. In another embodiment, the transaction can be a card not present transaction in which the merchant system receives card data to be used for the transaction, such as from user input of card data (e.g., card number, expiration date, name on card, card verification value, etc.). Additionally, as described herein, the merchant system (e.g., POS system, commerce app, etc.) can also provide additional data regarding the transaction, such as transaction amount, transaction location, etc., in order to process the transaction.

[0040] Processing logic at the ingress server instance generates a transaction message including a deterministic card identifier and encrypted card data (processing block 304). The deterministic identifier is an identifier generated from less sensitive card data, such as the last four digits of the card used in the transaction, utilizing a destructive one-way function, such as a hash function. Additionally, the sensitive card data is encrypted by processing logic at the ingress server instance upon receipt, such that the sensitive data is not maintained in unencrypted form at the ingress server instance. In an embodiment, an ephemeral public key from an asymmetric encryption key pair is used by the processing logic to encrypt the sensitive card data. The asymmetric encryption key pair is periodically generated by the exit server instance and provided to the ingress server instance, for example, upon startup of the ingress server instance, in periodic messaging, etc.

[0041] Processing logic at the ingress server instance provides the transaction message to the payment server instance (processing block 306). In an embodiment, a secure communication protocol may be used to communicate the message from the ingress server instance to the payment server instance. Furthermore, the payment server instance only accepts communications for transactions from the ingress server instance, and not from systems on a public network (e.g., a merchant system), for example.

[0042] Processing logic at the payment server instance authorizes the transaction using the deterministic card identifier (processing block 308). This authorization may include utilizing the deterministic identifier to query a risk management system based on factors associated with the transaction including amount, location, etc. Once authorization is successful, the transaction may be tokenized (processing block 310) and processing logic at the payment server instance provides the transaction message and authorization data from the risk assessment to the exit server instance (processing block 312). Again, a secure communication protocol may be used for messaging from the payment server instance to the exit server instance. Additionally, the exit server instance only receives communications for the transaction from the ingress server instance and not, for example, from systems on a public network (e.g., a merchant system) or from the ingress server. Rather, strict communication flows may be enforced by the processing logic to keep the exit server instance, and data maintained at the exit server instance, away from the public network.

[0043] Processing logic at the exit server instance decrypts the encrypted card data and appends a final transaction message (processing block 314). In an embodiment, processing logic selects one of a plurality of temporary secret keys based on one or more of the following: transaction time, identity of the entry server instance, transaction type, etc. In one embodiment, the final transaction message is a PCI compliant message, such as an ISO8583 message for communication with an authorized network server.

[0044] The processing logic of the exit server instance then communicates a final transaction message to an authorization network server (e.g., a bank server, a card issuing server, etc.) to complete the transaction between the merchant and the customer (processing block 316). In an embodiment, the authorization network server performs operations such as checking account balances, credit limits, etc. as part of completing the transaction. Once complete, the commerce platform system notifies the merchant that final approval for the transaction has been obtained, e.g., by referencing the token for the transaction.

[0045] 4 is one embodiment of a process 400 performed by an ingress server instance of a commerce platform for card-based transactions. Method 400 may be performed by processing logic that may include hardware (circuitry, dedicated logic, etc.), software (such as running on a general-purpose computer system or dedicated machine), firmware, or a combination thereof. In one embodiment, method 400 is performed by an instance of an ingress server (e.g., ingress server instance 212 running on a processing node of a computer system cluster).

[0046] 4, processing logic begins by periodically receiving a temporary encryption key (processing block 402). In an embodiment, this key is an asymmetric public encryption key, with the respective private keys maintained at one or more exit server instances. Additionally, new temporary encryption keys may be received hourly, daily, weekly, at startup, etc. Additionally, these keys may be specific to each entry server instance, to the region of the entry server, to a computer system cluster and the entry server instances running thereon, etc.

[0047] Processing logic receives card data from a card for use in a card-based transaction between a merchant and its customer (processing block 404). As described herein, the card data may be received during a card-present transaction (e.g., the card data may be received from a card reader associated with the commerce platform and used by the merchant to collect the customer's card data during the transaction) or during a card-not-present transaction (e.g., the card data for use during the transaction is collected and / or received from the customer without the merchant or its representative inspecting the customer's payment card).

[0048] Processing logic generates a deterministic card identifier using the card data (processing block 406). As described above, the deterministic card identifier may be generated using a destructive hash function, a set of hash functions, a set of hash functions distributed between the card reader and the entry server instance, encryption, etc., utilizing the card's PAN and a cryptographic salt selection as input to the function. The PAN is not sensitive card data and therefore may be used by other entities, such as an exit server instance, to generate a deterministic identifier for the card used in a transaction.

[0049] After the deterministic card identifier is generated, the sensitive card data is encrypted using a selected temporary encryption key, processing block 408. The key may be selected based on attributes associated with the transaction (e.g., card type, card issuer), key validity period, ingress region, ingress server instance identifier, etc.

[0050] Next, processing logic generates and provides an initial transaction message including at least the encrypted card data and the deterministic card identifier to the payment server instance (processing block 410). In one embodiment, the message may be transmitted using a secure communication protocol, encrypted, or otherwise protected. Additionally, processing logic at the ingress server instance sends the transaction message only to the payment server instance as a control over communication flow and delivery of the (albeit obfuscated / encrypted) sensitive card data. Additionally, in an embodiment, processing logic may select a particular payment server instance based on transaction attributes, geographic attributes for initiation of the transaction, geographic attributes for an authorizing server completing the transaction, legal requirements, etc.

[0051] 5 is one embodiment of a process 500 performed by a payment server of a commerce platform for card-based transactions. Method 500 may be performed by processing logic, which may include hardware (circuitry, dedicated logic, etc.), software (such as executed on a general-purpose computer system or dedicated machine), firmware, or a combination thereof. In one embodiment, method 500 is performed by an instance of a payment server (e.g., a payment server instance 232 executing on a processing node of a computer system cluster).

[0052] 5, processing logic begins by receiving a transaction message from an ingress server that includes at least encrypted card data and a deterministic card identifier associated with the encrypted card data for a card-based transaction between a merchant and its customer (processing block 502). The message can include additional data such as originating region of the transaction, issuing bank, card type, card brand, and attributes of the transaction such as amount.

[0053] Next, processing logic performs a risk assessment using the deterministic card identifier (processing block 504). As described herein, the risk assessment system analyzes the transaction data using the deterministic card identifier to detect fraud before allowing the transaction. If the risk assessment does not detect fraud, processing logic further generates a limited-use token for the transaction (processing block 506), which in embodiments is provided to the merchant from the payment server instance (processing block 508). As described herein, this token is used by the commerce platform and merchant system(s) as a reference to the transaction without necessarily including card data, allowing the merchant to track the transaction, receive rewards, operate a rewards system, etc., without triggering PCI compliance regulations.

[0054] Processing logic at the payment server instance then determines an exit server instance to forward the transaction message for the authorized transaction (processing block 512) and forwards the transaction message to the selected exit server instance. In embodiments, factors such as geography of the authorizing network server(s), geography of the card issuer / bank, etc. may be used in selecting among multiple different exit server instances to complete the transaction between the merchant and the customer. These selections may be based on legal requirements (e.g., egress occurs in a geographic region designated for the transaction and / or card), reduced latency (e.g., egress occurs by a computer system cluster in close proximity to the authorizing server), or any other selection criteria. Additionally, processing logic at the payment server instance communicates transaction messages only to exit servers, again enforcing strict communication flows to improve communication security.

[0055] 6 is one embodiment of a process 600 performed by an exit server instance of a commerce platform for card-based transactions. Method 600 may be performed by processing logic that may include hardware (circuitry, dedicated logic, etc.), software (such as running on a general-purpose computer system or dedicated machine), firmware, or a combination thereof. In one embodiment, method 600 is performed by an instance of an exit server (e.g., exit server instance 252 running on a processing node of a computer system cluster).

[0056] 6, processing logic begins by receiving a transaction message from a payment server instance that includes at least encrypted card data and a deterministic card identifier associated with the encrypted card data for a card-based transaction between a merchant and its customer (processing block 602). As described herein, the transaction message may include card and transaction metadata such as card type, issuer, transaction amount, origination region, risk assessment authorization, and entry server instance identifier.

[0057] In an embodiment, processing logic utilizes data in the transaction message to access an encryption key data store for encryption key selection (processing block 604). For example, a particular key may be distributed to a particular ingress server instance, and thus an ingress server instance identifier may be used to select an appropriate asymmetric private key for decrypting the encrypted content in the received transaction message. Similarly, timing data in the transaction message may be used to determine a key validity period for selecting an appropriate asymmetric private key for decrypting the encrypted content in the received transaction message. Other factors for selecting an appropriate decryption key may also be implemented that are not inconsistent with the description herein.

[0058] Processing logic commits the card data in encrypted form to a card vault data store, where the committed card data is associated with the deterministic card identifier (processing block 608). In an embodiment, the card data is maintained by the exit server instance in a secure / encrypted form and is accessible via the associated deterministic card identifier. Retaining the card data may improve the efficiency of subsequent transactions, such as subsequent different types of (e.g., card not present) transactions.

[0059] Next, processing logic generates and transmits a financial transaction card originated exchange message containing the card data (processing block 610). In one embodiment, this message is a PCI compliant ISO 8583 message or other PCI compliant message for communication with the authorized network server(s). In an embodiment, the exit server instance receives transaction communications only from the payment server instance and transmits transaction messages only to the authorized server(s), as described herein. Thus, again using the techniques described herein, the flow of transaction messages is limited and tightly controlled. Furthermore, because public network communication by the exit server is not expected and / or authorized, sensitive data is protected from access by devices on the public network.

[0060] 7 is one embodiment of a deterministic card identifier generation process by a commerce platform for use during card-based and other transactions. Method 700 may be performed by processing logic, which may include hardware (circuitry, dedicated logic, etc.), software (such as running on a general-purpose computer system or dedicated machine), firmware, or a combination thereof. In one embodiment, method 700 is performed by an instance of an ingress server (e.g., ingress server instance 212 running on a processing node of a computer system cluster). However, other systems, such as an egress server, or other systems of a commerce platform, may also generate deterministic card identifiers as described herein.

[0061] 7, processing logic begins by selecting a cryptographic salt from a set of cryptographic salts based on a primary account number (PAN) from card data (processing block 702). In embodiments, card data including the PAN may be collected during a card-present or card-not-present transaction. Further, as described herein, cryptographic salts are random data sets that are used as additional data in performing a one-way function, such as a destructive hash function. In one embodiment, the PAN is used to select among the available salts.

[0062] Processing logic executes at least one hash function using the PAN and the selected cryptographic salt as inputs (processing block 704). In one embodiment, one or more hash functions are performed using a hash function and a salt selection function as described herein to generate a deterministic identifier (processing block 704). hash (PAN,f salt In another embodiment, the processing logic may perform f recursive hash operations using the hash function and the salt selection function. h0→i (PAN,f salt In yet another embodiment, a recursive hashing technique can be used to perform a personal authentication (PAN) process. h0→m (PAN,f salt (PAN))=identifier initial Then, the processing logic performs a series of initial hashing such as f hm→n (identifier initial ), where m and n are predefined integers greater than 0. Although hashing is described above, the processing logic may use any one-way function that does not allow recovery of the input (e.g., the PAN) from the output of the function. In embodiments, encryption may be used in addition to hashing, including the reader encrypting the card data and / or the distributed deterministic identifier to further obfuscate this data until it enters a trusted environment (e.g., an entry server instance).

[0063] 8 illustrates one embodiment of a computer system that can be used to support the systems and operations described herein, although it will be apparent to one skilled in the art that other alternative systems of various system architectures may also be used.

[0064] The data processing system shown in Figure 8 includes a bus or other internal communication means 815 for communicating information, and a processor 810 coupled to the bus 815 for processing information. The system further includes a random access memory (RAM) or other volatile storage device (referred to as memory) 850 coupled to the bus 815 for storing information and instructions to be executed by the processor 810. The main memory 850 may also be used to store temporary variables or other intermediate information during execution of instructions by the processor 810. The system further includes a read only memory (ROM) and / or static storage device 820 coupled to the bus 815 for storing static information and instructions for the processor 810, and a data storage device 825, such as a magnetic or optical disk and its corresponding disk drive. The data storage device 825 is coupled to the bus 815 for storing information and instructions.

[0065] The system may further be coupled to a display device 870, such as a light emitting diode (LED) display or liquid crystal display (LCD), coupled to bus 815 through bus 865 for displaying information to a computer user. An alphanumeric input device 875, including alphanumeric and other keys, may also be coupled to bus 815 through bus 865 for communicating information and command selections to processor 810. An additional user input device is a cursor control device 880, such as a touch pad, mouse, trackball, stylus, or cursor direction keys, coupled to bus 815 through bus 865 for communicating directional information and command selections to processor 810 to control cursor movement on display device 870.

[0066] Another device that may optionally be coupled to computer system 800 is a communications device 890 for accessing other nodes of a distributed system over a network. Communications device 890 may include any of a number of commercially available network peripherals, such as those used to couple to Ethernet, Token Ring, the Internet, or wide area networks. Additionally, communications device 890 may be a null modem connection or any other mechanism that provides connectivity between computer system 800 and the outside world. It should be noted that any or all of the components of this system shown in FIG. 8 and associated hardware may be used in various embodiments as described herein.

[0067] It will be apparent to those skilled in the art that the systems, methods and processes described herein may be implemented as software stored in a main memory or a read-only memory and executed by a processor. This control logic or software may also reside on an article of manufacture that includes a non-transitory computer readable medium that embodies computer readable program code readable by a mass storage device that causes a processor to operate according to the methods and teachings herein.

[0068] The embodiments described herein may also be embodied in a handheld or portable device that includes a subset of the computer hardware components described above. For example, a handheld device may be a mobile phone, a tablet computer, a dedicated computing device, etc., configured to include only a bus, a processor, and memory. A handheld device may also be configured to include a set of buttons or input signaling components that allow a user to select from a set of available options. A handheld device may be configured to include an output device, such as a liquid crystal display (LCD) or a matrix of display elements that displays information to a user of the handheld device. Such handheld devices may be implemented using conventional methods. The implementation of embodiments of such devices will be apparent to one of ordinary skill in the art given the disclosure as provided herein.

[0069] The embodiments described herein may also be embodied in a special purpose device that includes a subset of the computer hardware components described above. For example, the device may include only a processor, data storage, a bus and memory, and a basic communication mechanism such as a small touch screen that allows a user to communicate in a basic way with the device. In general, the more specialized the purpose of the device, the fewer elements that need to be present for the device to function.

[0070] 9 is a block diagram of one embodiment of a reader device. The reader device 900 provides further details of the reader devices described herein (e.g., reader device 115). Examples of reader devices 900 include Verifone™ PIN pad devices such as the VX820, P400, P200, and other PIN pad reader devices offered by Verifone and other manufacturers of such devices. Further reader device examples 900 include mobile reader devices such as the BBPOS™ Chipper™, and mobile reader devices offered by BBPOS™ and other manufacturers of such devices.

[0071] In one embodiment, the reader device 900 is a system that may include a combination of one or more processors 904, memory 906, a network interface 908, and a card reader(s) 902 (e.g., magnetic stripe reader, chip reader, etc.). The reader device 900 may also include multiple processing modules that may be implemented as hardware, software, firmware, or a combination thereof. Although not shown, it should be understood that the reader device 900 may also include a user interface (e.g., keyboard, touch screen, buttons, or similar user input device), a power supply (e.g., battery), and other components typically associated with electronic devices. Additionally, the reader device's network interface 908 may be coupled to multiple wireless subsystems (e.g., Bluetooth, Wi-Fi, Cellular, or other networks) for transmitting and receiving data streams over a wireless link to and from the network, or may be a wired interface that connects directly to a network (e.g., Internet, Ethernet, or other wireless system).

[0072] The memory 906 may be coupled to the processor(s) 904 of the reader device to store instructions executed by the processor(s). In some embodiments, the memory is non-transitory. It should be understood that the embodiments as described herein may be implemented, for example, through execution by the processor(s) of the reader device and / or other circuitry of the reader device of instructions stored in the memory or other elements. In particular, the circuitry of the reader device, including but not limited to the processor and the card reader, may operate under control of a program, routine, or instruction execution to perform a method or process according to the embodiments described herein. For example, such a program may be implemented in firmware or software (e.g., stored in memory and / or elsewhere) and may be implemented by the processor, such as the processor and the card reader, and / or other circuitry of the reader device. Furthermore, it should be understood that terms such as processor, microprocessor, circuit, controller, etc. may refer to any type of logic or circuitry capable of executing logic, commands, instructions, software, firmware, functions, etc.

[0073] Those skilled in the art will appreciate that any configuration of the system may be used for a variety of purposes depending on the particular implementation. The control logic or software implementing the described embodiments may be stored in main memory, mass storage device, or other storage medium accessible locally or remotely by a processor.

[0074] It should be understood that the above description is illustrative and not restrictive. Many other embodiments will become apparent to those skilled in the art upon reading and understanding the above description. The scope should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

[0075] The foregoing description has been given with reference to specific embodiments for purposes of illustration. However, the illustrative discussion above is not intended to be exhaustive or to limit the described embodiments to the precise forms disclosed. Many modifications and variations are possible in light of the above teachings. The embodiments have been selected and described in order to best explain the principles of the various embodiments and their practical application, thereby enabling others skilled in the art to best utilize the various embodiments with various modifications suited to the particular use envisaged. [Explanation of symbols]

[0076] 100 Systems 102 Network 110 Payment Cards 115 Reader device 120 (single or multiple) Merchant POS Devices 130 Commerce Platform Server(s) 140 Merchant Server(s) 150 Authorized Network Servers < / first6>

Claims

1. 1. A method of processing a transaction between a merchant and its customers, comprising: generating an initial transaction message at an entry server by generating a deterministic identifier of the card to be used in the transaction from card data received for the transaction and encrypting the received card data; providing the initial transaction message from the entry server to a payment server; updating, by the payment server, the initial transaction message with authorization data in response to authorization of the transaction determined at least in part based on the deterministic identifier of the card; providing the updated initial transaction message from the payment server to an exit server; the exit server decrypting the encrypted card data and appending a final transaction message; communicating the final transaction message to an authentication system for processing the transaction between the merchant and the customer based on the card data; The method according to claim 1, further comprising:

2. the card data is obtained from the customer for the transaction between the merchant and the customer, and the card data is not exposed in unencrypted form to the payment server; The method of claim 1.

3. The step of generating the deterministic identifier for the card comprises: said entry server selecting an encryption salt from a set of encryption salts based on said card data; the entry server performing at least one hash function on the selected cryptographic salt and the card data to obtain the deterministic identifier; The method of claim 1 , comprising:

4. The step of encrypting the received card data comprises: said entry server selecting a public key from a set of public-private key pairs provided to said entry server based on said deterministic identifier; the portal system encrypting the card data using the selected public key; The method of claim 1 further comprising:

5. The step of decrypting the encrypted card data includes: the exit server selecting a private key associated with a selectable public key from the set of public-private key pairs based on the deterministic identifier of the card from the initial transaction message; the exit system decrypting the encrypted card data for inclusion in the final transaction message; The method of claim 4 further comprising:

6. the set of public-private key pairs is temporary and is periodically replaced with a new set of public-private key pairs; The method according to claim 4.

7. the entry server is an instance of an entry server running on a computer system cluster, the payment server is an instance of a payment server running on a computer system cluster, and the exit server is an instance of an exit server running on a computer system cluster; The method of claim 1.

8. the entry server is an instance of an entry server executing on a first computer system cluster, the payment server is an instance of a payment server executing on a second computer system cluster, and the exit server is an instance of an exit server executing on a third computer system cluster, and the first, second and third computer system clusters are geographically distributed. The method of claim 1.

9. the first computer system cluster being geographically proximate to a server computer system of the distributor, and the third computer system cluster being geographically proximate to a server computer system of the authorization system; The method according to claim 8.

10. the payment server instance selecting the instance of the exit server for receiving the updated initial transaction message based on the geographic proximity between the third computer system cluster and the server computer system of the authorization system.

10. The method of claim 9.

11. the transaction is a card present transaction; The method of claim 1.

12. the card is a chip card and the card data is captured from an integrated circuit of the card by a card reader of the merchant's personal identification number (PIN) pad device; The method of claim 11.

13. communications exchanged between the entry server and the payment server, and between the payment server and the exit server, are protected using encrypted communications links; The method of claim 1.

14. A non-transitory computer-readable storage medium containing instructions that, when executed by a processor, cause the processor to perform operations to process transactions between a merchant and its customers, the operations including: generating, at an entry server, a deterministic identifier for a card to be used in the transaction from card data received for the transaction and encrypting the received card data, thereby generating an initial transaction message; providing the initial transaction message from the entry server to a payment server; updating, by the payment server, the initial transaction message with authorization data in response to authorization of the transaction determined at least in part based on the deterministic identifier of the card; providing the updated initial transaction message from the payment server to an exit server; the exit server decrypting the encrypted card data and appending a final transaction message; communicating the final transaction message to an authentication system for processing the transaction between the merchant and the customer based on the card data; A non-transitory computer-readable storage medium comprising:

15. the card data is obtained from the customer for the transaction between the merchant and the customer, and the card data is not exposed in unencrypted form to the payment server; 15. The non-transitory computer-readable storage medium of claim 14.

16. The step of generating the deterministic identifier for the card comprises: the entrance server selecting an encryption salt from a set of encryption salts based on the card data; the entry server performs at least one hash function on the selected cryptographic salt and the card data to obtain the deterministic identifier; 15. The non-transitory computer-readable storage medium of claim 14, further comprising operations for:

17. The step of encrypting the received card data comprises: the entry server selecting a public key from a set of public-private key pairs provided to the entry server based on the deterministic identifier; the entrance system encrypts the card data using the selected public key; The non-transitory computer-readable storage medium of claim 1 , further comprising operations for:

18. The step of decrypting the encrypted card data includes: the exit server selecting a private key associated with a selectable public key from the set of public-private key pairs based on the deterministic identifier of the card from the initial transaction message; the exit system decrypts the encrypted card data for inclusion in the final transaction message; 20. The non-transitory computer-readable storage medium of claim 17, further comprising operations for:

19. the set of public-private key pairs is temporary and is periodically replaced with a new set of public-private key pairs; 20. The non-transitory computer-readable storage medium of claim 17.

20. the entry server is an instance of an entry server running on a computer system cluster, the payment server is an instance of a payment server running on a computer system cluster, and the exit server is an instance of an exit server running on a computer system cluster; 15. The non-transitory computer-readable storage medium of claim 14.

21. the entry server is an instance of an entry server executing on a first computer system cluster, the payment server is an instance of a payment server executing on a second computer system cluster, and the exit server is an instance of an exit server executing on a third computer system cluster, and the first, second and third computer system clusters are geographically distributed.

15. The non-transitory computer-readable storage medium of claim 14.

22. the first computer system cluster being geographically proximate to a server computer system of the distributor, and the third computer system cluster being geographically proximate to a server computer system of the authorization system; 22. The non-transitory computer-readable storage medium of claim 21.

23. and an operation for the payment server instance to select the instance of the exit server for receiving the updated initial transaction message based on the geographic proximity between the third computer system cluster and the server computer system of the authorization system.

23. The non-transitory computer readable storage medium of claim 22.

24. the transaction is a card present transaction; 15. The non-transitory computer-readable storage medium of claim 14.

25. the card is a chip card and the card data is captured from an integrated circuit of the card by a card reader of the merchant's personal identification number (PIN) pad device; 25. The non-transitory computer-readable storage medium of claim 24.

26. communications exchanged between the entry server and the payment server, and between the payment server and the exit server, are protected using encrypted communications links; 15. The non-transitory computer-readable storage medium of claim 14.

27. a first computer system cluster configured to execute an entry server to generate an initial transaction message by generating a deterministic identifier for a card to be used in the transaction from card data received for the transaction and encrypting the received card data, and to transmit the initial transaction message from the entry server; a second computer system cluster configured to execute the payment server to receive the initial transaction message from the entrance server, update the initial transaction message with authorization data in response to authorization of the transaction determined at least in part based on the deterministic identifier of the card, and transmit the updated initial transaction message from the payment server; a third computer system cluster configured to execute an exit server to receive the updated initial transaction message from the payment server, decrypt the encrypted card data to append a final transaction message, and communicate the final transaction message to an authentication system for processing the transaction between the merchant and the customer based on the card data; A system comprising:

28. the first, second and third computer system clusters are part of a same computer system cluster; 28. The system of claim 27.

29. the first, second and third computer system clusters are different computer system clusters.

28. The system of claim 27.

30. the first computer system cluster being geographically proximate to a server computer system of the merchant and the third computer system cluster being geographically proximate to a server computer system of the authorization system, the system further comprising the second computer system cluster configured to execute the payment server to select the exit server in the third computer system for receiving the updated initial transaction message based on geographic proximity between the third computer system cluster and the server computer system of the authorization system.

30. The system of claim 29.

Images