GB2524946A - Secure gateway for payments other transactions involving sensitive information - Google Patents

Abstract

The invention relates to a gateway for providing point to point encryption (P2PEG) for the communication of sensitive data for card-present transactions from a card reading device to a transaction processing system using a communication network. The sensitive data for a transaction is encrypted at the card reading device such that said encrypted transaction data is transmitted from the card reading device through a merchant environment towards said transaction processing system. The encrypted transaction data is redirected via said P2PEG 3.9, wherein the P2PEG comprises a secure decryption module (SDM) for accessing a decryption key for decrypting the encrypted transaction data. Responsive to the receipt of the encrypted transaction data at the P2PEG, the SDM is configured to decrypt the encrypted transaction data such that the decrypted transaction with the sensitive data is transmitted to the transaction processing system via the communication network. A subsystem is also provided which further utilises a secure interface device and tokens to avoid encrypted data passing through a merchant environment. The gateway of the present invention is capable of providing P2PE for a payment transaction system without requiring any significant changes to be made to an existing transaction processing system, such as an existing Payment Service Provider (PSP) system.

Description

A Secure Gateway For Transactions Involving Sensitive Information

Field of the Invention

The present invention generally relates to a gateway, method and system for enabling secure communication of sensitive information. Particularly, the invention relates to communications such as credit/debit card payments and/or other transactions in which cardholder data or other sensitive information is to be transmitted from one node or terminal to another node or terminal via a communication network, for the processing of said payments/transactions. More particularly, the invention is concerned with secure communication of cardholder data when a payment card is presented at a terminal for a payment/transaction to take place.

Background of the invention

Companies or merchants that accept payment cards for goods/services provided often collect, store or otherwise process information concerning individuals in order to provide services and products. Many countries have enacted laws that regulate how such information is to be treated or may be used. In addition, some industry bodies prescribe codes of conduct and standards with which their members must comply.

One such industry body is the Payment Card Industry -Security Standards Council (PCI 550). It administers the Data Security Standard (PCI DSS), a framework for the secure handling of cardholder data. PCI DSS compliance requirements apply to all system components that are included in, or connected to, the cardholder data environment (i.e. that part of the network which stores, processes or transmits cardholder data), including network components, servers and applications. These compliance requirements apply to communications for card-present transactions (when the payment card is presented at a point of sale (POS) terminal at a merchant premises), as well as cardholder-not-present transactions (when a transaction is made online or over the telephone via a web payment portal or a call centre assistant).

Payment Service providers (PSP) are entities that provide merchant's services for accepting electronic payments by a variety of payment methods including credit card, bank-based payments such as direct debits or transfers, and real-time bank transfers online. Typically, a PSP uses a software as a service model to form a single technical gateway for the merchant to multiple payment methods. A PSP can connect to multiple acquiring banks, card associations and payment networks. The PSP5 fully manage the connections and relationships with the external networks and bank accounts.

PCI SSC has in the recent years released a point-to-point encryption (P2PE) Standard, as an encryption standard to secure cardholder data from point-of-interaction (P01) or point of sale (POS) in the merchant environment through processing, for cardholder-present transactions. The reference to merchant environment throughout this document refers to the hardware and software modules and databases required to be maintained by the merchant in order to accept card payments for purchases and other transactions such as returns, refunds, price adjustments, discounts, offers etc. Thus the merchant environment typically comprises the POS systems as well as the backend systems.

The data in P2PE remains encrypted between the source and the destination, with no decryption of the data feasible at any point between the source and the destination.

The encrypted information in the transmit path is deemed not to be actual cardholder data and is therefore out of scope' for PCI DSS. The presumption of P2PE is that cardholder data in transit is protected when it is encrypted, to the extent that an entity in possession of the cipher text alone cannot reverse the encryption process. Thus the decryption keys or algorithms should not be accessible to the merchant or any other party through which the encrypted data flows, other than the destination or end point for P2PE. Properly implemented P2PE allows merchants to reduce their scope in complying with PCI DSS and simplify compliance for and within their environment. This is because P2PE eliminates cardholder data from flowing through their existing IT systems. Thus, there is a desire for merchants to implement P2PE techniques for processing card-present transactions.

Most existing PSPs that offer payment services to merchants concentrate on offering online secure services, i.e. dealing with cardholder-not-present transactions for online shopping and payments. Few PSP5 offer in-store or card-present transactions services compliant with PCI DSS P2PE. Existing PSPs that are not set up for P2PE would be required to modify their systems such that they are able to act as the end point for the encryption i.e. they should have the necessary modules for storing and applying the decryption keys for the end-to-end encryption that originates at the P05. One reason for existing PSPs being unable to offer P2PE compliant services for card-present transactions is because this would involve a significant change to their existing IT systems and backend system architecture, as a means for decryption (typically implemented as a Hardware Security Module (HSM)) specific to the encryption being applied at the POS terminal would need to be implemented. Another reason specific to card-present transactions is that dominant players existing in the P05 market currently supply merchants with P2PE ready' card reading devices or terminals i.e. Pin Entry Devices (PEDs) that are capable of applying encryption at the Point Of Interaction (P01). In order to offer P2PE to their merchants, PSPs are required to incorporate an HSM in their existing systems or to be able to connect securely to a hosted third party service that implements the HSM, such as a hosted P2PE gateway. The existing HSMs, whether implemented within or connected to the PSP are specific to the type of encryption applied at the PEDs connected to the merchant environment. Such HSMs are capable of generating or storing the necessary decryption keys for the encryption applied at the PED for a merchant. In addition to this, about 30%-50% of the existing backend systems and IT architecture would need to be changed to incorporate PED encryption-specific HSMs or to be able to securely communicate with a HSM that is provided externally to the PSP system. These changes are very expensive and take a lot of time to be tried, tested and implemented for existing traditional PSP systems.

Furthermore, once implemented the resulting system would be a rather inflexible one.

This is because the HSM that the PSP either implements or connects with can only provide P2PE transactions for one particular type of PED encryption, thereby preventing the PSP from offering their secure payment services to merchants using card readers or PED5 that apply a different type of encryption. Such a system also results in inflexibility in the merchant's environment. This is because, if the merchant requires changing their PED5 for any technical or commercial reason to ones providing a different type of encryption or generating encryption keys using a different technique, they may need to also change their PSP or the hosted service or gateway implementing a suitable HSM to a different provider that can offer P2PE functionality to decipher the new encryption keys. Likewise, if the merchant wishes to change their existing PSP, but at the same time keep their existing PEDs connected to their P05 systems and backend systems; they would only be able to engage a PSP incorporating an HSM or configured to securely connect with a gateway hosting a HSM that can process the same encryption as the existing one.

Therefore, there exists a need for providing a cost-effective and flexible P2PE, i.e. point to point encryption, for existing PSPs without requiring significant changes to be made to the existing systems in the PSP or the merchant environment

Summary of the Invention

A first embodiment of the present invention relates to a gateway for providing point to point encryption (P2PEG) for the communication of sensitive data for card-present transactions from a card reading device to a transaction processing system using a communication network, the sensitive data for a transaction being encrypted at the card reading device such that said encrypted transaction data is transmitted from the card reading device through a merchant environment towards the transaction processing system; wherein the encrypted transaction data is redirected via the P2PEG, and wherein the P2PEG comprises a secure decryption module (SDM) for accessing a decryption key for decrypting the encrypted transaction data; and wherein, responsive to the receipt of the encrypted transaction data at the P2PEG, the 5DM is configured to decrypt the encrypted transaction data; and wherein the decrypted transaction with the sensitive data is transmitted to the transaction processing system using the communication network.

A second embodiment of the present invention relates to a system for providing point to point encryption (P2PE) for the communication of sensitive data for card-present transactions in a communication network, the system including a gateway for point to point encryption (P2PEG), as set out in the first embodiment, the system further comprising: a card reading device that is capable of interacting with a card having sensitive data stored on it such that the card reading device is configured to access and encrypt the sensitive data for a transaction using an encryption key that is unique for a particular transaction; a merchant environment including a point of sale system (POS) connected to backend systems (BE) , wherein the card reading device is connected to the POS, and the P03 and/or BE is connected to the P2PEG such that encrypted transaction data is transmitted from the card reading device through the merchant environment; and a transaction processing system connected to the P2PEG, wherein said encrypted transaction data is transmitted through the merchant environment towards the transaction processing system, and wherein the encrypted transaction data is redirected via the P2PEG, the P2PEG configured such that, responsive to decryption of the encrypted transaction data in the SDM, the P2PEG transmits the decrypted transaction to the transaction processing system, said transaction processing system being capable of communicating with an external network to authorise and process the transaction, the transaction processing system further configured to return the results of said transaction to the merchant environment via the P2PEG.

Another aspect of the second embodiment of the present invention relates to a method for providing point to point encryption (P2PE) for the communication of sensitive data for card-present transactions in a communication network, the method being implemented in the system as set out above, the method comprising the steps of: initiating a transaction at the card reading device by inserting or swiping a card at the device; accessing sensitive data from the card by the card reading device; encrypting the sensitive data using a unique encryption key for the transaction at the card reading device; transmitting encrypted transaction data from the card reading device to the merchant environment; redirecting the encrypted transaction data via the P2PEG; accessing or generating decryption keys for the encrypted transaction data by the SDM in the P2PEG; decrypting the encrypted transaction data using the decryption keys in the SDM; transmitting the decrypted transaction to the transaction processing system; processing the decrypted transaction at the transaction processing system by communicating with an external network for authorising the transaction; returning the result of said transaction by the transaction processing system to the merchant environment via the P2PEG.

A third embodiment of the present invention relates to a subsystem for providing point to point encryption (P2PE) for the communication of sensitive data for card-present transactions from a card reading device to a transaction processing system using a communication network, the sensitive data for a transaction being encrypted at the card reading device; said subsystem comprising a gateway for providing point to point encryption (P2PEG) and a secure interface device connected to each other by a communication link; wherein the secure interface device is capable of being communicatively connected to the card reading device and a merchant environment such that it is capable of receiving the encrypted transaction data from the card reading device and sending the encrypted transaction data to the P2PEG via the communication link; the P2PEG comprises a tokenisation module configured to replace the encrypted transaction data with a non-encrypted token and to return said token to the secure interface device for forwarding to the merchant environment; said merchant environment being communicatively connected to the P2PEG such that said token is received at the P2PEG; the tokenisation module is further configured to retrieve the encrypted transaction data corresponding to the token, responsive to receiving the token from the merchant environment; the P2PEG further comprises a secure decryption module (SDM) for accessing a decryption key for decrypting the encrypted transaction data, and wherein, responsive to the retrieval of the encrypted transaction data by the tokenisation module, the SDM is configured to decrypt the encrypted transaction data such that the decrypted transaction with the sensitive data is transmitted to the transaction processing system via the communication network.

A fourth embodiment of the present invention relates to a system for providing point to point encryption (P2PE) for the communication of sensitive data for card-present transactions in a communication network, the system including a subsystem for providing point to point encryption, as set out above, the system further comprising: a card reading device that is capable of interacting with a card having sensitive data stored on it such that the card reading device is configured to access and encrypt the sensitive data for a transaction using an encryption key that is unique for a particular transaction; a merchant environment including a point of sale system (POS) connected to backend systems (BE), the secure interface device being connected to the card reading device and FOS, and the FOS and/or BE being connected to the F2FEG such that a non-encrypted token received from the tokenisation module is received at the P2PEG; and a transaction processing system connected to the P2PEG, the P2PEG configured such that, responsive to decryption of the retrieved encrypted transaction data in the SDM, the F2PEG transmits the decrypted transaction to the transaction processing system, said transaction processing system being capable of communicating with an external network to authorise and process the transaction, the transaction processing system further configured to return the results of said transaction to the merchant environment via the P2PEG.

Another aspect of the fourth embodiment relates to a method for providing point to point encryption (P2PE) for the communication of sensitive data for card-present transactions in a communication network, the method being implemented in the system as set out above, the method comprising the steps of initiating a transaction at the card reading device by inserting or swiping a card at the device; accessing sensitive data from the card by the card reading device; encrypting the sensitive data using a unique encryption key for the transaction at the card reading device; sending encrypted transaction data from the card reading device to the secure interface device; transmitting the encrypted transaction data from the secure interface device to the P2PEG via the communication link; replacing the encrypted transaction data with a non-encrypted token by the tokenisation module in the P2PEG, and storing the encrypted transaction data and non-encrypted token in the P2PEG; returning the token to the secure interface device; transmitting the token from the secure interface device to the merchant environment; transmitting the token from the merchant environment to the P2PEG, or redirecting the token from the merchant environment via the P2PEG; retrieving the encrypted transaction data using the token by the tokenisation module; accessing or generating decryption keys for the encrypted transaction data by the SDM in the P2PEG; decrypting the encrypted transaction data using the decryption keys in the SDM; transmitting the decrypted transaction to the transaction processing system by the P2PEG; processing the decrypted transaction at the transaction processing system by communicating with an external network for authorising the transaction; returning the result of said transaction by the transaction processing system to the merchant environment via the P2PEG.

Brief Description of the Drawings

Figure la shows an example of a conventional system for processing card-present transactions.

Figure lb shows the flow of data in the conventional system in figure la.

Figure 2a shows an example of an existing system incorporating P2PE for processing card-present transactions.

Figure 2b shows the flow of data in the existing system in figure 2a.

Figure 3 shows a secure gateway for implementing P2PE for card-present transactions, according to a first embodiment of the present invention.

Figure 4 shows a system for processing card-present transactions incorporating the gateway of figure 3, according to a second embodiment of the present invention.

Figure 5 shows a subsystem for implementing P2PE for card-present transactions, according to a third embodiment of the present invention.

Figure 6 shows a system for processing card-present transactions incorporating the subsystem of figure 5, according to a fourth embodiment of the present invention.

Figure 7 shows the flow of data in the system in figure 6.

Detailed Description

Payment service providers (PSP) have transaction processing systems for providing payment services to merchants or organisations accepting card payments. They provide such services by receiving the transactions from the merchant Point of Sale (POS) systems and forwarding this on to the payment acquiring bank for processing of such payment. Once authenticated, the outcome of such transactions will be passed to the merchant POS systems through the PSP. As mentioned above, PSP5 can provide services to enable merchants to accept online payments i.e. cardholder -not -present transactions, or card-present payments in which the cardholder physically inserts or swipes the payment card into a card reader device such as pin entry device (PED) that is connected via a wired, wireless or mobile communication network to the merchant's POS systems. The present invention is concerned with secure card-present payments and other transactions involving cardholder data in which the card physically interacts with the FED.

Though the embodiments of the present invention herein described are mostly concerned with card payment transactions involving sensitive cardholder data which must be securely handled, the present invention is not limited to the use of payment cards and the transfer of cardholder data alone. The invention extends to the secure communication of any type of sensitive information that is stored on a card and which can be accessed at a point of interaction using a card reading device, and which needs to be transferred to a different terminal or entity via a communication network to be processed. For instance, the present invention can be used in the healthcare industry for secure communication of patient information and health records that are linked to a patient card. This information can be accessed and dealt with in a similar way to cardholder data in the present invention. Another application of the present invention is for the secure communication of identity information in documents such as passports, national identity cards, social security numbers etc. between agencies, service providers or businesses that handle such sensitive information.

The below detailed description is concerned with the preferred application, i.e. the communication of cardholder data that complies with regulations and standards set by the FCI SSC. A traditional card-present payment system using Europay, MasterCard and Visa (EMV), which is a global standard for handling and authenticating cardholder-present transactions, is depicted in figure la. It will be understood that although the preferred application focuses on EMV transactions, a similar approach can be adopted for non-EMV transactions, such as those where the cardholder data is contained on a magnetic stripe (magstripe) on the card. An existing system incorporating end-to-end encryption to comply with the recent P2PE standard set by the PCI SSC is depicted in figure 2a.

The components of the traditional and existing systems and the technical steps taking place to transmit and process card-present transactions are explained below in detail, so that the differences between the existing systems and embodiments of the invention (depicted from figures 2-6) can be clearly established.

I. Traditional card-present payment processing (figures la and ib): As seen in figure la, the traditional system comprises a card reading device such as a Pin Entry Device (PED) 1.4 connected to a Point-of Sale (P03) system 1.6 in a merchant environment, which is in turn connected to the Backend systems (BE) 1.8 and/or other IT systems in the merchant environment. The communication links between these components can be established by a wired or wireless/mobile communication network. The BE systems 1.8 are then connected using a larger communication network such as the Internet or a WLAN network to a payment service portal provided by the PSP 1.12. A standard PSP 1.12 will include an interface (not shown in figure)for receiving merchant information and e-commerce transactions from a merchant (the PSP's client interface) as well as a payment platform (not shown in figure) for processing the e-commerce transactions.

The systems/server(s) at the PSP 1.12 is connected to the Payment Network(PN) 1.14 of an Issuing bank and an Acquiring bank for obtaining the requested funds. An issuing bank or issuer is a bank that offers payment cards directly to consumers. The term issuer is derived from the fact that it issues payment to the acquiring bank on behalf of its customer (the purchaser in the transaction). An acquiring bank or acquirer is a bank or a financial institution that processes card payments for products or services for a merchant. The term acquirer indicates that this bank accepts or acquires creditldebit card payment from the card-issuing banks within an association.

It is assumed that all communications between the components via one or more networks are compliant with PCI DSS.

The numbers of the steps below correspond to the arrows of figure la, which depicts the flow of data and other information taking place in the traditional system for processing a card-present payment: Si-i. When a card-present purchase has been confirmed, the merchant's P05 systems request payment from a FED 1.4 31-2. Once the cardholder swipes or inserts the card 1.2 into the PED 1.4, a request is sent from the PED 1.4 to authorise payment for the card. For an offline' authorisation as seen in this step, the transaction will be automatically authorised, provided the Personal identification number (PIN) number was entered correctly and the transaction meets the offline authorisation criteria on the payment card 1.2. This offline authorisation is done using the Integrated Circuit Card (ICC), i.e. the chip on the payment card 1.2. This result of the authorisation is sent back to the PED 1.4.

S1-3. If authorised, the authorised Transaction (TX) & Transaction Certificate (TC) is then returned to POS 1.6 from the PED 1.4. This transaction (TX) is the set of data relating to a particular payment. It initially includes the payment amount and some information relating to the merchant. As the transaction progresses it is updated to include card data (the primary account number -PAN) and any data to be communicated to acquirer/issuer. The Transaction Certificate (TC) refers to a digital signature created by the card 1.2 so that the card issuer knows that the transaction is authentic.

The payment card 1.2 can be removed from the PED 1.4 after this step.

If the transaction is not authorised by the card, then an Application Authentication Cryptogram (AAC) is used to sign dedined transactions. In this case, the payment process terminates at this step. Step 51-4 onwards only relates to authorised transactions.

S1-4. The authorised transaction and the certificate (TX + TC) are then stored using suitable and secure storage means in BE systems 1.8 maintained in the merchant environment.

S1-5. At intervals that may be predefined, the authorised transactions and certificates are sent using a communication network to the merchant's PSP 1.12. In most cases, these are sent across in batches from the merchant BE systems 1.8, but can be transmitted individually as well.

S1-6. Once this is received at the PSP 1.12, the PSP 1.12 then proceeds to communicate with the PN 1.14 i.e. the network existing between the issuing bank (also called issuer) and the acquiring bank (also called acquirer) in order to obtain the funds.

S1-7. Confirmation of the acquired funds/Error in the transaction is then passed from the FN 1.14 to the FSF 1.12.

Si-B. The PSP 1.12 then returns this confirmation/Error notification to BE system 1.8.

The below steps will take place in the system shown in figure la if an online, i.e. real-time authorisation, is requested before funds can be acquired. In this case, step 51-2 above is replaced with the following steps S1-2a. Once the cardholder swipes or inserts the card 1.2 into the PED 1.4, the TX & an Authorisation Request Cryptogram (ARQC) is returned to the PED 1.4. The ARQC is a standard cryptogram used whenever Online Card Authentication is requested. This cryptogram is generated by the payment card for transactions requiring online authorization. This cryptogram is the result of the card, the FED 1.4, and transaction data (TX) encrypted by a Data Encryption Standard (DES) key in the authorization request. The issuer validates the AROC to ensure that the card is authentic and card data was not copied from a skimmed card.

S1-2b. The TX & ARQC is then sent from the PED 1.4 to the P05 systems 1.6.

S1-2c. The POS systems 1.6 then send the TX & ARQC to BE 1.8 (this step is optional,as it is possible for the POS 1.6 to directly handle further transmission of the TX in some cases).

S1-2d. The POS 1.6 or the BE 1.8 then sends the TX & AROC to PSP 1.12.

S1-2e. The PSP 1.12 then proceeds to authorise the transaction with the PN 1.14.

Si-2f. The PN 1.14 then returns an authorisation code (AC) & an Authorisation Response Cryptogram (ARPC) to the PSP 1.12. The ARPC is a standard cryptogram used for online Issuer Authentication. This cryptogram is the result of the Authorization Request Cryptogram (ARQC) and the issuer's authorization response encrypted by a DES key. It is to be sent to the card as pad of the authorization response.

51-2g. The PSP 1.12 then returns Merchant Defined tags, AC & the ARPC to the BE 1.8.

S1-2h. The BE 1.8 then proceeds to return the Tags, AC & ARPC to the P05 terminals/systems 1.6.

S1-2i. The P05 systems 1.6 then return the Tags, AC & ARPC to the PED 1.4.

S1-2j. The card 1.2 in the PED 1.4 then validates the ARPC to ensure that it is communicating with the valid issuer, and then requests the transaction certificate TC from the ICC in the card 1.2. This step completes the online authorisation and steps 51-3 to 51-8 explained above follow for processing the card present transaction.

The flow of data for transactions using the system of figure la can be seen in figure lb. This figure shows the data handled and processed by the components of the system of figure la. Sensitive cardholder data, card data as well as other types of data, i.e. the cryptograms, acknowledgements etc. are shown in figure lb. This data flow corresponds with the transaction steps shown in figure la.

II. Existing systems for card-present payment processing incorporating PCI DSS compliant point-to-point encryption (P2PE) (figures 2a and 2b): As seen in figure 2a, existing systems for card-present transactions implementing P2PE have a means for decryption (typically implemented as a hardware security module (HSM)) 2.10 incorporated within the PSP's systems. The HSM 2.10 is a module or device that access, generates and/or stores the decryption keys for the end-to-end encryption, which is a requirement for implementing P2FE. This is also explained in the background section. Such a system as seen in figure 2a requires the HSM 2.10 to be integrated as part of the PSP's 2.12 system architecture, thereby significantly changing the PSP's 2.12 backend and IT systems at the expense of significant cost and time. For instance, one existing method of incorporating the HSM 2.10 in the PSF 2.12 is to create a data flow tunnel' or a secure communication channel between a client interface (not shown in this figure) of the PSP and the HSM 2.10, such that this tunnel is implemented across a payment platform (not shown in this figure) of the PSP 2.12, which is responsible for processing e-commerce transactions.

In some cases, the responsibility for providing the end point of the P2PE system (including the requirement to implement at HSM 2.10 required to access, generate or store the decryption keys) is fulfilled by a third party or external hosted gateway seivice (not shown in figure 2a). In such instances, in order to be able to securely communicate with this gateway to implement P2PE, some subsystems, modules and/or interfaces at both the merchant end as well as the PSP end may need be changed to implement the necessary P2PE requirements for encryption/decryption of sensitive information. The operation of the hosted gateway model will be explained later when explaining the embodiments of the present invention that utilise this model.

The system of figure 2a only shows an integrated HSM model for implementing P2PE i.e. where the HSM 2.10 is integrated within the PSP's systems. All other components of the system of figure 2a are similar to the traditional system as seen in figure la.

Therefore this system also comprises a card reader device such as a Pin Entry Device (FED) 2.4 connected to the merchant Point-of Sale (POS) systems 2.6, which is in turn connected to the merchant Backend systems (BE) 2.8 and/or other IT systems. The communication links between these components can be established by a wired or wireless/mobile communication network. The BE system 2.8 is then connected using larger communication network such as the Internet or a WLAN network to a payment service portal or transaction processing system provided by the PSP 2.12 which incorporates the HSM 2.10. The systems/server(s) at the PSP 2.12 are connected to the Payment Network (PN) 2.14 of the Issuing bank and the Acquiring bank for obtaining the requested funds.

The PEDS 2.4 in this system are configured to encrypt sensitive cardholder data before passing it on to the POS systems 2.6. For instance, encryption which uses Derived Unique Key per Transaction (DUKPT) key management is a preferred method of encrypting sensitive data in PEDs. DUPKT is a method of generating encryption keys specific to a device i.e. the PED 2.4, and based on a transaction ID. Using this method the transaction ID, a device ID and the encrypted data needs to be transmitted by the PED 2.4. The receiving system that is required to decrypt the key may use the device ID along with the transaction ID to generate the same key and then declypt the data. In order to generate the decryption keys at a receiving system such as the HSM 2.10 in the system of figure 2a, the HSM 2.10 must be preconfigured so that it is in sync with or corresponds to the enciyption key generation process applied at the PED. Other types of encryption key generation techniques can also be used, as long as decryption is only possible at the end point for P2PE compliance i.e. only the HSM 2.10 should be able to decrypt the encrypted data.

The POS systems 2.6 and any software associated with this in the merchant environment will also require to be configured such that the POS systems 2.6 are able to pass on encrypted data to other components of system 2a. Therefore, in addition to the significant change needed in the PSP systems architecture, changes to the merchant environment are also required in order to implement the existing P2PE model.

The HSM 2.10 is integrated within the PSP 2.12 systems and is configured to generate and/or store, as well as access and apply decryption keys that are specific to the encryption provided at the FEDs 2.4. Thus the FSF 2.12 with the integrated HSM 2.10 is the destination node, or the end point of the point-to-point encryption (P2PE), and no other system or component is capable of deciphering the encrypted sensitive transaction data. As mentioned in the background sections, the transmission or flow of this encrypted data is out of scope of the PCI DSS standard. Thus, the P2PE system in figure 2a will simplify compliance with PCI DSS and will reduce the merchant's compliance costs with this standard, as non-encrypted sensitive information will no longer flow through the merchant environment.

The numbers of the steps below correspond to the flow arrows of figure 2a, which depict the flow of data and other information taking place in the system of figure 2a for processing a card-present payment. Some of the steps for the transaction, and the terms used to explain these steps are similar to the traditional EMV payment system of figure la, so these similar steps and terms there will not be explained in detail here to avoid re-iteration.

S2-1. POS system 2.6 requests payment from PED 2.4 for a transaction (same as Si-1).

S2-2. FED 2.4 requests authorisation (offline) of payment with Integrated Circuit Card (ICC) (Same as 51-2).

S2-3. This step is different to the transaction steps in figure la as this is the first point' for P2PE.

Here, if authorised, the PED 2.4 encrypts the sensitive card holder data using a predefined encryption technique and by using unique encryption keys. Since the sensitive data is now encrypted, any further communication of this encrypted data does not need to comply with PCI DSS. Thus this is the origin or the first point for P2PE. The authorised Transaction (TX) with sensitive data encrypted using P2PE & Transaction Certificate (TC) is then returned to POS 2.8 from the PED 2.4. The reference to TX in the below steps refers to the transaction with encrypted cardholder data i.e. TX with P2PE data.

The payment card can be removed after this step.

S2-4. TX + TC are then stored in BE system 2.8 (similar to 51-4).

S2-5. Batches of TX5 with TC5 are then forwarded to the F'SP 2.12 (similar to S1-5).

52-6. This step is different from the transaction steps in figure la, as this involves interaction with the HSM 2.10. In this step, the PSP 2.12 is configured to send P2PE protected TX data to the HSM 2.10 that is integrated within the PSP's 2.12 systems for decryption. This may be sent via a secure communication channel that is incorporated within the PSP architecture 2.12.

52-7. This step represents the end-point of the point-to point encryption. Upon receipt of the encrypted sensitive/cardholder data, the HSM 2.10 is configured to access the stored decryption keys or generates a decryption for the TX with P2PE data. The HSM 2.10 then applies the necessary keys to the encrypted TX data to decrypt the cardholder data. The sensitive TX data is decrypted and this decrypted TX data is returned to the PSP 2.12 for further handling. The flow of data following this step will be within the scope of PCI DSS and is required to be handled accordingly.

S2-8. The PSP 2.12 then proceeds to acquire funds from Payment Network (PN) 2.14 (same as 51-6) S2-9. The PN 2.14 the returns confirmation/errors related to the transaction to PSP 2.12 (same as 51-7).

S2-1O. The PSP 2.12 then returns these confirmation/errors to the merchant's BE systems (2.8).

If an online authorisation is requested, then Step S2-2 will be replaced with the following steps as shown at the bottom of figure 2a.

When an online or real time payment authorisation from the issuer is required, this needs to pass through the system components in a similar manner as figure la.

However, since the system of figure 2a implements P2PE, some modifications are required to ensure that the sensitive cardholder data is always in an encrypted form when flowing through the merchant environment.

52-2a. When online authorisation is required, the PED 2.4 accesses the payment card 2.2 and encrypts the cardholder data i.e. the sensitive data in the TX with unique encryption keys for P2PE. The Authorisation Request Cryptogram (AROC) is sent to the PED 2.4 from the ICC in the card 2.2. Thus, the TX with P2PE data & ARQC are received at the PED 2.4.

Steps 52-2b to S2-2d below are similar to steps S1-2a to S1-2d, except that the TX includes the encrypted sensitive data.

S2-2b. The PED 2.4 sends TX with P2PE data & AROC to POS 2.6.

52-2c. The POS sends TX with P2FE data & AROC to BE 2.8 (optional).

S2-2d. The P03 2.6 or BE 2.8 sends the TX with P2PE data & ARQC to PSP 2.12.

S2-2e. This step is different to the online authorisation process of figure la as the sensitive data of the TX requires to be passed to the HSM 2.10 for decryption. In this step, the encrypted sensitive data in the TX is forwarded to the integrated HSM 2.10 in the PSP 2.12.

S2-2f. The integrated HSM 2.10 then accesses the unique decryption key required for decrypting the encrypted data and returns decrypted TX data to the PSP 2.12. Thus this is the end -point of the F2PE for online authorisation, to ensure that all sensitive data flow through the merchant environment is encrypted.

Steps S2-2g to S2-21 below are similar to steps S1-2e to S1-2j of figure la, and handle the same data for the online authorisation.

52-2g. The PSP 2.12 authorises the TX with PN 2.14 S2-2h. The PN 2.14 returns the authentication code (AC) & Authorisation Response Cryptogram (ARPC) to the PSP 2.12.

S2-2i. The PSP 2.12 returns Merchant Defined tags, AC & ARPC to BE 2.8.

S2-2j. BE 2.8 returns Tags, AC & ARPC to POS 2.6.

S2-2k. POS 2.6 returns Tags, AC & ARPC to PED 2.4.

52-21. The card 2.2 validates the ARPC and requests the TC from ICC.

The flow of data for transactions using the system of figure 2a can be seen in figure 2b.

This figure shows the data handled and processed by the components of the system in figure 2a. Sensitive cardholder data, card data as well as other types of data, i.e. the cryptograms, etc. are shown in figure 2b. This data flow shown corresponds to both, online and offline authorisation transaction steps shown in figure 2a.

Ill. First Embodiment of the invention A gateway for providing PCI DSS compliant point-to-point encryption (P2PE) for card-present payment processing systems (figures 3 and 4): As mentioned in the Background section, existing P2PE compliant systems require significant changes to be made to traditional POS/PSP architecture that result in merchants as well as PSP's having to restructure their existing computing systems. To implement the P2PE compliant system in figure 2a, it is essential for the HSM to be integrated with the FSP servers/systems, with some changes being required at the merchant P03 as well so that it can handle encrypted TX data for sending to the PSP.

For the existing hosted gateway model, even though the HSM is not integrated in the PSP's system architecture, this will still require significant changes to be made such that the merchant environment as well as the PSP can connect to this gateway for secure communication of sensitive information, and coordinate with the HSM included in the gateway. Therefore, there exists a need for providing a secuie, cost-effective and flexible P2PE functionality which can be used by existing PSPs without requiring significant changes to be made to the PSP's system architecture.

The present invention in a first embodiment uses the hosted model briefly set out above. The existing hosted-gateway model as well as a new gateway providing point to point encryption (P2PEG) according to the present invention is explained in detail in this section. The first embodiment of the present invention provides a gateway that is capable of providing P2PE functionality to a PSP system, without requiring any change to be made to the PSPs existing systems and IT infrastructure, as thele is no need for the HSM to be implemented within the PSP system. The Point to Point Encryption Gateway (P2PEG) according to the present invention can be communicatively coupled to an existing PSF. The gateway according to the present invention is a hosted service or module that includes one or more secure decryption modules (SDM) for generating and storing the decryption keys required for P2PE. The SDM in the present embodiment is functionally similar to the existing hardware security modules (HSM) described above, in that the SDM is capable of implementing decryption for the encrypted sensitive data. Thus, the SDM is also configured for accessing, generating and/or storing the decryption keys for decrypting the received encrypted sensitive data.

The SDMs according to the present invention can be implemented as secure hardware-based systems (similar to the HSMs and can be referred to as such if using only hardware-based decryption). In another preferred aspect, the SDMs of the present invention may also be implemented using software modules and data structures for performing decryption. Therefore, the decryption taking place in the SDMs can be implemented using hardware or software modules or a combination of both.

The decryption keys generated and/or stored in the SDM maintained in the gateway can be used to decrypt the encryption applied at a PED and provide decrypted transaction data which can be forwarded to the PSP. This decrypted data is transmitted to the PSP via methods compliant with PCI DSS and can be handled by the PSP in the same way as traditional transactions, such as the data flow shown in figure la.

By this, the gateway hosting the SDM will be the end point for P2PE, rather than the PSP. Therefore, as the existing PSP systems will be able to recognize the format of the decrypted transaction data and process this in the normal way (as in figure la), there are no changes in backend systems and other IT system required to be implemented at the PSP. Thus, the hosted gateway model can switch on' or switch off' P2PE functionality for a PSP whenever it is required.

With the existing hosted-gateway model, existing traditional PSPs may be able to offer P2PE functionality to merchants without reconfiguring the PSP's internal IT systems.

However, with existing hosted P2PE gateways, the merchant environment in particular may still require substantial change in order to implement de-scoping. These changes may include swapping the merchant's existing payment processes to those offered by the P2PE gateway (which could include the additional ramifications of re-writing order processing and inventory systems, reporting tools, financial reconciliation systems, etc.). The merchant will also need to ensure that payment communications which previously were sent to the PSP are now routed via the P2PE gateway for decryption.

The P2PE gateway (P2PEG) according to the present invention functions as a ready to connect' hosted service, so a PSP can provide a fully functional P2PE to merchants requesting this without requiring any significant modifications to be made to the merchant environment, or to the PSP environment. Thus, the present invention ensures that the merchant environment and the FSP can securely and easily connect to the gateway P2PEG including the desired SDM, based on the encryption keys applied at the PEDs connected to the merchants environment.

The point to point encryption gateway (P2PEG) according to the present invention is shown in figure 3. The P2FEG 3.9 is a hosted service that is communicatively connected to a merchant environment and a PSP 3.12. The merchant environment here includes the merchant's POS systems 3.6 and the backend systems (BE) 3.8.

The PED 3.4 that encrypts the sensitive data using approved techniques is coupled to the merchant environment, i.e. preferably connected to the POS 3.6, which in turn is connected to the BE 3.8. Data originally sent by the BE 3.8 in the merchant environment towards the PSP is then redirected to the P2PEG 3.9 so that data flow from the merchant environment reaches the gateway. The P2PEG 3.9 is also connected to the PSP. The PSP 3.12 may be similar to an existing PSP, with an interface (not shown in figure 3) for processing payment transactions.

A secure PCI DSS compliant connection to the P2PEG 3.9 of the first embodiment can be obtained as explained below: Access to the secure server of the PSP is now facilitated via the P2PEG 3.9 of present embodiment. In a first example implementation, the P2PEG 3.9 is configured to act as a proxy server with an IP address 1.2.3.4., for example. Suppose that PSP with domain name "w.psp.com" is at IP address 10.0.0.1 and that the P2PEG 3.9 (www.hostedgateway.com") is at IF address 1.2.3.4. In the present embodiment, when the merchant environment initiates a connection with a payment portal of the PSP, i.e. "www.psp.com", a connection from the merchant environment is established (as will be discussed below) to the P2PEG rather than the PSP 3.12, using for example Hypertext Transfer Protocol Secure (HTTPS) so that communications can be fully encrypted. In one example, the domain name for the P2PEG i.e. ww.hostedgateway.com" has a Secure Socket Layer (SSL) certificate generated using the domain name "www.psp.com". This could be an X.509 self-signed SSL certificate (cd file) in the name of "ww.psp.com" , for instance (X.509 is a standard for a Public Key Infrastructure (PKI) and Privilege Management Infrastructure (PMI) of the International Telecommunication U nion (ITU) Telecommunication Standardization Sector). The generated.crt certificate is present at the F2FEG 3.9 at IF address 1.2.3.4.

Thus the connection from the merchant environment to www.hostedgateway.com" will therefore see a valid SSL certificate, and determine that the requested Universal Resource Locator (URL), i.e. "www.hostedgateway.com", matches the certificate domain. However, since the P2PEG 3.9 may be an untrusted certificate issuer, the merchant environment may also add the served certificate of P2PEG 3.9 to a trusted list. Thus, merchant environment i.e. backend systems 3.6 for instance, which would normally connect to the payment portal at "www.psp.com" in the existing systems of figure la and 2a, will now accept a trusted certificate served by F2FEG 3.9. Then, either the DNS server of the merchant environment is changed so communications addressed to w.psp.com" are routed to 1.2.3.4, or a local host file is deployed at the merchant environment such that communications addressed to "www.psp.com" (the PSP 3.12) are instead routed to the P2PEG 3.9 at 1.2.3.4.

In this way, when the merchant environment tries to connect securely to "www.psp.com", the connection request is routed to 1.2.3.4 (i.e. P2PEG 3.9). The merchant environment checks the SSL certificate of the P2PEG 3.9. Since this certificate has been marked as trusted', the SSL connection is established between the merchant environment and the P2PEG 3.9. Once connected, encrypted sensitive data can be transmitted to the P2PEG 3.9 securely and may be decrypted using the SDM 3.10 in the P2PEG 3.9.

Once this is done, the P2PEG 3.9 of the present embodiment must then establish a secure connection with the PSP 3.12 to pass the decrypted sensitive data. When the connection request is received by the P2PEG, it checks the request for the host to which the merchant environment is actually trying to connect with, i.e. the FSP at "www.psp.com", and retrieves its IP address (10.0.0.1) from an external DNS and initiates a connection with "ww.psp.com". The service provider system i.e. the PSP 3.12 provides this connection with its own HTTPS certificate. By way of example, the P2PEG 3.9 requests a secure connection to "www.psp.com." The local or external DNS routes the request to the IP address of "w.psp.com" (i.e. 10.0.0.1). Then, the P2PEG 3.9 checks the SSL certificate of the PSP 3.12. If this certificate has been signed by a trusted certificate authority (CA) and matches the server URL, the SSL connection is established between 1.2.3.4 and PSP. Thus, the interfaces, connection ports, secure connection protocols etc. of the merchant and PSP environments function as normal and do not require any restructuring. At the same time, this allows P2PEG 3.9 to communicate with both merchant environment and PSP 3.12 for required handling of sensitive data.

In a second example implementation for establishing a secure connection with the P2PEG 3.9, the URLs in use by the merchant environment may need to be changed.

For all applications which normally would use the URL "www.psp.com", the merchant environment instead sets the URL to "www.psp.hostedgateway.com". Similar to the above described redirection, an X.509 SSL certificate (.crt file) in the name of "ww.psp.hostedgateway.com" is obtained from a trusted CA and loaded onto the P2PEG 3.9. For the merchant environment which accesses "Aww.psp.com", the URL is changed to www.psp.hostedgateway.com". Thus, when the merchant environment requests a secure connection to "www.psp.hostedgateway.com", it checks the SSL certificate of P2PEG 3.9. As this certificate has been issued by a trusted CA and matches the server URL, an SSL connection is established with no warnings or error messages. In this example, there are no changes required to the certificates accepted by the merchant environment, since the URL "ww.psp.hostedgateway.com" with which it is communicating matches the URL on the certificate. In order to establish a secure connection to the PSP 3.12, the P2PEG 3.9 requests a secure connection to "www.psp.com". A local or external DNS routes this request to the IP address of the PSP 3.12 (e.g. 10.0.0.1). The P2PEG 3.9 checks the SSL certificate of "ww.psp.com", and if this certificate has been signed by a trusted CA and matches the server URL, a SSL connection can be established between them.

Thus, by applying one of the above-described techniques, the transmission of encrypted sensitive data in the present embodiment can be securely and efficiently redirected to reach the P2PEG 3.9 for decryption, without the merchant environment or the PSP having to make any significant changes to their communication interfaces or security protocols.

The P2PEG 3.9 hosts the SDM 3.10 that is capable of generating/storing and applying decryption keys for the encryption applied by the PED 3.4. The P2PEG 3.9 is arranged to receive the encrypted transaction data from the merchant environment (3.6 -3.8) via a suitable interface. This encrypted data is then passed to the SDM 3.10 within the P3PEG 3.9. At the SDM 3.10, the decryption keys are generated or accessed based on the encryption method applied at the PED 3.4. These keys are then applied to the encrypted TX with encrypted sensitive data such that the sensitive data is decrypted.

Then, the decrypted transaction with the sensitive data is transmitted to the FSP 3.12 via a suitable interface. The PSP 3.12 is then able to process the transaction and proceeds to obtain the required authorization from the Payment network (PN) in the similar manner as shown in figure la.

Therefore, the P2FEG 3.9 provides F2PE functionality without requiring any changes to be made in the existing PSP systems.

In a further preferred aspect of the P2PEG 3.9 of the first embodiment, the P2PEG 3.9 may include a plurality of SDMs, each SDM being capable of generating or storing decryption keys for decrypting a particular type of cipher key applied by a FED 3.4, the decryption keys maintained by each said SDM 3.10 being different to the other SDMs.

Therefore, the SDMs in the P2PEG can each operate with a different type of PED applying a different encryption technique. Therefore, this aspect of the invention allows different FEDs, each having a unique encryption technique to be connected to a suitable SDM in the same P2PEG 3.9 to obtain compliant P2PE functionality. Thus, if a merchant changes the PED5 connected to the merchant environment, for any technical or business reason, there is no need to also switch to a FSF that is specifically capable of the new encryption being applied by the new FEDs. The merchant can still use the services of the existing PSP 3.12, as this PSP 3.12 can simply connect to a SDM in the P2PEG 3.9 that can decrypt the new encryption applied by the new PEDs. Therefore, this aspect of the first embodiment provides a more flexible method for implementing F2FE for the merchant environment, when compared to the existing system in figure 2a. Furthermore, the F2PEG 3.9 is not limited for use by just one merchant and many different merchant environments using different PEDs/FOS systems can connect to the P2PEG 3.9 such that P2PE can be implemented for payment transactions by using the appropriate SDM in the P2PEG.

Similarly, this aspect of the first embodiment also provides flexibility for a PSP, as the FSF 3.12 can connect to any one of the SDM's for a particular merchant environment and can switch to a different SDM for a different merchant environment that uses a different PED encryption. Thus, the PSP can still provide fully functional and P2PE to a plurality of different merchants without having to change the PSP's system architecture.

In a further preferred aspect of the first embodiment, the F2FEG 3.9 with either a single hosted SDM or a plurality of SDM's can be communicatively coupled to more than one PSP. Therefore, one or more PSP's can connect to a particular SDM 3.10 hosted by the P2PEG 3.9, if the merchant environments being served by the respective PSP's are connected to PED5 that implement a similar encryption technique. If there are many SDMs, then each one can be connected to a plurality of FSF's that require the decryption key provided by it.

This aspect of the P2PEG 3.9 allows the P2PEG 3.9 to also act as a switch, and can be configured to switch between different PSP5 to send TX5 to different PSP5. Thus, a particular merchant environment need not be limited to using just one PSF for payment transactions, but their transactions can be sent to different PSPs that are capable of servicing these payments. The P2PEG 3.9 can switch between PSPs based on volume of transactions passing through the P2PEG 3.9, time of day, etc. to minimise network congestion and make efficient use of the communication network. This aspect of the first embodiment can also minimise the amount of network resources by routing transactions to a PSP such that the amount of network resources used is kept to a minimum. Furthermore, by being capable of such switching between PSP's for processing payment transactions, the P2PEG 3.9 can provide a continuous service for one or more merchant environments, as in case a merchant's chosen PSP is inaccessible or out of service due to any technical or service fault, downtime etc., the P2PEG 3.9 can simply switch to a different PSP that can process these payments for the merchant environment.

IV. Second Embodiment of the invention A system for implementing PCI DSS compliant point-to-point encryption (P2PE) for processing card-present payments using a secure gateway (P2PEG) As seen in figure 4, the system for processing card-present transactions implementing P2PE comprises a secure decryption module (SDM) 4.10 that is hosted by a gateway, i.e. P2PEG 4.9, which is similar to the gateway 3.9 of the first embodiment of figure 3.

The P2PEG 4.9 including the SDM 4.10 is connected to the merchant environment and the PSP 4.12 using a wired or wireless communication network. The components and working of the system according to the second embodiment of the present of the present invention is explained below.

Some components of the system of figure 4 are similar to the existing P2PE system as seen in figure 2a. Therefore this system also comprises a Pin Entry Device (PED) 4.4 connected to the merchant's Point-of Sale (POS) systems 4.6, which is in turn connected to the merchant Backend systems (BE) 4.8 and/or other IT systems.

In the system according to the second embodiment of the present invention, The merchant's BE systems 4.8 is connected using a communication network such as the Internet or a WLAN network to a P2PEG 4.9 via a suitable interface. This P2PEG 4.9 incorporates the 5DM 4.10. For ease of explaining the transaction process of the second embodiment, the 5DM 4.10 is shown separate from the P2PEG, i.e. outside the gateway. However, it is understood that this 5DM 4.10 is provided within/hosted by the P2PEG 4.9. This P2PEG 4.9 is connected to the PSP 4.12 via a suitable network. The PSP 4.12 is then connected to a Payment Network (PN) 4.14 of the Issuing bank and the Acquiring bank for obtaining the requested funds.

As with the existing P2PE system of figure 2a, the PED5 4.4 in this figure 4 are configured to apply an encryption to any sensitive cardholder data before passing it on to the P05 systems 4.6. The P05 systems 4.6 and any software associated with this in the merchant environment will also require to be configured such that the POS systems 4.6 are able to pass this encrypted data through the merchant environment.

The SDM 4.10 in the P2PEG 4.9 is preconfigured to generate, store, access and apply decryption keys that are specific to the encryption provided by the PEDs 4.4. This P2PEG 4.9 with the SDM 4.10 is the destination node, or the end point of the point-to-point encryption (P2PE), and no other systems or components of the systems are capable of deciphering the encrypted cardholder data.

The numbers of the steps below correspond to the flow arrows of figure 4, which depict the preferred steps taking place for processing a card-present payment. Some of the steps for the transactions and the terms used to explain these steps are similar to the existing P2PE systems of figure 2a, so these standard steps and terms there will not be explained again here.

S4-1. P05 systems 4.6 request payment from PED 4.4 for a transaction (same as S2-1).

S4-2. PED 2.4 requests authorisation (offline) of payment with Integrated Circuit Card (ICC) (Same as S2-2).

S4-3. If authorised, the PED 2.4 encrypts the sensitive card holder data using a predefined encryption technique, and the authorised Transaction (TX) with sensitive data encrypted using P2PE & Transaction Certificate (TO) is then returned to POS 4.6 from the PED 4.4. The reference to TX in the below steps refers to the transaction with encrypted cardholder data. This is the first point of the point-to point encryption being applied (Same as S2-4).

The payment card can be removed after this step.

54-4. TX + TC are then stored in BE systems 4.8 (similar to S2-4).

54-5. This step is different to the related step in the existing systems, as from this point onwards the merchant environment interacts with the P2PEG 4.9. In this step, the TXs with lOs are transmitted to the P2PEG 4.9. (The lXs and TCs are usually sent in batches, but this does not preclude one TX and TO pair to be sent at a time to the P2PEG 4.9).

Thus, contrary to the system in figure 2a, the merchant environment in figure 4 connects to the P2PEG 4.9 instead of the PSP 4.12. The information flow to the P2PEG 4.9 from the merchant environment is re-directed in this embodiment using the techniques described above in the gateway according to the first embodiment (P2PEG 3.9), such that no significant changes are required to be made to the POS 4.6 and BE 4.8 in the merchant environment. For instance, such re-direction can be achieved by using DNS changes in the merchant environment, i.e. such that for instance, "www.psp.com" resolves to 1.2.3.4 (the hosted service provided by P2PEG 4.9).

Otherwise, the re-direction can be achieved by providing a new URL (say "www.psp.hostedgateway.com") for the P2PEG 4.9. The redirection techniques according to the first, second or third example explained above in relation to P2PEG 3.9 of the first embodiment are implemented in this step.

S4-6. In this step, the P2PEG 4.9 is configured to send the P2PE protected TX data to the SDM 4.10 present in the gateway for decryption.

S4-7. This step represents the end-point of the point-to point encryption of figure 4.

Upon receipt of the P2PE encrypted sensitive /cardholder data, the 5DM 4.10 is configured to generate or access the appropriate decryption keys stored in the SDM 4.10. The SDM 4.10 then applies the necessary keys to the encrypted TX data to decrypt the cardholder data. Once the TX data is decrypted, this decrypted TX data is returned to the P2PEG 4.9 for further handling. The flow of data following this step will be within the scope of PCI DSS (as it is no longer encrypted) and is required to be handled accordingly.

Therefore, by the above steps 54-5 to 54-7 complete P2PE is obtained as compliant with PCI DSS without involving the PSP 4.12 and without requiring any change to the PSP's systems 4.12. Also, the merchant environment can simply redirect communications to the P2PEG 4.9 efficiently, securely and easily using any one of the above described re-direction techniques, rather than connecting to the PSP 4.12.

S4-8. In this step, the P2PEG 4.9 sends the decrypted TX + TC to the PSP 4.12 via a suitable communication network. Thus, the PSP receives the transactions in a format that it can handle without making any changes to the PSF system architecture, while at the same time being able to provide its merchants with fully operational P2PE for their transactions, thereby allowing the merchant environment to be de-scoped of cardholder data or sensitive information, thereby simplifying the process and costs of compliance S4-9. The PSP 4.12 then proceeds to acquire funds from Payment Network (PN) 4.14 (same as 52-8) S4-10. The PN 4.14 then returns confirmation/errors related to the transaction to PSP 4.12 (same as S2-7) 54-11. The FSP 4.12 then returns these confirmations/errors to the P2PEG 4.9 via a suitable interface, as the PSP 4.12 is connected to the merchant environment only via the P2PEG 4.9.

S4-12. The P2PEG 4.9 then returns these confirmations/errors to the merchant's BE systems 4.8.

If an online authorisation is requested, then Step 54-2 will be replaced with the following steps as shown at the bottom of figure 4.

S4-2a. When online authorisation is required, the PED 4.4 accesses the payment card 4.2 and encrypts the cardholder data, i.e. the sensitive data in the TX with unique encryption keys for P2PE. The authorisation Request Cryptogram (AROC) is sent to the PED 4.4 from the ICC in the card 4.2. Thus, the TX with P2PE data & ARQC are received at the PED 4.4. The TX in the following steps refers to a transaction including the encrypted sensitive data.

S4-2b. The PED 4.4 sends TX with P2PE data & ARQC to POS 4.6 (same as S2-2b).

S4-2c. The P05 4.6 sends TX with P2PE data & AROC to BE 4.8 (optional, and same as S2-2c).

S4-2d. From this step onwards, the merchant environment interacts (POS and BE systems) interact with the P2PEG 4.9 lather than their FSP 4.12. Thus, this step is different from the online authorisation process of figure 2a. In this step, the POS 4.6 or BE 4.8 sends the TX with P2PE data & AROC to the P2PEG 4.9.

S4-2e. Once the transaction reaches the P2PEG 4.9, the sensitive data of the TX is passed to the 5DM 4.10 within the P2PEG 4.9 for decryption.

S4-2f. The 5DM 4.10 in the P2FEG generates or accesses the unique key required for decrypting the encrypted data, and returns decrypted TX data to the P2PEG 4.9 for further handling. Thus this is the end -point of the P2PE functionality for online authorisation, to ensure that all sensitive data flow through the merchant environment is encrypted and therefore de-scoped from PCI DSS.

54-2g. The P2PEG 4.9 then proceeds to pass the decrypted TX and the ARQC to the PSP 4.12.

S4-2h. The PSP 4.12 authorises the TX with PN 4.14 (same as S2-2g).

S4-2i. The PN 4.14 returns the authentication code (AC) & Authorisation Response Cryptogram (ARPC) to the PSP 4.12 (same as S2-2h) S4-2j. The PSP 4.12 returns Merchant Defined tags, AC & ARPC to the P2PEG 4.9.

S4-2k. The P2PEG 4.9 returns Tags, AC & ARFC to the BE 4.8.

S4-21. BE 4.8 returns Tags, AC & ARPC to POS 2.6 (same as S2-2j).

S4-2m. POS 2.6 returns Tags, AC & ARPC to PED 2.4 (same as 52-2k) S4-2n. The card 2.2 validates the ARPC and requests the TC from ICC (same as 52-21).

V. Third Embodiment of the Invention: A subsystem for implementing PCI DSS compliant point-to-point encryption (P2PE) for processing card-present payments using a secure interface or bridge (PEB) and a secure gateway (P2PEG) In the first and second embodiments of the present invention depicted in figures 3 and 4, respectively, it was seen that in order to achieve P2PE, the P05 and/or BE systems in the merchant environment are required to be pre-configured to allow for receiving, transmitting as well as handling of P2PE encrypted transaction data from the PEDs, so that such encrypted data is capable of being sent through the merchant environment to the secure gateway P2PEG for transaction processing. Thus the first and second embodiments are applicable to a merchant environment that is already preconfigured for handling P2PE. However, merchant environments implementing a traditional EMV system for processing card transactions, such as shown in figure la, will not have the necessary P05 and BE systems that will allow encrypted TX data to pass through the merchant environment. Thus, if such merchants wish to switch to a P2PE system to be de-scoped from PCI DSS using the P2PEG gateway in figures 3 and 4, the first step would be the need to reconfigure the POS and/or BE systems in the merchant environment so that it is capable of handling encrypted data.

The third embodiment of the present invention provides a subsystem for implementing P2PE for all transactions involving sensitive data without requiring any change to the existing P03 and/or BE systems in the merchant environment.

The third embodiment also includes a secure gateway similar to the P2PEG 3.9 and 4.9 seen in figures 3 and 4, so therefore F2FE can be achieved with no changes being required to the PSP systems (this was already explained in detailed in sections III and IV of the detailed description) and no changes to the traditional merchant environment.

Thus, both traditional cardholder-present merchant environments as well as traditional PSP's can both obtain P2PE just by plugging in or communicating with the subsystem according to this embodiment.

The subsystem according to the third embodiment is seen in figure 5 of the accompanying drawings. Figure 5 shows a PED 5.4 connected to a traditional merchant environment, i.e. a P03 5.6 and a BE 5.8. As with the PED5 in figures 2a, 3 and 4, the PED here is capable of encrypting sensitive card holder data. A subsystem according to this embodiment comprises a secure interface device 5.5 hereinafter known as a pin entry bridge (FEB) that is capable of being connected between the PED 5.4 and the P03 5.6. The subsystem also includes a secure gateway P2PEG 5.9.

The gateway according to the third embodiment includes one or more SDMs 5.10 (as is the case with the P2PEG in figures 3 and 4) and additionally includes a tokenisation module 5.11. This tokenisation module hosted in the P2PEG 5.9 along with the 3DM 5.10, in combination with the PEB 5.5 allows for a complete P2PE implementation without requiring any substantial changes to be made to the merchant environment or the FSF's systems.

The secure interface device or PEB 5.5 is arranged to be connected between the PED 5.4 and P03 5.6. Thus, in use, the PEB 5.5 connects to the PED 5.4 as if it were the P03 5.6. Likewise, the PEB connects to the P03 5.6 as though it were the FED 5.4.

Thus, this device 5.5 acts as a proxy for both the FED 5.4 as well as the P03 5.5 such that each one detects it as if it were the other. In addition to this, the PEB 5.5 also has a communication link with the secure gateway P2PEG 5.9 such that it can directly send and receive information from the P2PEG 5.9, thereby bypassing the merchant payment systems. This link is also referred to as a "direct communication link", by which it is to be understood that communication does not take place through the existing merchant payment processes (which includes P03 5.6 and BE 3.8 and possibly other systems).

This "direct" communication link may be routed via other modules or routing devices etc., as long as it bypasses the merchant payment processes. (It should not be inferred that this link is necessarily a direct physical connection between the PEB and the P2PEG.) When a payment is to be processed by the PED 5.4, encryption is applied such that the sensitive data in the transaction is encrypted for P2PE. Then, instead of being sent to the merchant environment, the PED 5.4 sends this encrypted data to the proxy interface, i.e. the PEB 5.5. Once this is received at the PEB 5.5, the encrypted transaction is sent directly to the P2PEG 5.9 via the direct communication link.

Therefore, by bypassing the POS terminal, the merchant environment now no longer has to handle P2PE encrypted data.

In the subsystem of the third embodiment, once the P2PE encrypted transaction data arrives at the P2PEG 5.9 from the PEB 5.5, this encrypted sensitive data is stored in the P2PEG 5.9 in a suitable secure storage module. The tokenisation module 5.11 then generates a unique token to replace this encrypted sensitive transaction data and returns this non-sensitive token back to the PEB 5.5 via the communication link. Upon receipt of this token from the P2PEG 5.9, the PEB 5.5 sends this non-sensitive non-encrypted token to the POS system 5.6 for further handling via the merchant environment. This token will be in a data format that is recognised by the POS 5.6 as a standard card number that has to be passed on for processing (such as in figure la).

Thus, the POS 5.6 will send this token to the BE 5.8 which will in turn transmit this token to the P2PEG 5.9 via a suitable communication network. Upon receiving this token, the tokenisation module 5.11 in the P2PEG 5.9 is configured such that it recognises this unique token as being for a particular transaction, and based on this, the tokenisation module 5.11 retrieves the stored encrypted transaction data for that particular transaction. Once this is done, the SDM 5.10 in the P2PEG 5.9 generates or accesses the decryption key required for that encrypted data and then proceeds to decrypt the P2PE protected sensitive data for the transaction. Following this, The SDM 5.10 returns the decrypted transaction to the P2PEG 5.9 for further handling.

Thus, the PED 5.4 and the P2PEG 5.9 incorporating the 5DM 5.10 are still the two end points of the P2PE implementation, as in embodiments shown in figures 3 and 4.

However, by incorporating a proxy interface such as a PEB 5.5 with a link to the P2PEG 5.9 that in addition also incorporates a tokenisation module 5.11, PCC-DSS compliant P2PE can be implemented with no substantial change to a traditional merchant payment environment, or to the traditional PSP system.

As with the first embodiment, the P2PEG 5.9 of the third embodiment can also be configured to include more than one SDM and can be configured to be connected to a plurality of merchant environments as well as to a plurality of PSPs.

In a further aspect, the information flow to the P2PEG 5.9 from the merchant environment can be re-directed using the techniques described above in relation to the first embodiment, such that no significant changes are required to be made to the POS 5.6 and BE 5.8 in the merchant environment to enable communication with the P2PEG 5.9. As explained above, in the present embodiment the merchant environment requires transmitting the non-encrypted tokens to the P2PEG 5.9 rather than the PSP 5.12. Therefore, the re-direction to the P2PEG 5.9 can be achieved by using DNS changes in the merchant environment, i.e. such that for instance, "w.psp.com" resolves to 1.2.3.4 (the hosted service provided by P2PEG 5.9). Otherwise, the re-direction can be achieved by providing a new URL (say "ww.psp.hostedgateway.com") for the P2F'EG 5.9. Any of the redirection techniques described in the first, second or third example for the P2PEG 3.9 of the first embodiment apply equally to the P2PEG 5.9 of the third embodiment for the redirection of the non-encrypted tokens to the P2PEG 5.9.

VI. Fourth Embodiment of the invention A system for implementing PCI DSS compliant point-to-point encryption (P2PE) for processing card-present payments using a secure interface or bridge (PEB) and secure gateway (P2PEG) As seen in figure 6, the system for processing card-present transactions implementing P2PE comprises a tokenisation module 6.11 that is hosted by a gateway, i.e. P2PEG 6.9, which is similar to the P2PEG 5.9 of figure 5. For ease of explaining the transaction process of the fourth embodiment, the tokenisation module 6.11 is shown separate from the P2PEG, i.e. outside the gateway. However, it is understood that this tokenisation module 6.11 can be provided within/hosted by the P2PEG 6.9. As shown, the P2PEG 6.9 also includes 3DM 6.10. In addition, a proxy interface such as PEB 6.5 is connected between a PED 6.4 and a POS system 6.6 in the merchant environment.

This PER 6.5 is communicatively coupled to the P2PEG 6.9 via a communication link.

The tokenisation module 6.11 replaces encrypted card holder data received from the PEB 6.5 with a non-sensitive non-encrypted token, and this token is passed through the merchant environment so that the merchant environment recognises and handles this token like a normal cardholder-present payment.

As with the existing P2PE system of figure 2a and the system according to the embodiment in figure 4, the PEDs 6.4 in figure 6 are configured to apply an encryption to any sensitive cardholder data before it passes it on. However, unlike the second embodiment, the sensitive encrypted card holder data is not passed on to the merchant environment, but is instead passed to the proxy interface PER 6.5. From the PEB 6.5, the encrypted TX data is sent via the direct link to the P2PEG 6.9 where the tokenisation module 6.5 is configured to generate a non-encrypted token for the encrypted transaction received from the FEB 6.5. Thus, the combination of the FEB 6.5 and tokenisation module 6.11 provide a token that can pass through the merchant environment instead of the encrypted sensitive data. When this token reaches the P2PEG 6.9 from the merchant environment, the tokenisation module 6.11 performs de-tokenisation to obtain the P2PE encrypted sensitive data. This data is then passed on to the SDM 6.10 for decryption in the same way as set out in relation to figures 4 and 5.

The numbers of the steps below correspond to the flow arrows of figure 6, which depict the preferred steps taking place in the system for processing a card-present payment.

Some of the steps for the transactions and the terms used to explain these steps are similar the systems of figure 4, so these standard steps and terms there will not be re-iterated in detail here.

Se-i. P05 system 6.6 requests payment from PEB 6.5 for a transaction. The POS requests this information from this proxy interface because the PER 6.5 when connected to the P05 6.6 acts as though it were the PED 6.4.

S6-2. The FEB 6.5 in turn requests the payment from the FED 6.4.

S6-3. PED 2.4 then requests authorisation (offline) of payment with Integrated Circuit Card (ICC) (Same as S4-2).

S6-4. If authorised, the FED 6.4 encrypts the sensitive card holder data using a predefined encryption technique, and the authorised Transaction (TX) with sensitive data encrypted using P2PE & Transaction Certificate (TC) is then returned to PEB 6.5.

The reference to TX in the below steps refers to the transaction with encrypted cardholder data. This is the first point of the point-to point encryption being applied.

The payment card can be removed after this step.

S6-5. TX with encrypted data + TC are then sent via the link between the FEB 6.5 and the P2PEG 6.5. The tokenisation module 6.11 in the P2PEG 6.9 generates a unique token for this encrypted transaction data. This token replaces the encrypted TX data for the particular transaction. This TX with encrypted data is then stored in the P2PEG 6.9 in a suitable secure storage means and the non-sensitive and non-encrypted token is returned to the FEB 6.5.

S6-6. The tokenised TX i.e. the transaction where the encrypted sensitive data is now replaced with a token, along with the TC is then sent to the POS 6.6.

S6-7. The tokenised TX and TC are passed on to the BE 6.8.

S6-8. The tokenised TX with TC is transmitted to the F2FEG 6.9. (The TXs and TCs are usually sent in batches, but this does not preclude one TX and TC pair to be sent at a time to the P2PEG 6.9).

In a further preferred aspect, the information flow to the P2PEG 6.9 from the merchant environment is re-directed in this embodiment using the techniques described above in the gateway according to the first embodiment (F2FEG 3.9), such that no significant changes are required to be made to the P05 6.6 and BE 6.8 in the merchant environment. For instance, such re-direction can be achieved by using DNS changes in the merchant environment, i.e. such that for instance, www.psp.com" resolves to 1.2.3.4 (the hosted service provided by F2PEG 6.9). Otherwise, the re-direction can be achieved by providing a new URL (say "www.psp.hostedgateway.com") for the F2FEG 4.9. Any of the redirection techniques according to the first, second or third example explained above in relation to P2PEG 3.9 of the first embodiment can be implemented in this step.

S6-9. The tokenisation module 6.11 in the P2PEG 6.9 accesses the tokenised TX. As this token is unique to the particular transaction, the tokenisation module 6.11 de-tokenises this to return the encrypted sensitive data of that particular transaction. The TX with encrypted sensitive data is obtained and this is sent to the SDM 6.10, which is also present in the P2PEG 6.9, for decryption.

S6-10. This step represents the end-point of the point-to point encryption of system 6.

Upon receipt of the P2PE encrypted sensitive /cardholder data, the SDM 6.10 is configured to generate or access the appropriate decryption keys. The SDM 6.10 then applies the necessary keys to the encrypted TX data to decrypt the sensitive data.

Once this data is decrypted, this decrypted TX is returned to the P2PEG 6.9 for further handling. The flow of data following this step will be within the scope of PCI DSS (as it is no longer encrypted) and is required to be handled accordingly.

Therefore, by the above steps P2PE is obtained without involving the PSP 6.12 and without requiring any change to the PSPs systems 6.12. Also, no change is required to the merchant's payment environment, and any existing POS + BE can simply connect to the PEB 6.5 and P2PEG 6.9 to obtain P2PE de-scoping.

The following steps are similar to steps 54-8 to 54-11 in figure 4: S6-11. The P2PEG 6.9 sends the decrypted TX + TC to the PSP 6.12 via a suitable communication network.

56-12. The PSP 6.12 then proceeds to acquire funds from Payment Network (PN) 6.14.

56-13. The PN 6.14 the returns confirmation/errors related to the transaction to PSP 6.12.

56-14. The PSP 6.12 then returns these confirmations/errors to the P2PEG 6.9 via a suitable third party gateway interface, as the PSP 6.12 is connected to the merchant environment only via the P2PEG 6.9.

S6-15. The P2PEG 6.9 then returns these confirmations/errors to the merchant's BE systems 6.8.

If an online authorisation is requested, then Step 56-3 will be replaced with the following steps as shown at the bottom of figure 6.

When an online or real time payment authorisation from the issuer is required, this request and authorisation also needs to pass through the system components such that sensitive information is blocked or encrypted. The following modifications to the information flow may be required for the system in figure 6 to ensure that the sensitive cardholder data does not flow through the merchant environment, as the merchant environment is not suited for handling encrypted sensitive data.

S6-3a. When online authorisation is required, the FED 6.4 accesses the payment card 6.2 and encrypts the cardholder data, i.e. the sensitive data in the TX with unique encryption keys for P2PE. The Authorisation Request Cryptogram (AROC) is sent to the FED 6.4 from the ICC in the card 6.2. Thus, the TX with F2FE data & ARQC are received at the PED 6.4. The TX in the following steps refers to a transaction including the encrypted sensitive data.

S6-3b. The FED 6.4 sends TX with F2FE data & ARQC to the FEB 6.5.

56-Sc. The PEB 6.5 sends TX with P2PE data & ARQC to the P2PEG 6.9.

S6-3d. Once the transaction reaches the P2PEG6.9, the sensitive data of the TX is passed to the 5DM 6.10 within the gateway for decryption.

56-Se. The 5DM 6.10 in the P2PEG generates or accesses the unique key required for decrypting the encrypted data, and returns decrypted TX data to the P2PEG 6.9 for further handling. Thus this is the end -point of the P2FE functionality for online authorisation, to ensure that all sensitive data flow is encrypted and therefore F2FE compliant. The merchant environment is de-scoped from this encrypted data, as this the FEB bypasses the FOS 6.6 and BE 6.8 and instead directly sends the TX with P2PE data to the P2PEG 6.9.

S6-3f. The P2PEG 6.9 then proceeds to pass the decrypted TX and the AROC to the FSF 6.12.

S6-3g. The PSP 6.12 authorises the TX with PN 6.14.

S6-3h. The PN 6.14 returns the authentication code (AC) & Authorisation Response Cryptogram (ARPC) to the PSP 6.12.

S6-3i. The PSP 6.12 returns Merchant Defined tags, AC & ARPC to the P2PEG 6.9.

S6-3j. The P2PEG 6.9 sends the Tags, AC & ARPC to the PEB 6.5 via the communication link.

S6-3k. The FEB 6.5 returns Tags, AC & ARFC to the FED 6.4.

S6-31. The card 6.2 validates the ARPC and requests the TC from ICC.

The flow of data for transactions using the system of figure 6 can be seen in figure 7.

This figure shows the data handled and processed by the components of the system of figure 6. Sensitive cardholder data, card data as well as other types of data, i.e. the cryptograms, etc. are shown in figure 7. This data flow shown corresponds to authorisation transaction steps shown in figure 6.

While certain embodiments have been described, these embodiments have been presented by way of example only, and are not intended to limit the scope of the inventions. Indeed, the novel devices, methods, and products described herein may be embodied in a variety of other forms; furthermore, various omissions, substitutions and changes in the form of the methods and systems described herein may be made without departing from the spirit of the inventions. The accompanying claims and their equivalents are intended to cover such forms or modifications as would fall within the scope of the embodiments.

Claims (28)

1. CLAIMS: 1. A gateway for providing point to point encryption (P2PEG) 3.9 for the communication of sensitive data for card-present transactions from a card reading device 3.4 to a transaction processing system 3.12 using a communication network, the sensitive data for a transaction being encrypted at the card reading device 3.4 such that said encrypted transaction data is transmitted from the card reading device 3.4 through a merchant environment (3.6, 3.8) towards the transaction processing system 3.12; wherein the encrypted transaction data is redirected via the P2PEG 3.9, and wherein the P2PEG 3.9 comprises a secure decryption module (3DM) 3.10 for accessing a decryption key for decrypting the encrypted transaction data; and wherein, responsive to the receipt of the encrypted transaction data at the P2PEG 3.9, the SDM 3.10 is configured to decrypt the encrypted transaction data such that the decrypted transaction with the sensitive data is transmitted to the transaction processing system 3.12 via the P2PEG 3.9 using the communication network.
2. 2. The gateway as claimed in claim 1, wherein said P2PEG 3.9 is a hosted service that is arranged to act as the end point for point to point encryption (P2PE) of the sensitive data instead of the transaction processing system 3.12.
3. 3. The gateway as claimed in claims 1 or 2, wherein the P2PEG 3.9 is capable of being communicatively connected to the merchant environment (3.6, 3.8) and the transaction processing means using the communication network via suitable interfaces such that the encrypted transaction data is received from the merchant environment and the decrypted transaction is forwarded to the transaction processing system 3.12.
4. 4. The gateway as claimed in any of the preceding claims, wherein the P2PEG 3.9 is capable of being communicatively connected to one or more merchant environments and/or to one or more transaction processing systems 3.12.
5. 5. The gateway as claimed in claim 4, wherein the P2PEG 3.9 is configured to select one of a plurality of transaction processing systems 3.12 connected to it based on a defined condition and to forward the decrypted transaction to the selected system 3.12.
6. 6. The gateway as claimed in claim 5, wherein if the selected transaction processing system 3.12 no longer meets the defined condition, the P2FEG 3.9 is configured to switch to another transaction processing system that meets such condition.
7. 7. The gateway as claimed in any of the preceding claims, wherein the sensitive data is cardholder data from a payment card 3.2 and wherein the transaction processing system is a payment service provider (PSP) 3.12.
8. 8. The gateway as claimed in any of the preceding claims wherein the P2PEG 3.9 includes a plurality of SDMs (3.10), each 3DM 3.10 being capable of generating or storing decryption keys for encrypted transaction data received from a merchant environment, such that each SDM 3.10 is capable of decrypting transaction data received from a merchant environment that is different to the other merchant environments.
9. 9. A system for providing point to point encryption (P2PE) for the communication of sensitive data for card-present transactions in a communication network, the system including a gateway for point to point encryption (P2PEG) 4.9 as claimed in any of the preceding claims, the system further comprising: a card reading device 4.4 that is capable of interacting with a card 4.2 having sensitive data stored on it such that the card reading device 4.4 is configured to access and encrypt the sensitive data for a transaction using an encryption key that is unique for a particular transaction; a merchant environment including a point of sale system (POS) 4.6 connected to backend systems (BE) 4.8, wherein the card reading device 4.4 is connected to the P03 4.6, and the P03 4.6 and/or BE 4.8 is connected to the P2PEG 4.9 such that encrypted transaction data is transmitted from the card reading device 4.4 through the merchant environment (4.6, 4.8); and a transaction processing system 4.12 connected to the P2PEG 4.9, wherein said encrypted transaction data is transmitted through the merchant environment (4.6, 4.8) towards the transaction processing system 4.12 and wherein the encrypted transaction data is redirected via the P2PEG 4.9, the P2PEG 4.9 configured such that, responsive to decryption of the encrypted transaction data in the 3DM 4.10, the P2PEG 4.9 transmits the decrypted transaction to the transaction processing system 4.12, said transaction processing system 4.12 being capable of communicating with an external network 4.14 to authorise and process the transaction, the transaction processing system further configured to return the results of said transaction to the merchant environment via the P2PEG 4.9.
10. 10. The system as claimed in claim 9 wherein the card reading device is a pin entry device (PED) 4.4 for reading data from a payment card 4.2.
11. 11. The system as claimed in claim 10 wherein the transaction processing system is a payment service provider (PSP) 4.12 capable of processing card-present payment transactions for a merchant environment.
12. 12. The system as claimed in claim 11 wherein the external network is a payment network 4.14 for authenticating payment transactions and acquiring funds for a merchant environment.
13. 13. A method for providing point to point encryption (P2PE) for the communication of sensitive data for card-present transactions in a communication network, the method being implemented in the system claimed in any one of claims 9 to 12, the method comprising the steps of: initiating a transaction at the card reading device 4.4 by inserting or swiping a card 4.4 at the device 4.4; accessing sensitive data from the card 4.2 by the card reading device 4.4; encrypting the sensitive data using a unique encryption key for the transaction at the card reading device 4.4; transmitting encrypted transaction data from the card reading device 4.4 through the merchant environment towards a transaction processing system 4.12; redirecting the encrypted transaction data via the P2PEG 4.6; accessing or generating decryption keys for the encrypted transaction data by the SDM 4.10 in the P2PEG 4.9; decrypting the encrypted transaction data using the decryption keys in the SDM 4.10; transmitting the decrypted transaction to the transaction processing system 4.12; processing the decrypted transaction at the transaction processing system 4.12 by communicating with an external network for authorising the transaction; returning the result of said transaction by the transaction processing system 4.12 to the merchant environment via the P2PEG.
14. 14. The method as claimed in claim 13 wherein, prior to transmitting the encrypted transaction to the merchant environment, the method comprises the steps of: requesting an online authorisation of the of the card transaction by the card reading device; communicating with an external network via the merchant environment, the P2PEG 4.9 and the transaction processing system 4.14; verifying the validity of the transaction by the external network 4.14; and returning the result of such verification to the card reading device 4.4 via the communication network.
15. 15. The method as claimed in claim 13 wherein, prior to transmitting the encrypted transaction to the merchant environment, the method comprises the steps of: requesting an offline authorisation of the card transaction by the card reading device communicating with the integrated circuit card 4.2 to verify the validity of the transaction; and returning the result of such verification to the card reading device 4.4.
16. 16. A subsystem for providing point to point encryption F2PEG for the communication of sensitive data for card-present transactions from a card reading device 5.4 to a transaction processing system 5.12 using a communication network, the sensitive data for a transaction being encrypted at the card reading device 5.4; said subsystem comprising a gateway for providing point to point encryption (P2PEG) 5.9 and a secure interface device 5.5 connected to each other by a communication link; wherein the secure interface device 5.5 is capable of being communicatively connected to the card reading device 5.4 and a merchant environment such that it is capable of receiving the encrypted transaction data from the card reading device 5.4 and sending the encrypted transaction data to the P2PEG 5.9 via the communication link; the P2PEG 5.9 comprises a tokenisation module 5.11 configured to replace the received encrypted transaction data with a non-encrypted token and to return said token to the secure interface device 5.5 for foiwarding to the merchant environment; said merchant environment being communicatively connected to the P2PEG 5.9 such that said token is received at the P2PEG 5.9; the tokenisation module 5.11 is further configured to retrieve the encrypted transaction data corresponding to the token, responsive to receiving the token from the merchant environment; the P2PEG 5.9 further comprises a secure decryption module (SDM) 5.10 for accessing a decryption key for decrypting the encrypted transaction data, and wherein, responsive to the retrieval of the encrypted transaction data by the tokenisation module 5.11, the SDM 5.10 is configured to decrypt the encrypted transaction data such that the decrypted transaction with the sensitive data is transmitted to the transaction processing system 5.12 via the communication network.
17. 17. The subsystem as claimed in claim 16 wherein said token is transmitted from the secure interface device 5.5 through the merchant environment for further transmission to the P2PEG 5.9.
18. 18. The subsystem as claimed in claim 16 wherein said token is transmitted from the secure interface device 5.5 through the merchant environment towards the transaction processing system 5.12, and wherein token is redirected via the P2PEG 5.9.
19. 19. The subsystem as claimed in any one of claims 16 to 18 wherein the secure interface device is a pin entry bridge (FEB) 5.5 that is configured to connect the card reading device 5.4 and the merchant environment such that all communication between them takes place through the PEB 5.5.
20. The subsystem as claimed in any one of claims 16 to 19 wherein the secure interface device may be incorporated within the card reading device 5.4.
21. 21. The subsystem as claimed in claims 16 to 19 wherein the secure interface device may be incorporated within the point of sale (POS) system 5.6.
22. 22. The subsystem as claimed in any one of claims 16 to 21 wherein the F2PEG 5.9 further comprises storage means for storing the encrypted card data that has been replaced with the token by the tokenisation module 5.11, such that said encrypted data can be retrieved when the token is returned to the P2PEG 5.9 by the merchant environment.
23. 23. The subsystem as claimed in any of the claims 16 to 22 wherein the sensitive data is cardholder data from a payment card 5.2 and wherein the transaction processing system is a payment service provider (PSP) 5.12.
24. 24. A system for providing point to point encryption (P2PE) for the communication of sensitive data for card-present transactions in a communication network, the system including a subsystem for providing point to point encryption as claimed in any one of claims 16 to 23, the system further comprising: a card reading device 6.4 that is capable of interacting with a card 6.2 having sensitive data stored on it such that the card reading device 6.4 is configured to access and encrypt the sensitive data for a transaction using an encryption key that is unique for a particular transaction; a merchant environment including a point of sale system (POS) 6.6 connected to backend systems (BE) 6.8, the secure interface device 6.5 being connected to the card reading device 6.4 and POS 6.6, and the P05 6.6 and/or BE 6.8 being connected to the P2PEG 6.9, such that a non-encrypted token received from the tokenisation module 6.11 is received at the P2PEG 6.9; and a transaction processing system 6.12 connected to the P2PEG 6.9, the P2PEG 6.9 configured such that, responsive to decryption of the retrieved encrypted transaction data in the 5DM 6.10, the P2PEG 6.9 transmits the decrypted transaction to the transaction processing system 6.12, said transaction processing system 6.12 being capable of communicating with an external network 6.14 to authorise and process the transaction, the transaction processing system further configured to return the results of said transaction to the merchant environment via the P2PEG 6.9.
25. 25. The system as claimed in claim 24 wherein the card reading device is a pin entry device (PED) 6.4 for reading data from a payment card 6.2.
26. 26. The system as claimed in claim 25 wherein the transaction processing system is a payment service provider (PSP) 6.12 capable of processing card-present payment transactions for a merchant environment.
27. 27. The system as claimed in claim 26 wherein the external network is a payment network 6.14 for authenticating payment transactions and acquiring funds for a merchant environment.
28. 28. A method for providing point to point encryption (P2PE) for the communication of sensitive data for card-present transactions in a communication network, the method being implemented in the system claimed in any one of claims 24 to 27, the method comprising the steps of: initiating a transaction at the card reading device 6.4 by inserting or swiping a card 6.4 at the device 6.4; accessing sensitive data from the card 6.2 by the card reading device 6.4; encrypting the sensitive data using a unique encryption key for the transaction at the card reading device 6.4; sending encrypted transaction data from the card reading device 6.4 to the secure interface device 6.5; transmitting the encrypted transaction data from the secure interface device 6.5 to the P2PEG 6.9 via a communication link; replacing the encrypted transaction data with a non-encrypted token by the tokenisation module 6.11 in the P2PEG and storing the encrypted transaction data in the P2PEG 6.9; returning the token to the secure interface device 6.5; transmitting the token from the secure interface device 6.5 to the merchant environment; transmitting the token from the merchant environment to the P2PEG 6.9, or redirecting the token from the merchant environment via the P2PEG 6.9; retrieving the encrypted transaction data using the token by the tokenisation module 6.11; accessing or generating decryption keys for the encrypted transaction data by the SDM 6.10 in the P2PEG 6.9; decrypting the encrypted transaction data using the decryption keys in the SDM 6.10; transmitting the decrypted transaction to the transaction processing system 6.12 by the P2PEG 6.9; processing the decrypted transaction at the transaction processing system 6.12 by communication with an external network 6.14 for authorising the transaction; returning the result of said transaction by the transaction processing system 6.12 to the merchant environment via the P2PEG 6.9.