Claims:CLAIMS
We claim:

1. A computer-implemented method, comprising:
accessing, by a server system, information of a plurality of authorization entities sharing a communication channel on a payment interface processor (PIP), the plurality of authorization entities associated with a data processing system;
generating, by the server system, a set of cryptographic keys corresponding to each authorization entity based, at least in part, on an entity identifier associated with each authorization entity and a communication channel identifier associated with the communication channel;
storing, by the server system, the set of cryptographic keys corresponding to each authorization entity indexed based, at least in part, on the entity identifier and the communication channel identifier in a database, the set of cryptographic keys of each authorization entity identified based, at least in part, on the entity identifier and the communication channel identifier; and
transmitting, by the server system, a data block to the data processing system through the payment interface processor, the data block comprising the set of cryptographic keys corresponding to each authorization entity and the communication channel identifier.

2. The computer-implemented method as claimed in claim 1, wherein the set of cryptographic keys corresponding to each authorization entity comprises master cryptographic key, and PIN encryption key (PEK).

3. The computer-implemented method as claimed in claim 1, further comprising:
sending, by the server system, a cryptographic operation command for generating a master cryptographic key corresponding to each authorization entity and the communication channel, to a Hardware Security Module (HSM) communicatively connected to the server system;
receiving, by the server system, the master cryptographic key corresponding to each authorization entity and the communication channel identifier; and
transmitting, by the server system, the master cryptographic key corresponding to each authorization entity and the communication channel identifier to the data processing system.

4. The computer-implemented method as claimed in claim 1, further comprising:
sending, by the server system, an operation command for generating the PIN encryption key (PEK) corresponding to each authorization entity and the communication channel to HSM;
encrypting, by the server system, the PEK of each authorization entity using the respective master cryptographic key of each authorization entity;
transmitting, by the server system, a data block to the data processing system, the data block comprising a unique data field indicating a key exchange message for the plurality of authorization entities and the encrypted PEK associated with each authorization entity.

5. The computer-implemented method as claimed in claim 1, further comprising:
receiving, by the server system, a payment transaction request from an acquiring processing system associated with an acquirer via a first communication channel on an acquiring PIP, the payment transaction request comprising PIN encrypted under acquiring PEK key corresponding to the acquirer and the first communication channel, and first entity identifier associated with the acquirer;
fetching, by the server system, the acquiring PEK key based, at least in part, on the first entity identifier and a first communication channel identifier of the first communication channel from the database;
identifying, by the server system, a second entity identifier and a second communication channel on an issuing PIP associated with an issuer based, at least in part, on Bank identification number (BIN) comprised in the payment transaction request; and
fetching, by the server system, an issuing PEK key associated with issuer based, at least in part, on the second entity identifier and a second communication channel identifier of second communication channel from the database.

6. The computer-implemented method as claimed in claim 5, further comprising:
transmitting, by the server system, a PIN translation command to a Hardware Security Module (HSM) communicatively connected to the server system, the PIN translation command comprising the acquiring PEK key and the issuing PEK key;
receiving, by the server system, the PIN encrypted with the issuing PEK key from the HSM, the HSM configured to decrypt the PIN using the acquiring PEK key and encrypt the PIN using the issuing PEK key; and
transmitting, by the server system, a payment authorization request to an issuing processing system via the second communication channel on the issuing PIP, the payment authorization request comprising the PIN encrypted with the issuing PEK key and the second entity identifier associated with the issuer.

7. The computer-implemented method as claimed in claim 1, wherein a first set of cryptographic keys associated with a first authorization entity is different from a second set of cryptographic keys associated with a second authorization entity, and wherein the first authorization entity and the second authorization entity communicate over a single communication channel on the payment interface processor.

8. The computer-implemented method as claimed in claim 1, wherein the server system is a payment server associated with a payment network.

9. The computer-implemented method as claimed in claim 1, wherein the communication channel between the server system and the data processing system is established via the payment interface processor.

10. A server system, comprising:
a communication interface;
a memory comprising executable instructions; and
a processor communicably coupled to the communication interface and the memory, the processor configured to cause the server system to perform at least in part to:
access information of a plurality of authorization entities sharing a communication channel on a payment interface processor, the plurality of authorization entities associated with a data processing system;
generate a set of cryptographic keys corresponding to each authorization entity based, at least in part, on an entity identifier associated with each authorization entity and a communication channel identifier associated with the communication channel;
store the set of cryptographic keys corresponding to each authorization entity indexed based, at least in part, on the entity identifier and the communication channel identifier in a database, the set of cryptographic keys of each authorization entity identified based, at least in part, on the entity identifier and the communication channel identifier; and
transmit a data block to the data processing system through the payment interface processor, the data block comprising the set of cryptographic keys corresponding to each authorization entity and the communication channel identifier.
, Description:
FORM 2
THE PATENTS ACT 1970
(39 of 1970)
&
The Patent Rules 2003
COMPLETE SPECIFICATION
(refer section 10 & rule 13)

1. TITLE OF THE INVENTION:
METHODS AND SYSTEMS FOR PROVIDING SECURED ACCESS OF SHARED PORTS ON PAYMENT INTERFACE PROCESSOR TO ENTITIES

2. APPLICANT(S):

(a) Name:

(b) Nationality:

(c) Address:

MASTERCARD INTERNATIONAL INCORPORATED

United States of America

2000 Purchase Street, Purchase, NY 10577, United States of America

3. PREAMBLE TO THE DESCRIPTION

The following specification particularly describes the invention and the manner in which it is to be performed.

4. DESCRIPTION
(See next page)

METHODS AND SYSTEMS FOR PROVIDING SECURED ACCESS OF SHARED PORTS ON PAYMENT INTERFACE PROCESSOR TO ENTITIES

TECHNICAL FIELD
[0001] The present disclosure generally relates to cryptographic services and, more particularly to, methods and systems for allocating unique cryptographic keys for multiple authorization entities sharing a communication port or channel on payment interface processor.

BACKGROUND
[0002] Data is usually protected before any data exchange for increasing the security of data. Conventionally, there exist third party entities residing between a sender and receiver during data exchange. Since the third-party entities may interact with the data in between, data is encrypted for protection from malicious users. Data is encrypted/decrypted using cryptographic keys so that a malicious user may not intercept the data and commit fraud. For secured data exchange between an acquirer server and an issuer server in payment technology a payment interface processor (PIP) is required to be installed at the acquirer server and the issuer server for facilitating secure connection with the payment network.
[0003] The PIP, in general, has a port limitation that allows one PIP to support only a certain number of ports, for example 80 ports. As a result, only 80 authorization entities may be able to access one PIP from one domain controller. Generally, the domain controller is a server that responds to security authentication requests. Thus, there arises a need to purchase additional PIPs in order to support more entities. However, using separate PIP ports for individual entities is not operationally feasible, as it increases operational overhead. Additionally, for onboarding a new entity on the payment network, there is a requirement of a lot of changes at the PIP.
[0004] To overcome this limitation, the PIP provides capability of single sign-on functionality. With this functionality, various entities may use a shared communication port on the PIP. To implement the shared communication port on the PIP, entities need to share same set of cryptographic keys (such as key encryption key, PIN key encryption key, MAC integrity key, and so on). However, sharing the same set of cryptographic keys for multiple entities is a security violation in some countries.
[0005] Thus, there exists a technological need to overcome the above-stated limitations.

SUMMARY
[0006] Various embodiments of the present disclosure provide systems and methods for allocating unique cryptographic keys for multiple authorization entities sharing a communication port or channel on payment interface processor.
[0007] In an embodiment, a computer-implemented method is disclosed. The method includes accessing, by a server system, information of a plurality of authorization entities sharing a communication channel on a payment interface processor (PIP). The plurality of authorization entities is associated with a data processing system. The method includes generating, by the server system, a set of cryptographic keys corresponding to each authorization entity based, at least in part, on an entity identifier associated with each authorization entity and a communication channel identifier associated with the communication channel. The method includes storing, by the server system, the set of cryptographic keys corresponding to each authorization entity indexed based, at least in part, on the entity identifier and the communication channel identifier in a database. The set of cryptographic keys of each authorization entity is identified based, at least in part, on the entity identifier and the communication channel identifier. The method includes transmitting, by the server system, a data block to the data processing system through the PIP. The data block includes the set of cryptographic keys corresponding to each authorization entity and the communication channel identifier.
[0008] In another embodiment, a server system is disclosed. The server system includes a communication interface and a memory including executable instructions. The server system further includes a processor communicably coupled to the communication interface and the memory. The processor is configured to cause the server system to perform at least in part to access information of a plurality of authorization entities sharing a communication channel on a payment interface processor. The plurality of authorization entities is associated with a data processing system. The server system is further caused to generate a set of cryptographic keys corresponding to each authorization entity based, at least in part, on an entity identifier associated with each authorization entity and a communication channel identifier associated with the communication channel and store the set of cryptographic keys corresponding to each authorization entity indexed based, at least in part, on the entity identifier and the communication channel identifier in a database. The set of cryptographic keys of each authorization entity is identified based, at least in part, on the entity identifier and the communication channel identifier. The server system is further caused to transmit a data block to the data processing system through the payment interface processor. The data block includes the set of cryptographic keys corresponding to each authorization entity and the communication channel identifier.
[0009] Other aspects and example embodiments are provided in the drawings and the detailed description that follows.

BRIEF DESCRIPTION OF THE FIGURES
[0010] For a more complete understanding of example embodiments of the present technology, reference is now made to the following descriptions taken in connection with the accompanying drawings in which:
[0011] FIG. 1 illustrates an example representation of an environment related to at least some example embodiments of the present disclosure;
[0012] FIGS. 2A, 2B, and 2C, collectively, represent a sequence flow diagram of cryptographic key exchange process, in accordance with an embodiment of the present disclosure;
[0013] FIGS. 3A, 3B, and 3C, collectively, represent a sequence flow diagram of payment authorization process, in accordance with an embodiment of the present disclosure;
[0014] FIG. 4 illustrates a flow diagram depicting a method for allocating cryptographic keys to a plurality of authorization entities, in accordance with an embodiment of the present disclosure;
[0015] FIG. 5 illustrates a flow diagram depicting a method for performing payment authorization process, in accordance with an embodiment of the present disclosure;
[0016] FIG. 6 is a simplified block diagram of an issuer server, in accordance with an embodiment of the present disclosure;
[0017] FIG. 7 is a simplified block diagram of an acquirer server, in accordance with an embodiment of the present disclosure;
[0018] FIG. 8 is a simplified block diagram of a payment server, in accordance with an embodiment of the present disclosure; and
[0019] FIG. 9 is a simplified block diagram of a server system, in accordance with an embodiment of the present disclosure.
[0020] The drawings referred to in this description are not to be understood as being drawn to scale except if specifically noted, and such drawings are only exemplary in nature.

DETAILED DESCRIPTION
[0021] In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present disclosure. It will be apparent, however, to one skilled in the art that the present disclosure can be practiced without these specific details.
[0022] Reference in this specification to “one embodiment” or “an embodiment” means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of the phrase “in an embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.
[0023] Moreover, although the following description contains many specifics for the purposes of illustration, anyone skilled in the art will appreciate that many variations and/or alterations to said details are within the scope of the present disclosure. Similarly, although many of the features of the present disclosure are described in terms of each other, or in conjunction with each other, one skilled in the art will appreciate that many of these features can be provided independently of other features. Accordingly, this description of the present disclosure is set forth without any loss of generality to, and without imposing limitations upon, the present disclosure.
[0024] The term "payment account" used throughout the description refers to a financial account that is used to fund the financial transaction (interchangeably referred to as "payment transaction"). Examples of the payment account include, but are not limited to a savings account, a credit account, a checking account and a virtual payment account. The payment account may be associated with an entity such as an individual person, a family, a commercial entity, a company, a corporation, a governmental entity, a non-profit organization and the like. In some scenarios, a payment account may be a virtual or temporary payment account that can be mapped or linked to a primary payment account, such as those accounts managed by wallet service providers and the like.
[0025] The term "payment network", used throughout the description, refers to a network or collection of systems used for transfer of funds through use of cash-substitutes. Payment networks may use a variety of different protocols and procedures in order to process the transfer of money for various types of transactions. Transactions that may be performed via a payment network may include product or service purchases, credit purchases, debit transactions, fund transfers, account withdrawals, etc. Payment networks may be configured to perform transactions via cash-substitutes, which may include payment cards, letters of credit, checks, financial accounts, etc. Examples of networks or systems configured to perform as payment networks include those operated by Mastercard® etc.
OVERVIEW
[0026] Various example embodiments of the present disclosure provide systems and methods for allocating cryptographic keys to various authorization entities for communicating messages via a shared communication channel on a payment interface processor to overcome limitations of the existing systems and to provide additional advantages. More specifically, techniques disclosed herein enable cryptographic key message exchange between the various authorization entities. The various authorization entities may include acquirers or issuers. In general, cryptographic operations are performed with facilitation of a hardware security module (HSM). The HSM may be installed at a data processing system. In addition, HSM is a physical computing device responsible for performing cryptographic operations such as safeguard and management of digital keys, performing encryption/decryption for digital signatures, authentication and other cryptographic functions. In addition, a payment interface processor (PIP) is installed at the various entities to perform easier integration. The data processing system is a data processing center that is configured to handle a plurality of cryptographic operations for the various authorization entities. In one example, a PIP is installed at an acquiring processing system associated with the acquirer and another PIP is installed at an issuing processing system associated with the issuer.
[0027] The present disclosure describes a server system that is configured to access information of a plurality of authorization entities sharing a communication channel on a payment interface processor. The plurality of authorization entities is associated with a data processing system. In one embodiment, the server system may receive a request for generation of a set of cryptographic keys corresponding to each authorization entity of the plurality of authorization entities. The server system includes a communication interface, a memory, and a processor communicably coupled to the communication interface and the memory. In one embodiment, the server system is a payment server associated with a payment network. In one example, each of the plurality of authorization entities may be associated with the acquirer server or the issuer server. The request may be handled by an administrator associated with the server system. In an embodiment, the request may be received from the acquiring processing system associated with the acquirer. In another embodiment, the request may be received from the issuing processing system associated with the issuer.
[0028] The server system is configured to generate a set of cryptographic keys corresponding to each authorization entity based, at least in part, on an entity identifier associated with each authorization entity and the communication channel identifier associated with the communication channel. In one embodiment, the set of cryptographic keys corresponding to each of the plurality of authorization entities is generated by a hardware security module (HSM) communicatively coupled to the server system.
[0029] The set of cryptographic keys corresponding to each authorization entity includes at least one of master cryptographic key representing key encryption key (KEK), pin encryption key (PEK), local master key (LMK), zone master key (ZMK), zone pin key (ZPK), and the like. The server system is configured to store the set of cryptographic keys corresponding to each authorization entity indexed based, at least in part, on the entity identifier and the communication channel identifier in a database. In general, the database is an organized collection of data (structured information) stored electronically in a computer system. The set of cryptographic keys of each authorization entity is identified based, at least in part, on the entity identifier and the communication channel identifier.
[0030] The server system is further configured to transmit a data block to the data processing system through the payment interface processor (PIP). The data block includes the set of cryptographic keys corresponding to each authorization entity and the communication channel identifier. The set of cryptographic keys is identified based, at least in part, on the entity identifier and the communication channel identifier. The server system transmits the data block periodically after a period of time (e.g., 12 hours, 1 day, 2 days, and the like). The communication channel between the server system and the data processing system is established via the payment interface processor.
[0031] In one embodiment, the server system is configured to send an operation command to generate a master cryptographic key corresponding to each authorization entity and the communication channel to a Hardware Security Module (HSM) communicatively connected to the server system. The server system is configured to receive the master cryptographic key corresponding to each authorization entity and the communication channel identifier. The server system is further configured to transmit the master cryptographic key corresponding to each authorization entity and the communication channel identifier to the data processing system.
[0032] The server system is also configured to send an operation command to generate the PIN encryption key (PEK) corresponding to each authorization entity and the communication channel to the HSM. The server system is configured to encrypt the PEK of each authorization entity using the respective master cryptographic key of each authorization entity. The server system is further configured to transmit the data block to the data processing system. The data block includes a unique data field indicating a key exchange message for the plurality of authorization entities and the encrypted PEK associated with each authorization entity.
[0033] Hence, a first set of cryptographic keys associated with a first authorization entity is different from a second set of cryptographic keys associated with a second authorization entity, where the first authorization entity and the second authorization entity communicate over the single communication channel on the payment interface processor.
[0034] The server system is configured to enable an authorization process between an acquiring processing system associated with an acquirer and an issuing processing system associated with an issuer. The acquirer is enrolled with an acquirer PIP of a payment network. In a similar manner, the issuer is enrolled with an issuer PIP of the payment network. The acquirer is configured to host a payment application on a payment terminal on which a customer/user/cardholder may tender payment for a purchase from a facility such as a merchant using a payment card. The payment terminal may be associated with the issuer or the acquirer. In one example, the payment terminal includes a point-of-sale terminal (POS machine), automated teller machine (ATM), and the like. The payment terminal initiates and sends a payment transaction request to the acquiring processing system associated with the acquirer. The server system is configured to receive the payment transaction request from the acquiring processing system associated with the acquirer via a first communication channel on the acquiring PIP. The payment transaction request includes PIN encrypted under acquiring PEK key corresponding to the acquirer, the first communication channel, and first entity identifier associated with the acquirer.
[0035] The server system is configured to fetch acquiring PEK key based, at least in part, on the first entity identifier and a first communication channel identifier of the first communication channel from the database. The server system is configured to identify a second entity identifier and a second communication channel on an issuing PIP associated with an issuer based, at least in part, on bank identification number (BIN) included in the payment transaction request. The server system is configured to fetch an issuing PEK key associated with issuer based, at least in part, on the second entity identifier and a second communication channel identifier of second communication channel from the database.
[0036] The server system is configured to transmit a PIN translation command to a Hardware Security Module (HSM) communicatively connected to the server system. The PIN translation command includes the acquiring PEK key and the issuing PEK key. The server system is configured to receive the PIN encrypted with the issuing PEK key from the HSM. The server system is configured to transmit a payment authorization request to an issuing processing system via the second communication channel on the issuing PIP. The payment authorization request includes the PIN encrypted with the issuing PEK key and the second entity identifier associated with the issuer.
[0037] Various embodiments of the present disclosure offer multiple advantages and technical effects. For instance, the present disclosure provides reduced operational overhead because of usage of a single PIP for the plurality of authorization entities. In addition, the present disclosure provides increased security because of a unique entity identifier associated with each authorization entity of the plurality of authorization entities. Further, the present disclosure reduces resource consumption because of usage of the single PIP for the plurality of authorization entities. Furthermore, the cryptographic sign-on operation enhancement provided by the present disclosure is compliant with standard of any country across the globe.
[0038] Thus, the server system enhances the cryptographic sign-on operations by performing cryptographic key exchanges between various entities, such as the server system and the data processing system. In addition, the server system enables the authorization process between the acquiring processing system associated with the acquirer and the issuing processing system associated with the issuer to validate the payment transaction request, which is further explained in detail with reference to FIGS. 1 to 9.
[0039] FIG. 1 illustrates an exemplary representation of an environment 100 related to at least some example embodiments of the present disclosure. Although the environment 100 is presented in one arrangement, other embodiments may include the parts of the environment 100 (or other parts) arranged otherwise depending on, for example, allocating cryptographic keys to various authorization entities for communicating messages via a shared communication channel on a payment interface processor. The environment 100 generally includes, a data processing system 102, a plurality of authorization entities (for the sake of clarity, a single authorization entity 104 is shown), a payment network 106 including a payment server 108, a payment interface processor (PIP) 110, a server system 112, each coupled to, and in communication with (and/or with access to) a network 114. The network 114 may include, without limitation, a light fidelity (Li-Fi) network, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a satellite network, the Internet, a fiber optic network, a coaxial cable network, an infrared (IR) network, a radio frequency (RF) network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among the entities illustrated in FIG. 1, or any combination thereof.
[0040] Various entities in the environment 100 may connect to the network 114 in accordance with various wired and wireless communication protocols, such as Transmission Control Protocol and Internet Protocol (TCP/IP), User Datagram Protocol (UDP), 2nd Generation (2G), 3rd Generation (3G), 4th Generation (4G), 5th Generation (5G) communication protocols, Long Term Evolution (LTE) communication protocols, future generation communication protocols, or any combination thereof. For example, the network 114 may include multiple different networks, such as a private network made accessible by the server system 112, separately, and a public network (e.g., the Internet etc.).
[0041] The data processing system 102 is a data processing center that is configured to handle a plurality of cryptographic operations for one or more authorization entities. The one or more authorization entities are registered with the data processing system 102 for facilitating cryptographic operations. The data processing system 102 includes one or more hardware security modules (HSMs) (not shown in the FIG. 1) to perform cryptographic operations. The data processing system 102 may communicate with the one or more HSMs using TCP IP protocol or using a serial communication. In one example, the one or more HSMs and the data processing system 102 can be a single entity embodied within a single server system. The data processing system 102 may be built on cloud computing platform. In general, the HSM is a tamper-proof physical computing device or crypto processor specially designed for performing cryptographic operations. In one embodiment, the data processing system 102 maintains cryptographic keys and performs cryptographic processing for its associated authorization entities.
[0042] In one embodiment, the authorization entity 104 may be involved in authorization of a payment transaction. In one example, an authorization entity (e.g., issuer server 104a) may receive authorization request messages from another authorization entity (e.g., acquirer server 104b) and in response, the issuer server 104a generates an authorization response message including authorization status.
[0043] In one embodiment, the issuer server 104a is associated with a financial institution normally called as an "issuer bank" or "issuing bank" or simply "issuer", in which a cardholder may have a payment account, (which also issues a payment card, such as a credit card or a debit card), and provides microfinance banking services (e.g., payment transaction using credit/debit cards) for processing electronic payment transactions, to the cardholder.
[0044] In one embodiment, the acquirer server 104b is associated with a financial institution (e.g., a bank) that processes financial transactions. This can be an institution that facilitates the processing of payment transactions for physical stores, ATM terminals, merchants, or an institution that owns platforms that make online purchases or purchases made via software applications possible (e.g., shopping cart platform providers and in-app payment processing providers). The terms “acquirer”, “acquirer bank”, “acquiring bank” or “acquirer server” will be used interchangeably herein.
[0045] In one embodiment, the payment server 108 may be used by the payment cards issuing authorities as an interchange payment network. Examples of interchange payment network include, but are not limited to, Mastercard® payment system interchange network. The Mastercard® payment system interchange network is a proprietary communications standard promulgated by Mastercard International Incorporated® for the exchange of financial transaction data between two entities that are members of Mastercard International Incorporated®. (Mastercard is a registered trademark of Mastercard International Incorporated located in Purchase, N.Y.).
[0046] In one embodiment, the payment interface processor (PIP) 110 (e.g., Mastercard Interface Processor (MIP), etc.) is configured, by computer-executable instructions to perform routing for communication messages received from authorization entities via one or more routers to payment processing network (e.g., payment network 106). In other words, the PIP 110 may directly be coupled with one or more data processing systems via the one or more routers. The PIP 110 may include a plurality of communication ports (i.e., communication channels) for routing the communication messages among the authorization entities. Each port is assigned with a communication channel identifier (e.g., port identifier). In one embodiment, a single communication channel can be shared by one or more authorization entities for coupling the one or more authorization entities with the payment network 106.
[0047] During registration or enrolment of the authorization entity 104 on the payment network 106, the payment server 108 may allocate a particular communication channel (i.e., a particular port) on the PIP 110 for the authorization entity 104 for sending communication messages that can be shared with one or more authorization entities. The payment server 108 is also configured to assign an entity identifier or index (e.g., Interbank Card Association (ICA)) to the authorization entity 104.
[0048] Since the plurality of authorization entities cannot transmit cardholder sensitive data (e.g., PIN) directly over the payment network 106 via the PIP 110, therefore, the payment server 108 is configured to implement security protocols through data encryption and decryption. To implement the security protocols, the payment server 108 is configured to generate various cryptographic keys for various cryptographic operations, for example, data encryption and decryption and share cryptographic keys with authorization entities. Detailed explanation of the various cryptographic keys is provided in the following description.
[0049] In one example scenario (i.e., not in accordance with present disclosure), each authorization entity may be allocated to a different communication channel of the PIP 110. However, such system results in increase of operational overhead and requirement of major changes at the PIP 110 and the data processing system 102 during onboarding of each authorization entity.
[0050] In another example scenario (as per existing solutions, and not per the embodiments of the present disclosure), the payment server 108 may generate unique cryptographic keys corresponding to a shared communication channel of the PIP 110 that is shared among a set of authorization entities. Thereafter, the payment server 108 may send the same cryptographic keys for each authorization entity of the set of authorization entities that share the communication channel on the PIP 110. For example, if 10 authorization entities are enrolled on the payment network 106 with single sign-on functionality (i.e., opt-in functionality of sharing port on the PIP with other authorization entity), the payment server 108 will allocate one common communication channel on the PIP 110 to each authorization entity (i.e., one communication channel identifier and 10 ICAs for the 10 authorization entities. Hence, the payment server 108 maintains 1 key set for the ten authorization entities and the same key set will be used by the ten authorization entities.
[0051] The main drawbacks of the existing single sign-on functionality are: (a) All authorization entities sharing the communication channel need to use same cryptographic keys, (b) The single sign-on functionality creates a security violation to use the same cryptographic keys for multiple authorization entities.
[0052] To solve the above problems, the server system 112 is configured to perform one or more of the operations described herein. In one example, the server system 112 is embodied with the payment network 106. In other words, the server system 112 is an example of the payment server 108. In general, the server system 112 is configured to allocate unique cryptographic keys for each authorization entity that utilizes a shared communication channel on the PIP 110. Thus, the server system 112 is configured to assign cryptographic keys with respect to the authorization entity and the shared communication channel. In other words, the server system 112 is configured to generate a set of cryptographic keys corresponding to each authorization entity based, at least in part, on the entity identifier associated with each authorization entity and the communication channel identifier associated with the shared communication channel.
[0053] The set of cryptographic keys includes at least one of: PIN encryption key (PEK), local master key (LMK), key encryption key (KEK), zone master key (ZMK), zone pin key (ZPK), and the like. The PEK is a session key which is used for PIN encryption, decryption, or translation. Both the server system 112 or the payment server 108 and the authorization entity 104 should use the same PEK keys for PIN encryption and decryption. The KEK is a master cryptographic key that is used to encrypt PEK session keys. Since PEK session keys cannot be shared directly to any party, the PEK session keys are encrypted using the KEK and then the PEK session keys are shared with any party. Some non-exhaustive examples of the encryption keys include a terminal master key (TMK), a zonal master key (ZMK), Terminal Pin Key (TPK), Message Authentication Code (MAC) Key and the like in a context of cryptographic keys used in a payment network.
[0054] The server system 112 is coupled with a HSM to perform various cryptographic key operations such as, cryptographic key generation, encryption/decryption, management of the set of cryptographic keys, personal identification number (PIN) verification, card verification value (CVV) verification, authorization response code (ARC) verification, authorization response cryptogram (ARPC) generation, authorization request cryptogram (ARQC) validation, PIN translation and the like.
[0055] In one embodiment, the server system 112 stores the set of cryptographic keys corresponding to each authorization entity 104 indexed based, at least in part, on the entity identifier and the communication channel identifier in a database 116. In one embodiment, the database 116 provides storage location to the set of cryptographic keys. In one example, the set of cryptographic keys are stored in a table along with the information of the communication channel identifier and the entity identifier associated with the authorization entity 104.
[0056] The number and arrangement of systems, devices, and/or networks shown in FIG. 1 are provided as an example. There may be additional systems, devices, and/or networks; fewer systems, devices, and/or networks; different systems, devices, and/or networks, and/or differently arranged systems, devices, and/or networks than those shown in FIG. 1. Furthermore, two or more systems or devices shown in FIG. 1 may be implemented within a single system or device, or a single system or device shown in FIG. 1 may be implemented as multiple, distributed systems or devices. Additionally, or alternatively, a set of systems (e.g., one or more systems) or a set of devices (e.g., one or more devices) of the environment 100 may perform one or more functions described as being performed by another set of systems or another set of devices of the environment 100.
[0057] FIGS. 2A, 2B, and 2C, collectively, represent a sequence flow diagram 200 of cryptographic key exchange process, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 200 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner. It is to be noted that to explain the sequence flow diagram 200, references may be made to elements described in FIG. 1.
[0058] The sequence flow diagram 200 is explained herewith including entities such as, an administrator 202 associated with the server system 112, hardware security module (HSM) 204 associated with the server system 112, a data processing system 102 along with an HSM 206. The data processing system 102 is configured to provide cryptographic services to a plurality of authorization entities. The plurality of authorization entities shares a single communication channel on the PIP 110. It should be noted that in some embodiments, the plurality of authorization entities can also be associated with one or more data processing systems without deviating the scope of the disclosure.
[0059] During enrolment or on-boarding process of the plurality of authorization entities on the payment network 106, the server system 112 is configured to assign a particular entity identifier (e.g., ICA) corresponding to each authorization entity and identify the data processing system 102 associated with each authorization entity. Thereafter, the server system 112 is configured to initiate a key exchange process.
[0060] To initiate the key exchange process, at 205, an administrator 202 sends a request to the server system 112 for generating unique key encryption key (KEK) corresponding to each authorization entity.
[0061] At 210, the server system 112 sends a cryptographic operation command for generating the unique KEK corresponding to each authorization entity to the HSM 204.
[0062] In response, at 215, the server system 112 receives the unique KEK corresponding to each authorization entity from the HSM 204.
[0063] At 220, the server system 112 stores the unique KEK corresponding to each authorization entity against communication channel identifier corresponding to the shared communication channel on the PIP 110 and the entity identifier i.e., ICA corresponding to the authorization entity, in the database 116. In particular, the server system 112 is configured to create an entry including the KEK of each authorization entity using a composite key in the database 116. The composite key includes two attributes such as, entity identifier (i.e., ICA) and a communication channel identifier corresponding to a communication channel allocated on the PIP 110.
[0064] At 225, the server system 112 transmits unique KEKs of the plurality of authorization entities to the data processing system 102 via the PIP 110. The unique KEKs are shared with respect to entity identifiers of the plurality of authorization entities and the communication channel identifier associated with the communication channel shared by the plurality of authorization entities.
[0065] At 230, the data processing system 102 transmits all the unique KEKs of the plurality of authorization entities to the HSM 206 for performing validation process.
[0066] Upon successful validation, at 235, the data processing system 102 stores all the unique KEKs according to entity identifiers associated with the plurality of authorization entities and the communication channel identifier of the communication channel on the PIP 110 shared by the plurality of authorization entities. In one embodiment, the HSM 206 may store the unique KEKs in a database associated with the data processing system 240.
[0067] At 240, the server system 112 sends a command to the HSM 204 to generate a set of PIN encryption keys (PEKs) associated with the plurality of authorization entities. The HSM 204 may generate random unique PEK of each authorization entity based on the communication channel identifier and the ICA of the authorization entity. In one embodiment, the server system 112 may send a request for generating PEK of a first authorization entity and then, the HSM 204 may provide the PEK encrypted with the KEK of the first authorization entity (i.e., PEK_KEK) and the PEK encrypted with LMK (local master key) of the HSM 204. The HSM 204 has its own master key known as Local Master Key (LMK) (e.g., 0132456729ABCDEF). Every cryptography key is encrypted under this LMK. In an example, the HSM stores the LMK on a chip card and a clear value of the LMK cannot be known by anyone. In similar manner, the server system 112 may send requests for generating PEKs of remaining authorization entities in iterative manner.
[0068] At 245, the server system 112 receives the set of PEKs of the plurality of authorization entities encrypted with corresponding KEKs (i.e., PEK_KEK) and the set of PEKs of the plurality of authorization entities encrypted with the LMK of the HSM 204 (i.e., PEK_LMK). More illustratively, PEK of an authorization entity is encrypted with its own KEK to generate PEK_KEK key and the PEK of the authorization entity is also encrypted with the LMK of the HSM 204 to generate the PEK_LMK key.
[0069] At 250, the server system 112 stores the set of PEKs (i.e., PEK_LMK) of the plurality of authorization entities encrypted with the LMK of the HSM 204 based on the entity identifiers and the communication channel identifier.
[0070] At 255, the server system 112 sends a key exchange message to the data processing system 102. The key exchange message includes the set of PEKs (i.e., PEK_KEK) of the plurality of authorization entities encrypted with corresponding KEKs. The key exchange message includes multiple data element (DE) fields.
[0071] The key exchange message may comply with a message type defined by an International Organization for Standardization (ISO) 8583 standard, which is a standard for systems that exchanges electronic transaction information associated with payments. In one example, an ISO 8583 transaction message may include one or more data elements that store data usable by the server system 112 to communicate information such as transaction requests, responses to transaction requests, inquiries, indications of fraud, security information, or the like. For example, the ISO 8583 message may include a PAN in the second data field (also known as DE2), an amount of a transaction in DE4, a date of settlement in DE15, a location of merchant 112 in DE41, DE42, and/or DE43, or the like. In particular, the acquirer server 104b transmits merchant name, location, city, and country-code in the DE 43 data element.
[0072] In one example, the key exchange message includes all the PEK keys corresponding to each authorization entity in a data element (i.e., DE-110) and a unique data field such as DE-70 indicating a key exchange message of the plurality of authorization entities. For example, the server system 112 may transmit the entity identifier associated with each authorization entity along with the set of cryptographic keys in an ISO DE field as entity identifier 1: the first set of cryptographic keys, entity identifier 2: the second set of cryptographic keys, … entity identifier n: the last set of cryptographic keys.
[0073] At 260, the data processing system 102 sends a command to the HSM 206 to decrypt the set of PIN encryption keys (PEKs) encrypted with KEKs (key encryption keys) associated with the plurality of authorization entities and generate the PEKs encrypted with LMK of the HSM 206. The HSM 206 may fetch unique KEK of each authorization entity based on the communication channel identifier and the ICA of the authorization entity from the database and decrypt the unique KEKs of the plurality of authorization entities. In one embodiment, the data processing system 102 may send a request for fetching PEK_LMK from PEK_KEK of a first authorization entity and then, the HSM 206 may provide the PEK encrypted with the LMK of the first authorization entity (i.e., PEK_LMK) of the HSM 206. In similar manner, the data processing system 102 may send requests for generating PEK_LMKs of remaining authorization entities.
[0074] At 265, the data processing system 102 receives the set of PEKs of the plurality of authorization entities encrypted with the LMK of the HSM 204 (i.e., PEK_LMK). More illustratively, PEK of an authorization entity is encrypted with its own KEK to generate PEK_KEK key and the PEK of the authorization entity is also encrypted with the LMK of the HSM 206 to generate the PEK_LMK key.
[0075] At 270, the data processing system 102 stores the set of PEKs (i.e., PEK_LMK) of the plurality of authorization entities encrypted with the LMK of the HSM 206 based on the entity identifiers and the communication channel identifier in a database.
[0076] FIGS. 3A, 3B, and 3C, collectively, represent a sequence flow diagram 300 of payment authorization process, in accordance with an embodiment of the present disclosure. The sequence of operations of the sequence flow diagram 300 may not be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner. It is to be noted that to explain the sequence flow diagram 300, references may be made to elements described in FIG. 1.
[0077] More illustratively, the sequence flow diagram 300 explains authorization process after performing key exchange with the plurality of authorization entities. A part of payment system is represented in which a credit/debit card user uses a payment card interchange network, such as, payment network 106. Examples of payment interchange network include, but not limited to, Mastercard® payment system interchange network.
[0078] The payment network 106 includes various entities such as a payment terminal (e.g., POS terminal 302), an acquirer server 104b, a payment server (not shown) and an issuer server 104a. The acquirer server 104b is associated with an acquiring processing system 304 (similar to the data processing system 102 as shown in the FIG. 1) for performing a cryptography operation (i.e., PIN translation during a payment transaction) on behalf of the acquirer server 104b. The acquirer server 104b is enrolled with an acquirer PIP 306 (similar to the PIP 110) of the payment network 106. The POS terminal 302 is associated with a merchant (not shown). Examples of the merchant may include any retail shop, restaurant, supermarket or establishment, government and/or private agencies, or any such place equipped with POS terminals, where customers visit for performing financial transaction in exchange for any goods and/or services or any transaction that requires financial transaction between customers and the merchant. In some embodiments, a smartphone, a tablet, a personal digital assistant (PDA), a notebook, a kiosk, an ATM or any electronic device having the capability to perform the payment transaction can be used instead of the POS terminal 302 without deviating from the scope of the description.
[0079] The acquirer server 104b is configured to host a payment application on the POS terminal 302 on which a customer/user can tender payment for a purchase from a facility such as a merchant using a payment card. The issuer server 104a is associated with an issuing processing system 310 for performing cryptography operations and enrolled with issuer PIP 308 on the payment network 106.
[0080] When the user tenders payment for a purchase with a payment card, he may need to enter a PIN of the payment card using the POS terminal 302. The PIN (e.g., a four-digit number) encrypted with terminal PIN key (TPK) is required to be sent by the merchant for verification to the acquirer server 104b for the processing the payment.
[0081] At 315, the POS terminal 302 sends a payment transaction request to the acquiring processing system 304 via the acquirer server 104b. Since the acquirer server 104b needs to translate the PIN encrypted using terminal PIN key (TPK) to the PIN encrypted with PEK of the acquirer server 104b. The PEK is an encryption key used for encrypting the PIN for transmission between the acquirer server 104b and the server system 112 or the payment server 108 in the payment system during the payment transaction.
[0082] At 320, the acquiring processing system 304 performs pre-screening validation process on the payment transaction request and extracts the PIN encrypted with the TPK.
[0083] At 325, the acquiring processing system 304 identifies the acquirer server 104b and fetches the entity identifier i.e., ICA corresponding to the acquirer server 104b and communication channel identifier associated with a communication channel of the acquiring PIP 306 from its database.
[0084] At 330, the acquiring processing system 304 fetches PIN encryption key (PEK_LMK) associated with acquirer server 104b and TPK_LMK of the POS terminal 302 from the database. As the PEK and the TPK would be encrypted under the LMK of the associated HSM of the acquiring processing system 304, only the HSM would be able to read them.
[0085] At 335, the acquiring processing system 304 performs PIN translation process. In particular, the acquiring processing system 304 sends the TPK_LMK, the PEK_LMK, and a PIN translation command to the HSM associated with the acquiring processing system 304. The HSM decrypts the PIN using the TPK and thereafter, the HSM encrypts the PIN using the PEK of the acquirer server 104b and sends back the PIN encrypted with PEK of the acquirer server 104b to the acquiring processing system 304.
[0086] At 340, the acquiring processing system 304 transmits the payment transaction request including the PIN encrypted under the acquirer PEK of the acquirer server 104b via the communication channel (i.e. Port) of the acquiring PIP 306 to the server system 112. In one embodiment, the server system 112 is associated with the payment network 106. The server system 112 further needs to translate the PIN encrypted under from the PEK of the acquirer server 104b to issuer PEK keys of the issuer server 104a. In one embodiment, the acquiring processing system 304 may also send the entity identifier of the acquirer server 104b in the payment transaction request in ISO DE-32 data field or in a separate message along with the payment transaction request.
[0087] It should be noted that messages within a payment network such as payment networks 106 may, in at least some examples, conform to International Organization for Standardization (ISO) Standard or any such standard in force from time to time. For instance, the payment transaction request may comply with a message type defined by the International Organization for Standardization (ISO) 8583 standard.
[0088] At 345, the server system 112 performs pre-screening validation as per process already known in the art.
[0089] At 350, the server system 112 extracts the entity identifier associated with the acquirer server 104b from the payment transaction request.
[0090] At 355, the server system 112 fetches acquirer PEK keys of the acquirer server 104b from the database 116 based on the entity identifier of the acquirer server 104b and the communication channel identifier of the communication channel on the acquiring PIP 306 The communication channel of the acquiring PIP 306 was registered with the acquirer server 104b while on-boarding of the acquirer server 104b on the payment network 106. The communication channel is shared by multiple authorization entities.
[0091] In particular, the server system 112 generates a composite key based on the entity identifier of the acquirer server 104b and the communication channel identifier and runs a query over the database 116 to fetch the acquirer PEK keys.
[0092] At 360, the server system 112 identifies a communication channel (i.e., port) on the issuing PIP 308 and entity identifier (i.e., ICA) of the issuer server 104a based on bank identification number (BIN) information included in the payment transaction request.
[0093] In one example, face of the payment card displays 16-digit card number including the BIN. The BIN is associated with the issuer server 104a. When the customer swipes/dips the payment card at the POS terminal 302, the POS terminal 302 extracts the BIN associated with the payment card for determining issuer. A BIN table stored at the server system 112 includes a plurality of BIN ranges associated with card issuers and based on the BIN table, a BIN range is identified for the issuer server 104a.
[0094] At 365, the server system 112 fetches issuing PEK keys from the database 116 based on the entity identifier of the issuer server 104a and a communication channel identifier of the communication channel on the issuing PIP 308.
[0095] At 370, the server system 112 performs PIN translation process to translate the PIN encrypted under the acquirer PEK keys to the PIN encrypted under issuer PEK keys. In particular, the server system 112 sends a PIN translation command to the HSM. The PIN translation command includes the acquiring PEK keys encrypted under LMK of HSM associated with server system 112, issuing PEK keys encrypted under the LMK of the HSM.
[0096] The HSM decrypts the PIN using the acquirer PEK keys and thereafter, the HSM encrypts the PIN using the issuing PEK keys and sends back the PIN encrypted with issuing PEK keys of the issuer server 104a to the server system 112.
[0097] At 375, the server system 112 sends a payment authorization request to the issuing processing system 310 of the issuer server 104a via the communication channel of issuing PIP 308. In one embodiment, the server system 112 also sends the entity identifier of the issuer server 104a to the issuing processing system 310 in the payment transaction request.
[0098] At 380, the issuing processing system 310 fetches the issuing PEK keys of the issuer server 104a from the associated database using the communication channel identifier and the received entity identifier of the issuer server 104a.
[0099] In order to verify the PIN, at 385, the issuing processing system 310 performs PIN verification cryptographic operation for the issuer server 104a The issuing processing system 310 fetches a pin verification key (PVK) to verify PIN number entered by the cardholder while performing the payment transaction at the POS terminal 302.
[00100] In one non-limiting example, the acquiring processing system 304 manages two authorization entities (e.g., entity A and entity B), where the entity A is the acquirer server 104b. The issuing processing system 310 manages two authorization entities (e.g., entity C and entity D), where the entity C is the issuer server 104a.
[00101] The server system 112 allocates the common port with communication channel identifier (say, 11111) to the entity 'A' and the entity 'B'. In addition, the server system 112 allocates unique and separate entity identifier to the entity 'A' and the entity B. The server system 112 further allocates different set of cryptographic keys to each of the plurality of authorization entities (i.e., entity A and entity B) based on the corresponding entity identifier (i.e., ICA) and the communication channel identifier. In one example, the set of cryptographic keys along with the corresponding entity identifier, the communication channel identifier and type of the set of cryptographic keys is further illustrated in Table 1:
Type of cryptographic keys Communication channel identifier ICA Cryptographic keys
KEK 11111 AAAAAA 3333333333333333333
PEK 11111 AAAAAA 4444444444444444444
KEK 11111 BBBBBB 5555555555555555555
PEK 11111 BBBBBB 6666666666666666666
Table 1
[00102] Further, suppose the plurality of authorization entities (e.g., entity C and entity D) are onboarded on the issuing processing system 310. The server system 112 allocates the common communication channel identifier (say, 22222) to each of the plurality of authorization entities (i.e., entity C and entity D). In addition, the server system 112 allocates unique and separate entity identifier (i.e., ICA) to each of the plurality of authorization entities (i.e., entity C and entity D). The entity identifier for the entity C is ‘CCCCCC’ and the entity identifier for the entity D is ‘DDDDDD’. The server system 112 further allocates the set of cryptographic keys to each of the plurality of authorization entities (i.e., entity C and entity D) based on the corresponding entity identifier (i.e., ICA) and the communication channel identifier. In one example, the set of cryptographic keys along with the corresponding entity identifier, the communication channel identifier and type of the set of cryptographic keys is further illustrated in Table 2:
Type of cryptographic keys Communication channel identifier Entity identifier Cryptographic keys
KEK 22222 CCCCCC 3A3A3A3A3A3A3A3A3A
PEK 22222 CCCCCC 3B3B3B3B3B3B3B3B3B
KEK 22222 DDDDDD 4A4A4A4A4A4A4A4A4A
PEK 22222 DDDDDD 4B4B4B4B4B4B4B4B4B
Table 2.
[00103] In an example, a payment transaction is performed by a cardholder ‘CH1’ with a payment card associated with the entity C on a payment terminal associated with the entity A. The acquiring processing system 304 needs to perform PIN encryption before sending it over the payment network (e.g., payment network 106 of FIG. 1). To perform PIN encryption, the acquiring processing system 304 utilizes ‘4444444444444444444’ as the cryptographic key. The acquiring processing system 304 shares the payment transaction request to the server system 112 encrypted with the PEK (e.g., ‘4444444444444444444’). The server system 112 fetches and utilizes the same cryptographic key ‘4444444444444444444’ to perform decryption. In addition, the server system 112 fetches and utilizes the issuer cryptographic key ‘3B3B3B3B3B3B3B3B3B’ to perform encryption before sending the payment transaction request to the issuing processing system 310.
[00104] In another example, a payment transaction is performed by a cardholder ‘CH2’ with a payment card associated with the entity D on a payment terminal associated with the entity B. The acquiring processing system 304 needs to perform PIN encryption before sending it over the payment network (e.g., payment network 106 of FIG. 1). To perform PIN encryption, the acquiring processing system 304 utilizes ‘6666666666666666666’ as the set of cryptographic keys. The acquiring processing system 304 shares the payment transaction request to the server system 112. The server system 112 fetches and utilizes the same cryptographic key ‘6666666666666666666’ to perform decryption. In addition, the server system 112 fetches and utilizes the cryptographic keys ‘4B4B4B4B4B4B4B4B4B’ to perform encryption before sending the payment transaction request to the issuing processing system 310.
[00105] FIG. 4 illustrates a flow diagram depicting a method 400 for allocating cryptographic keys to a plurality of authorization entities, in accordance with an embodiment of the present disclosure. The method 400 depicted in the flow diagram may be executed by, for example, the payment server 108 of FIG. 1. Operations of the method 400, and combinations of operation in the method 400, may be implemented by, for example, hardware, firmware, a processor, circuitry and/or a different device associated with the execution of software that includes one or more computer program instructions. The operations of the method 400 are described herein may be performed by an application interface that is hosted and managed with help of the payment server 108 of FIG. 1. The method 400 starts at operation 402. It is to be noted that to explain the method 500, references may be made to elements described in FIG. 1.
[00106] At operation 402, the method 400 includes accessing information of a plurality of authorization entities sharing a communication channel on a payment interface processor (PIP) 110. The plurality of authorization entities is associated with the data processing system 102.
[00107] At operation 404, the method 400 includes generating a set of cryptographic keys corresponding to each authorization entity (for example, authorization entity 104) based, at least in part, on an entity identifier associated with each authorization entity and a communication channel identifier associated with the communication channel.
[00108] At operation 406, the method 400 includes storing the set of cryptographic keys corresponding to each authorization entity indexed based, at least in part, on the entity identifier and the communication channel identifier in the database 116. The set of cryptographic keys of each authorization entity is identified based, at least in part, on the entity identifier and the communication channel identifier from the database 116.
[00109] At operation 408, the method 400 includes transmitting a data block to the data processing system through the PIP 110. The data block includes the set of cryptographic keys corresponding to each authorization entity and the communication channel identifier.
[00110] The sequence of operations of the method 400 needs not to be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner.
[00111] FIG. 5 illustrates a flow diagram depicting a method 500 for performing payment authorization process, in accordance with an embodiment of the present disclosure. The method 500 depicted in the flow diagram may be executed by, for example, the server system 112 of FIG. 1. Operations of the method 500, and combinations of operation in the method 500, may be implemented by, for example, hardware, firmware, a processor, circuitry and/or a different device associated with the execution of software that includes one or more computer program instructions. The operations of the method 500 are described herein may be performed by an application interface that is hosted and managed with help of the server system 112 of FIG. 1. The method 500 starts at operation 502. It is to be noted that to explain the method 500, references may be made to elements described in FIG. 1.
[00112] At operation 502, the method 500 includes receiving, by the server system 112, a payment transaction request from an acquiring processing system associated with the acquirer server 104b via a first communication channel on an acquiring pip. The payment transaction request includes pin encrypted under acquiring PEK key corresponding to the acquirer server 104b and the first communication channel, and first entity identifier associated with the acquirer server 104b.
[00113] At operation 504, the method 500 includes fetching, by the server system 112, the acquiring PEK key based, at least in part, on the first entity identifier and a first communication channel identifier of the first communication channel from the database (e.g., database 116).
[00114] At operation 506, the method 500 includes identifying, by the server system 112, a second entity identifier and a second communication channel on an issuing pip associated with the issuer server 104a based, at least in part, on bank identification number (bin) included in the payment transaction request.
[00115] At operation 508, the method 500 includes fetching, by the server system 112, an issuing PEK key associated with the issuer server 104a based, at least in part, on the second entity identifier and a second communication channel identifier of second communication channel from the database (e.g., database 116).
[00116] At operation 510, the method 500 includes transmitting, by the server system 112, a pin translation command to a hardware security module (HSM) communicatively connected to the server system 112. The pin translation command includes the acquiring PEK key and the issuing PEK key.
[00117] At operation 512, the method 500 includes receiving, by the server system 112, the pin encrypted with the issuing PEK key from the HSM.
[00118] At operation 514, the method 500 includes transmitting, by the server system 112, a payment authorization request to an issuing processing system via the second communication channel on the issuing PIP.
[00119] The sequence of operations of the method 500 need not to be necessarily executed in the same order as they are presented. Further, one or more operations may be grouped together and performed in form of a single step, or one operation may have several sub-steps that may be performed in parallel or in sequential manner.
[00120] FIG. 6 is a simplified block diagram of an issuer server 600, in accordance with an example embodiment of the present disclosure. The issuer server 600 is an example of the issuer server 104a of FIG. 1. The issuer server 600 is associated with an issuer bank/issuer, in which a cardholder may have an account, which provides a payment card. The issuer server 600 includes a processing module 605 operatively coupled to a storage module 610 and a communication module 615. The components of the issuer server 600 provided herein may not be exhaustive and the issuer server 600 may include more or fewer components than those depicted in FIG. 6. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the issuer server 600 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00121] The storage module 610 is configured to store machine executable instructions to be accessed by the processing module 605. Additionally, the storage module 610 stores information related to, contact information of the cardholder, bank account number, availability of funds in the account, payment card details, transaction details and/or the like. Further, the storage module 610 is configured to store payment transactions.
[00122] In one embodiment, the issuer server 600 is configured to store profile data (e.g., an account balance, a credit line, details of the cardholder, account identification information, payment card number) in the database 116. The details of the cardholder may include, but not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like of the cardholder etc.
[00123] The processing module 605 is configured to communicate with one or more remote devices such as a remote device 620 using the communication module 615 over a network such as the network 114 of FIG. 1. The examples of the remote device 620 include the server system 112, the payment server 108, the data processing system 102, the database 116 or other computing systems of the issuer server 600 and the network 114 and the like. The communication module 615 is capable of facilitating such operative communication with the remote devices and cloud servers using API (Application Program Interface) calls. The communication module 615 is configured to receive a payment transaction request performed by the cardholder via the network 114. The processing module 605 receives a payment card information, a payment transaction amount, a customer information and merchant information from the remote device 620 (i.e., the payment server 108). The issuer server 600 includes a transaction database 630 for storing transaction data. The transaction data may include, but not limited to, transaction attributes, such as transaction amount, source of funds such as bank or credit cards, transaction channel used for loading funds such as POS terminal or ATM machine, transaction velocity features such as count and transaction amount sent in the past x days to a particular user, transaction location information, external data sources and other internal data to evaluate each transaction. The issuer server 600 includes a user profile database 625 storing user profile associated with the plurality of cardholders.
[00124] The user profile data may include an account balance, a credit line, and details of the cardholder, account identification information, payment card number, or the like. The details of the cardholder may include, but not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like of the cardholder.
[00125] FIG. 7 is a simplified block diagram of an acquirer server 700, in accordance with an example embodiment of the present disclosure. The acquirer server 700 is an example of the acquirer server 104b of FIG. 1. The acquirer server 700 is associated with an acquirer bank/acquirer, in which a cardholder may have an account, which provides a payment card. The acquirer server 700 includes a processing module 705 operatively coupled to a storage module 710 and a communication module 715. The components of the acquirer server 700 provided herein may not be exhaustive and the acquirer server 700 may include more or fewer components than those depicted in FIG. 7. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the acquirer server 700 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00126] The storage module 710 is configured to store machine executable instructions to be accessed by the processing module 705. Additionally, the storage module 710 stores information related to, contact information of the cardholder, bank account number, availability of funds in the account, payment card details, transaction details and/or the like. Further, the storage module 710 is configured to store payment transactions.
[00127] In one embodiment, the acquirer server 700 is configured to store profile data (e.g., an account balance, a credit line, details of the cardholder, account identification information, payment card number) in the database 116. The details of the cardholder may include, but not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like of the cardholder etc.
[00128] The processing module 705 is configured to communicate with one or more remote devices such as a remote device 720 using the communication module 715 over a network such as the network 114 of FIG. 1. The examples of the remote device 720 include the server system 112, the payment server 108, the data processing system 102, the database 116 or other computing systems of the acquirer server 700 and the network 114 and the like. The communication module 715 is capable of facilitating such operative communication with the remote devices and cloud servers using API (Application Program Interface) calls. The communication module 715 is configured to receive a payment transaction request performed by the cardholder via the network 114. The processing module 705 receives a payment card information, a payment transaction amount, a customer information and merchant information from the remote device 720 (i.e., the payment server 108). The acquirer server 700 includes a transaction database 730 for storing transaction data. The transaction data may include, but not limited to, transaction attributes, such as transaction amount, source of funds such as bank or credit cards, transaction channel used for loading funds such as POS terminal or ATM machine, transaction velocity features such as count and transaction amount sent in the past x days to a particular user, transaction location information, external data sources and other internal data to evaluate each transaction. The acquirer server 700 includes a user profile database 725 storing user profile associated with the plurality of cardholders.
[00129] The user profile data may include an account balance, a credit line, and details of the cardholder, account identification information, payment card number, or the like. The details of the cardholder may include, but not limited to, name, age, gender, physical attributes, location, registered contact number, family information, alternate contact number, registered e-mail address, or the like of the cardholder.
[00130] FIG. 8 is a simplified block diagram of a payment server 800, in accordance with an example embodiment of the present disclosure. The payment server 800 is an example of the payment server 108 of FIG. 1. The payment server 800, the data processing system 102, and the server system 112 of FIG. 1 may use the payment network 106 as a payment interchange network. Examples of payment interchange network include, but not limited to, Mastercard® payment system interchange network.
[00131] The payment server 800 includes a processing system 805 configured to extract programming instructions from a memory 810 to provide various features of the present disclosure. The components of the payment server 800 provided herein may not be exhaustive and that the payment server 800 may include more or fewer components than that of depicted in FIG. 8. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the payment server 800 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00132] Via a communication interface 815, the processing system 805 receives request from a remote device 820, such as the acquirer server 104b, a merchant device associated with a merchant, or a customer device hosting a payment gateway application. The request may be a request for conducting the payment transaction. The communication may be achieved through API calls, without loss of generality. The payment server 800 includes a database 825. The database 825 also includes transaction processing data such as, Issuer ID, POS ID, country code, acquirer ID, merchant identification number (MID), among others.
[00133] When the payment server 800 receives a payment transaction request from the acquirer server 104b or the payment terminal, the payment server 800 may route the payment transaction request to an issuer server (e.g., the issuer server 104a of FIG. 1). The database 825 stores transaction identifiers for identifying transaction details such as, transaction amount, payment card details, acquirer account information, transaction records, merchant account information, and the like.
[00134] In one example embodiment, the acquirer server 104b is configured to send an authorization request message to the payment server 800. The authorization request message includes, but is not limited to, the payment transaction request.
[00135] The processing system 805 further sends the payment transaction request to the issuer server 104a for facilitating payment transaction from the remote device 820. The processing system 805 is further configured to notify the remote device 820 of the transaction status in form of an authorization response message via the communication interface 815. The authorization response message includes, but is not limited to, a payment transaction response received from the issuer server 104a. Alternatively, in one embodiment, the processing system 805 is configured to send an authorization response message for declining the payment transaction request, via the communication interface 815, to the acquirer server 104b.
[00136] FIG. 9 is a simplified block diagram of a server system 900, in accordance with an example embodiment of the present disclosure. The server system 900 includes a computer system 902, a database 904, and a hardware security module (HSM) 916. In an embodiment, the server system 900 is integrated, but not limited to, in the payment server 108.
[00137] The computer system 902 includes at least one processor 906 configured to execute executable instructions for providing various features of the present disclosure. The executing instructions are stored in a memory 908. The components of the computer system 902 provided herein may not be exhaustive and that the computer system 902 may include more or fewer components than that of depicted in FIG. 9. Further, two or more components may be embodied in one single component, and/or one component may be configured using multiple sub-components to achieve the desired functionalities. Some components of the computer system 902 may be configured using hardware elements, software elements, firmware elements and/or a combination thereof.
[00138] The processor 906 is operatively coupled to a communication interface 910 such that the computer system 902 is capable of communicating with a remote device 914 such as the acquirer server 104b, associated with the payment network 106 (shown in FIG. 1), respectively or communicated with any entity connected to the network 114 (shown in FIG. 1) or any constituents of the acquirer server 104b. In an embodiment, the communication interface 910 is configured to receive a request for generation of the set of cryptographic keys. In addition, the communication interface 910 is configured to transmit the data block to the data processing system 102 including the set of cryptographic keys corresponding to each authorization entity and the shared communication channel, and a data element for indicating the data block as the key exchange message.
[00139] The processor 906 may also be operatively coupled to the database 904. The database 904 is an example of the database 116. The database 904 is any computer-operated hardware suitable for storing and retrieving data, such as, but not limited to, information of the card issuers, information of merchant, transaction data generated as part of sales activities conducted over the payment network 106 including data relating to merchants, payees, or customers, and purchases. The database 904 may also store the set of cryptographic keys, bank details of the merchant, authentication credentials of the merchant, security certificates, communication channel identifier information and entity identifier information associated with the plurality of authorization entities, and the like. The database 904 may include multiple storage units such as hard disks and/or solid-state disks in a redundant array of inexpensive disks (RAID) configuration. The database 904 may include a storage area network (SAN) and/or a network attached storage (NAS) system.
[00140] In some embodiments, the database 904 is integrated within the computer system 902. For example, the computer system 902 may include one or more hard disk drives as the database 904. The storage interface 912 is any component capable of providing the processor 906 with access to the database 904. The storage interface 912 may include, for example, an Advanced Technology Attachment (ATA) adapter, a Serial ATA (SATA) adapter, a Small Computer System Interface (SCSI) adapter, a RAID controller, a SAN adapter, a network adapter, and/or any component providing the processor 906 with access to the database 904.
[00141] The processor 906 is configured to receive the request for generating the set of cryptographic keys corresponding to each authorization entity of the plurality of authorization entities associated with the data processing system (e.g., 102 of FIG. 1). In addition, the processor 906 is configured to generate the set of cryptographic keys corresponding to each authorization entity based, at least in part, on the entity identifier associated with each authorization entity and the communication channel identifier. Further, the processor 906 is configured to store the set of cryptographic keys corresponding to each authorization entity indexed based, at least in part, on the entity identifier and the communication channel identifier in the database (e.g., 116 of FIG. 1). Thereafter, the processor 906 is configured to transmit the data block to the data processing system (e.g., 102 of FIG. 1) including the set of cryptographic keys corresponding to each authorization entity and the shared communication channel, and the data element for indicating the data block as the key exchange message.
[00142] The HSM 916 is configured to perform cryptographic operations received in cryptographic operation commands sent by the server system 900. The HSM 916 utilizes the set of cryptographic keys to perform the cryptographic operations. The HSM 916 is an example of the HSM (not shown in figure) described with reference to FIG. 1. The HSM 916 is further configured to generate a response of the performed operation and send to the server system 900. The processor 906 is configured to send the response generated by the HSM 916 to the remote device 914 via the communication interface 910.
[00143] Without limiting the scope of the present disclosure, the one or more example embodiments disclosed herein provide methods and systems for enhancing cryptographic sign-on operations with facilitation of a single payment interface processor (PIP). More specifically, a plurality of authorization entities may use a single port on the PIP to perform cryptographic operations. The plurality of authorization entities is allocated with a common communication channel identifier and a unique entity identifier is allocated for each authorization identity of the plurality of authorization entities. In addition, a set of cryptographic keys is allocated to each authorization entity of the authorization entities based, at least in part, on the communication channel identifier and the entity identifier of the corresponding authorization entity. The use of single port on the PIP reduces operational overhead. Further, an authorization process is enabled among a data processing system associated with an issuer server, a data processing system associated with an acquirer server and a payment server based on the set of cryptographic keys.
[00144] The disclosed methods with reference to FIGS. 1 to 9, or one or more operations of the method 400 and the method 500 may be implemented using software including computer-executable instructions stored on one or more computer-readable media (e.g., non-transitory computer-readable media, such as one or more optical media discs, volatile memory components (e.g., DRAM or SRAM), or nonvolatile memory or storage components (e.g., hard drives or solid-state nonvolatile memory components, such as Flash memory components) and executed on a computer (e.g., any suitable computer, such as a laptop computer, net book, Web book, tablet computing device, smart phone, or other mobile computing device). Such software may be executed, for example, on a single local computer or in a network environment (e.g., via the Internet, a wide-area network, a local-area network, a remote web-based server, a client-server network (such as a cloud computing network), or other such network) using one or more network computers. Additionally, any of the intermediate or final data created and used during implementation of the disclosed methods or systems may also be stored on one or more computer-readable media (e.g., non-transitory computer-readable media) and are considered to be within the scope of the disclosed technology. Furthermore, any of the software-based embodiments may be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, software applications, cable (including fiber optic cable), magnetic communications, electromagnetic communications (including RF, microwave, and infrared communications), electronic communications, or other such communication means.
[00145] Although the disclosure has been described with reference to specific exemplary embodiments, it is noted that various modifications and changes may be made to these embodiments without departing from the broad spirit and scope of the disclosure. For example, the various operations, blocks, etc., described herein may be enabled and operated using hardware circuitry (for example, complementary metal oxide semiconductor (CMOS) based logic circuitry), firmware, software and/or any combination of hardware, firmware, and/or software (for example, embodied in a machine-readable medium). For example, the apparatuses and methods may be embodied using transistors, logic gates, and electrical circuits (for example, application specific integrated circuit (ASIC) circuitry and/or in Digital Signal Processor (DSP) circuitry).
[00146] Particularly, the server system 900 (e.g., the server system 112 or the payment server 108) and its various components such as the computer system 902 and the database 904 may be enabled using software and/or using transistors, logic gates, and electrical circuits (for example, integrated circuit circuitry such as ASIC circuitry). Various embodiments of the disclosure may include one or more computer programs stored or otherwise embodied on a computer-readable medium, wherein the computer programs are configured to cause a processor or computer to perform one or more operations. A computer-readable medium storing, embodying, or encoded with a computer program, or similar language, may be embodied as a tangible data storage device storing one or more software programs that are configured to cause a processor or computer to perform one or more operations. Such operations may be, for example, any of the steps or operations described herein. In some embodiments, the computer programs may be stored and provided to a computer using any type of non-transitory computer readable media. Non-transitory computer readable media include any type of tangible storage media. Examples of non-transitory computer readable media include magnetic storage media (such as floppy disks, magnetic tapes, hard disk drives, etc.), optical magnetic storage media (e.g. magneto-optical disks), CD-ROM (compact disc read only memory), CD-R (compact disc recordable), CD-R/W (compact disc rewritable), DVD (Digital Versatile Disc), BD (BLU-RAY® Disc), and semiconductor memories (such as mask ROM, PROM (programmable ROM), EPROM (erasable PROM), flash memory, RAM (random access memory), etc.). Additionally, a tangible data storage device may be embodied as one or more volatile memory devices, one or more non-volatile memory devices, and/or a combination of one or more volatile memory devices and non-volatile memory devices. In some embodiments, the computer programs may be provided to a computer using any type of transitory computer readable media. Examples of transitory computer readable media include electric signals, optical signals, and electromagnetic waves. Transitory computer readable media can provide the program to a computer via a wired communication line (e.g. electric wires, and optical fibers) or a wireless communication line.
[00147] Various embodiments of the disclosure, as discussed above, may be practiced with steps and/or operations in a different order, and/or with hardware elements in configurations, which are different than those which, are disclosed. Therefore, although the disclosure has been described based upon these exemplary embodiments, it is noted that certain modifications, variations, and alternative constructions may be apparent and well within the spirit and scope of the disclosure.
[00148] Although various exemplary embodiments of the disclosure are described herein in a language specific to structural features and/or methodological acts, the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as exemplary forms of implementing the claims.