WO2018029011A1

WO2018029011A1 - Methods and systems for secure transaction processing

Info

Publication number: WO2018029011A1
Application number: PCT/EP2017/069087
Authority: WO
Inventors: Massimiliano COSTA; Victor KLETZER; Matthias Fritz; Garry Bryce BUCKLAND
Original assignee: Global Blue Sa
Priority date: 2016-08-12
Filing date: 2017-07-27
Publication date: 2018-02-15
Also published as: KR20190039753A; JP2019527895A; KR102180400B1; SG11201900938SA; GB201613863D0; JP6904636B2

Abstract

Handling of a Primary Account Number (PAN) in a PCI-DSS compliant manner is facilitated in which a merchant system does not hold a PAN while nevertheless enabling third party services that require knowledge of a PAN for conducting a transaction.

Description

METHODS AND SYSTEMS FOR SECURE TRANSACTION PROCESSING BACKGROUND

The present invention relates to methods, apparatus and systems for providing secure transaction processing.

Transactions effected using credit, debit and other payments accounts using payment cards such as credit or debit cards, or alternative payment devices such as mobile communications devices such as phones, watches, etc. that are provided with means for electronic payments (hereinafter referred to generically as payment cards) are subject to regulation in accordance with standards set by the Payment Card Industry (PCI) Security Standards Council.

The PCI Security Standards Council issues the PCI Data Security Standard (PCI- DSS), see https://www.pcisecuritystandards.org/document_library?document=pci_dss, which provides a framework for payment card data security processes, including prevention, detection and appropriate reaction to security incidents.

Maintaining systems to meet these standards is an onerous task. As a result of this, retail organisations typically use payment terminals that are separate from merchant front and back end systems (herein generically referred to as merchant systems). An example of a merchant front end system is a merchant point of sale (POS) terminal (e.g., an electronic cash register (ECR)). Examples of merchant back end systems can include inventory and accounting systems. The merchant systems such as an ECR do not store or process payment card numbers (the Primary Account Number, or PAN) used in a card transaction so that the merchant systems are therefore are out of PCI-DSS scope. Dedicated payment terminals are used to receive and process the PAN for a payment card transaction and to communicate in a secured manner with payment service provider (PSP) acquirer systems in accordance with the PCI-DSS. The PSP systems are then integrated with the card scheme (e.g., MasterCard, VISA, etc.) systems using secure channels in accordance with the PCI- DSS.

In some implementations, the merchant systems are completely separate from the payment terminals, in which case no electronic data passes between the payment terminals and the merchant systems. Typically, in such an implementation, the merchant enters the payment details (e.g., a transaction amount) manually into the payment terminal to conduct a card payment.

In other implementations, a degree of integration is provided whereby certain transaction details, such as a transaction amount can be passed from a merchant system to a payment terminal, and/or the payment terminal is configured to communicate selected information only to the merchant system. For example, selected information passed from a payment terminal to a merchant system can include an authorisation code for a transaction and a truncated part of the PAN (say the last four digits) to confirm authorisation of a payment using a card. However, in such a configuration, the full PAN is not passed to the merchant system in order that the merchant system does not have to be configured to meet the PCI-DSS.

Where additional, or specialised, services are provided by a third party, for example system of a service provider providing one or more specialised, specific or selected services (hereinafter referred to as a "special service provider", or "SSP" to differentiate such a service provider from a payment service provider (PSP) that forms part of a payment authorisation channel), for example a tax refund operator (TRO) system for providing a tax refund service for the refund of a general sales tax (GST) or value added tax (VAT), a dynamic currency choice service provider or the like, the merchant system can be configured to communicate with the SSP system. In such a configuration, the merchant system can provide information relating to the transaction, for example information concerning the amount of a transaction, the tax normally payable, a description of the goods, information determined at the point of sale regarding the eligibility of the payment card holder to receive a tax refund, etc., that are available to the merchant system. However, the PAN for the payment cannot be passed to the SSP system as this is not available to the merchant system. Accordingly, third party systems such as the SSP system are not able to provide services that may need use of the PAN.

There exists the technical problem, therefore, how to provide third party services associated with a payment transactions that may require the PAN, but where this is not available to a merchant system.

SUMMARY

Aspects of the invention are defined in the claims.

An embodiment of the claimed subject matter enables handling of a PAN in a PCI- DSS compliant manner where a merchant system does not hold a PAN, while enabling third party services to be provided by a SSP system that requires knowledge of a PAN for a transaction. As indicated above, the SSP system is a system of a service provider providing one or more specialised, specific or selected services out of band with respect to a payment authorisation channel. The SSP system can, for example, comprise one or more TRO host systems for providing a tax refund service (also referred to herein as a tax free service (TFS)). For example, TFS may be incorporated into the operation of a merchant system (e.g., an ECR) without a PAN needing to be captured by the ECR, thereby keeping the ECR out of the scope of the PCI-DSS. For payment, the PAN can be captured using a dedicated stand-alone or semi-integrated terminal. The PAN is not routed through the ECR and other merchant systems.

In an example, in response to a payment terminal routing payment transaction information including a PAN captured by the payment terminal to a PSP system (a payment service provider system in a payment authorisation channel), which then routes related information including the PAN to a card scheme system for authorisation, the PSP system returns to the payment terminal a unique reference (PREF) that maps to the PAN.

In one example the PREF is generated by the PSP system, in which case the PREF can be unique to the transaction or the PAN and the PSP. The PREF then maps to the PAN for the transaction using information held by the PSP system, which is held in a PCI- DSS compliant manner. Alternatively, the PREF can be generated to be unique to a PAN that is independent of the payment transaction itself, in which case the PREF then maps directly to the PAN using information held by the PSP system in a PCI-DSS compliant manner.

In another example the PREF is generated by the card scheme system, in which case the PREF can be unique to the transaction and the card scheme system. The PREF then maps to the PAN for the transaction using information held by the card scheme system, which is held in a PCI-DSS compliant manner. Alternatively, the PREF can be generated to be unique to a PAN that is independent of the payment transaction itself, in which case the PREF then maps directly to the PAN using information held by the card scheme system in a PCI-DSS compliant manner.

In an example, therefore, where the PREF is provided to the merchant system, the merchant system can then hold and pass to the authorised third party systems a PREF that can be used by a third party system that is authorised to communicate with the PSP systems and/or card scheme system, as appropriate, to obtain a mapping from the PREF to the PAN.

In a semi-integrated system, the payment terminal can be configured to transfer the

PREF (but not a full PAN) to the merchant system with conventional information authorising payment using the payment card concerned.

In a stand-alone system where the payment terminal is not connected to the merchant system, the payment terminal can be configured to print the PREF and/or a barcode, QR code, etc., that represents the PREF on a payment slip. In such a case, the merchant can then scan the PREF and/or the barcode, QR code, etc., representing the PREF to create a link between the payment transaction and the merchant records.

When the merchant system communicates with the SSP system, for example a TRO system for providing a TFS service, the PREF can be passed to the SSP system.

In this manner, a PREF that can map to the PAN for the payment transaction can be passed to the SSP system via the merchant system in a manner that is PCI-DSS compliant without the merchant system having itself to be PCI-DSS compliant.

The SSP system can then be in communication with the PSP system or the card scheme system, as appropriate, so as to link the PREF to the PAN held by the PSP system or the card scheme system, as appropriate, in a PCI-DSS compliant manner.

One or more aspects can be implemented by one or more computer programs that, when executed cause one or more computer system to carry out the one or more aspects.

BRIEF DESCRIPTION OF THE DRAWINGS

Example embodiments are described with reference to the accompany drawings.

Figure 1 is a schematic block diagram illustrating an example embodiment providing PSP system tokenisation in a transaction system ;

Figure 2, which comprises Figures 2A and 2B, is an example transaction flow diagram.

Figure 3 is a schematic block diagram illustrating another example embodiment providing PSP tokenisation in a transaction system;

Figure 4 is a schematic block diagram illustrating an example embodiment providing card scheme system tokenisation in a transaction system;

Figure 5 is a flow diagram illustrating and example method for generating a unique reference;

Figure 6 is a flow diagram illustrating another example method for generating a unique reference;

Figure 7 is an example of a unique reference to PAN mapping table. DETAILED DESCRIPTION

Figure 1 is a schematic block diagram of an example embodiment providing PSP system tokenisation in a transaction system. Figure 1 also illustrates a number of operations performed in the transaction system of Figure 1 .

A point of sale electronic cash register (ECR) 10 is a merchant system that provides the functions of a typical electronic cash register for the input of details of one or more products to be purchased by a customer or traveller (hereafter referred as a user). The ECR 10 is programmed to provide functions, for example in communication with one or more merchant systems (not shown), to compute a total value for purchases, compute tax payable etc., and also to perform functions of, for example, recording details of purchases, customers, inventory, etc. The ECR can include one or more processors, storage, user interface devices (e.g., displays, touch sensitive displays, keyboards etc.), communications interfaces (e.g., Ethernet, Wifi, Bluetooth, NFC readers, barcode scanners, etc.), etc.

In the example of Figure 1 , the ECR 10 is also configured, either directly or via other merchant systems, e.g. merchant server systems (not shown), to communicate with a special service provider (SSP) system, for example a tax refund operator host server system.

In the example of Figure 1 , in order that the ECR 10 does not have to be PCI-DSS compliant, the ECR 10 is configured so that it does not receive the full primary account number (PAN) of a user's payment card. Where reference is made to a "payment card", this term is used generically to refer to any payment device (e.g., a traditional debit, credit or pre-paid plastics card, mobile communications device incorporating electronic card wallets payment chips or the like) for electronic payments using, for example, a primary account number (PAN). With this in mind, transactions using a user's payment card are performed using an electronic funds transfer payment terminal (EFT) 20. The EFT 20 typically comprises a display, a keyboard for user entry, one or more communications interfaces for connection to one or more of a telephone line, a wired or wireless network, an ECR, etc., a card reader for reading one or more of a magnetic stripe on a payment card, a chip on the payment card via contacts or contactless (NFC) communication, etc., and a printer, for example a thermal printer. In the example of Figure 1 , the ECR 10 and the EFT 20 are interconnected and partial integration between the ECR 10 and the EFT 20 is provided so that certain information is passed between the ECR 10 and the EFT 20, but a full PAN is not communicated from the EFT 20 to the ECR 10 as will be described in more detail below.

In operation, when the purchase of goods is processed by the ECR 10, and a payment total is computed, the total value of the goods can then be passed electronically from the ECR 10 to the EFT 20. For example, a merchant may enter one or more goods (for example by scanning a barcode on each good using a using a barcode scanner of the ECR 10) and then operate a key on the ECR 10 to enable payment for the one or more goods using a payment card. The key can, for example, be a physical key switch on the ECR or a key displayed on a touch screen of an ECR. A message M1 is then sent from the ECR 10 to the EFT 20 that can include the total value of the goods in accordance with a conventional ECR-EFT message protocol. As will be described later, in this example selected information can also be passed from the EFT 20 to the ECR 10. The EFT 20 can be programmed to read payment card details from a payment card including the PAN, an expiry date, etc., for the payment card as will be described in more detail with reference to Figure 2. The EFT 20 is configured to be PCI-DSS compliant.

The EFT 20 can then be configured to communicate with a payment service provider (PSP) system 30 via a secure channel (for example over a telephone line or a computer network) to pass details of the transaction including the amount of the goods and the full PAN, the expiry date, etc. in accordance with a conventional EFT-PSP message protocol. The EFT 20 can be operable, for example to send authorisation request messages M2 to the PSP system 30. The PSP system 30 is configured to be PCI-DSS compliant.

In the example of Figure 1 , the PSP system 30 provides a payment services platform implementing an infrastructure to connect EFTs 20 to merchant acquirer systems 30 and other systems. The PSP system 30 can be a PSP computer server system comprising one or more processors, storage network interfaces, etc. The PSP system 30 is operable to generate a unique reference (PREF) identified as PSPRef in Figure 1 , that links, or maps, to the PAN either directly or indirectly.

For example, the PREF can be unique to the transaction and the PSP system 30 and the PSP system 30 can be arranged to store a record including the PREF, the transaction and the PAN associated with the transaction, whereby the PREF provides a mapping between the PREF and the PAN. For example, the PSP system 30 can be operable to generate a new, different, PREF for each successive transaction that the PSP system 30 processes. Each PREF can be a unique number, for example where the PSP system 30 generates a PREF for a given payment transaction to be processed by the PSP system 30 by incrementing (or decrementing) the PREF for the last payment transaction processed by the PSP system 30 by a given number, say one. In this way the PREF links back to the transaction and this in turn can be used to link to the PAN using records for the transaction held by the PSP system 30.

An example of such a process is illustrated in Figure 5.

In step 510, the PSP system 30 receives an authorisation request message M2 from an EFT 20 for a new transaction. The authorisation request includes, for example, a transaction ID (TRID) from the EFT 20, an address and/or identifier for the EFT (EFTA), the PAN used for the transaction, the transaction amount (TRAM), etc.

In step 512, the PSP system 30 increments by one the value of PREF last allocated to a transaction by the PSP system 30 (i.e. PREF, = PREF,._! +1 ). In other examples any suitable algorithm can be used for generating the next PREF.

In step 514, the PSP system 30 creates and stores (e.g., in storage in the PSP system 30) a new transaction record for the new transaction, the new transaction record storing the TRID with the new PREF and the PAN and, for example, the EFTA, the TRAM, etc.

Alternatively, the PREF can be generated as a unique token for a payment card PAN that is independent of the payment transaction itself. In such an example, the PSP system 30, when processing a new payment transaction, can check whether it has already generated a PREF for a given PAN, and if it has not already generated a PREF for the PAN, generate a new PREF for the PAN by incrementing (or decrementing) the last PREF generated, and otherwise to simply use the PREF that was already generated for that PAN.

An example of such a process is illustrated in Figure 6.

In step 610, the PSP system 30 receives an authorisation request from an EFT 20 for a new transaction. The authorisation request includes, for example, a transaction ID (TRID) from the EFT, an address and/or identifier for the EFT (EFTA), the PAN used for the transaction, the transaction amount (TRAM), etc.

In step 612 the PSP system 30 checks existing records to determine whether a PREF has already been allocated for the PAN for the new transaction.

If, in step 612, it is determined that a PREF has already been allocated for the PAN, then in step 614 the PSP system 30 creates and stores (e.g., in storage in the PSP system 30) a new transaction record for the new transaction that stores the TRID with the existing PREF for the PAN and further stores the PAN and, for example, the EFTA, the TRAM, etc.

If, in step 612, it is determined that a PREF has not already been allocated for the

PAN, then in step 616 the PSP system 30 increments by one the value of PREF last allocated to a PAN by the PSP system 30 (i.e. PREF, = PREF|_i +1 ). In other examples any suitable algorithm can be used for generating the next PREF.

In step 618, the PSP system 30 then creates and stores (e.g., in storage in the PSP system 30) a new transaction record for the new transaction that stores the TRID with the new PREF for the PAN and further stores the PAN and, for example, the EFTA, the TRAM, etc.

As an alternative to, or in addition to, the transaction records identified in Figures 5 and 6 above, the PSP system 30 can store a simple TREF to PAN translation table that can be accessed to directly map a TREF to a corresponding PAN.

For example, a table 700 as shown in Figure 7 can be generated using a method as described with reference to Figure 5 or Figure 6 above to link respective unique PREFs 710 (PREF_! to PREF_n) to respective PANs 720 (PAN_! to PAN_n).

The PSP system 30 is operable to send authorisation request messages M3 to a merchant acquirer (MA) system 40 via a secure channel and to receive authorisation response messages M6 from the MA system. The MA system 40 can comprise one or more computer server systems and is configured to communicate in turn with a scheme (schema) system (MasterCard, VISA, etc.) 50 via secure channels, for example for authorisation processing in real time using authorisation request messages M4 and authorisation response messages M5, and for settlement processing as a batch process (not shown) in a conventional manner. The MA system 40 and the scheme system 50 are configured to be PCI-DSS compliant.

The PSP system 30 is additionally configured to include the PREF in messages from the PSP system 30 to the EFT 20, for example in authorisation response messages M7.

The EFT 20 is operable to communicate the PREF to the ECR 10, for example in a payment completion message M8, but not to communicate the full PAN. As a result of the process described above, the ECR 10 is provided with a PREF that, with information held securely in the mapping in the records of the PSP system 30, can be used to identify a full PAN, without actually being provided with the full PAN. The ECR 10 therefore does not need to be configured to be PCI-DSS compliant, as it does not hold the full PAN for the payment card.

The ECR 10 is configured, either directly or via other merchant systems (not shown), to communicate details of a transaction with an SSP system 100, for example a tax refund operator host system 1 10, in one or more tax refund processing messages M9 that further identify the PREF and the identity of the PSP system 30.

In the example of Figure 1 , SSP systems 100 include the TRO host (TROH) system

1 10, a TRO process (TROP) system 120 for processing TRO operations, including integration with external systems (for example customs and/or revenue systems), and a TRO transaction (TROT) system 130 for conducting payment and/or debiting operations. The TROH system 1 10 and the TROP system 120 are preferably not configured to be PCI- DSS compliant, but the TROT system 130 is configured to be PCI-DSS compliant. Each of the TROH system 1 10, the TROP system 120 and the TROT system 130 can be implemented by one or more respective hardware server systems comprising processors, storage, etc., or they be can implemented by one or more virtual servers running on one or more hardware computer systems. The TROH system 1 10, the TROP system 120 and the TROT system 130 can also be implemented by computer cloud based systems.

Where the special service is a tax refund service, the ECR 10 can be operable to generate a paper and/or an electronic tax refund form in a conventional manner when the purchase is made. The tax refund form includes details of the transaction and a transaction identifier (TRID) that is different from the PREF and is unique to the tax refund form. The tax refund form enables the details of the transaction to be tracked, for example to determine whether the goods associated with the tax refund form transaction are exported and the refund is thereby validated. For example a paper refund form can be presented to a refund desk at an airport or an electronic form can be retrieved from the TROH system 1 10 or the TROP host system 120, for example in response to a TRO operator scanning a barcode on a paper receipt at a refund desk or by the user entering information at a validation kiosk or using an application on a mobile phone at, for example, an airport. To facilitate these operations, the ECR 10, either directly, or via other merchant systems (not shown), communicates with the TROH system 1 10 to communicate an electronic tax refund form that includes details of the transaction including the TRID, the PREF and an identifier (PSPID) for the PSP system 30.

When the TROH system 1 10 receives details of a transaction from the ECR 10 including the TRID, the PREF and the PSPID, the TROH system 1 10 passes M1 1 the details of the transaction including the TRID, the PREF and the PSPID to the TROP system 120. The TROP system 120 can be configured to communicate with, for example, a customs system or an export validation system (not shown) to receive M12 information as to whether the goods associated with the purchase have been exported. Thus, when the user validates the export of the goods at, for example, a refund desk or a refund kiosk at an airport or border location, or by using a refund validation application on a mobile phone, the TROP system 120 can receive notification that the goods associated with a transaction have been exported.

In a case where the export of the goods triggers the payment of a tax refund by a credit to a payment card, for example, the TROP system 120 can be operable to provide M13 details of the TRID, the PREF and the PSPID, along with other details including the amount to be credited to a user's payment card, to the TROT system 130.

In an alternative scenario as will be discussed later, where one or more goods associated with a transaction are not exported within a determined time from the time of purchase (say within 21 days of the initial purchase) and the associated general sales tax (GST), value added tax (VAT) or the like was not paid on purchase of the goods with the initial transaction (e.g., for a VAT-OFF or early refund transaction), then the TROP system 120 can be operable to provide M14 details of the TRID, the PREF and the PSPID, along with other details including an amount based on the associated general sales tax (GST), value added tax (VAT) or the like to then be debited from a user's payment card, to the TROT system 130.

However, in both cases, whether a debit or a credit is to be made, as the TROH system 1 10 and the TROP system 120 may not be PCI-DSS compliant, the TROP system 120 does not hold the full PAN, so that the TROT system 130 has to obtain the full PAN in order to be able to carry out the credit or debit in respect of the user's payment card account.

In both cases the TROT system 130 receives transaction information via a first communications channel that includes the TROH system 1 10 and the TROP system 120 from the merchant system (e.g., the ECR 10), the transaction information including the PREF.

In the example of Figure 1 , the TROT system 130 is configured to be in communication with the PSP system 30 via a secure communications channel to obtain M15 the mapping between the PREF and the full PAN associated with the transaction for a given TRID. The secure communications channel forms a second communications channel out of band with respect to the payment authorisation channel and the first communications channel that includes the TROH system 1 10 and the TROP system 120.

In one example, the PSP system 30 is operable to communicate (i.e. push) M15 the mapping between a PREF and a full PAN to the TROT system 130, for example in a batch process along with other mappings for other PREFs and PANs. The TROT system 130 is then operable to store all or selected ones of the mappings as it is also PCI-DSS compliant so that when it receives a message from the TROP system 120 to debit or a credit a user account, it already has the mapping from the PREF to a PAN stored and can use this to credit or debit the user's payment card account as appropriate. In such a batch process the PREFs and PANS can be broadcast via a secure channel and the TROT system 130 can be operable to capture either all of the mappings or only mappings for those PREFs that are required to currently process transactions and ignore mappings for any PREFs that are not currently required by the TROT system 130.

In another example, where a batch process as described above is not used, or where the TROT system 130 finds that it has not yet stored a mapping from a PREF to a PAN, the TROT system 130 is operable to send a request message M15R for a mapping for a given PREF to the PSP system 30 and to receive a response message M15 in real time from the PSP system 30. Thus, the TROT system 130 receives a mapping from the PREF to the PAN associated with the PREF via a second communications channel from a payment authorisation channel (PAC) system in an authorisation channel for authorising a card payment (in the present example from the PSP system 30).

In the example of Figure 1 , therefore, the information to enable a TROT system 130 to effect a credit or debit with a user's payment card account can be effected without a merchant system needing to be aware of a full PAN for the user's payment card, whereby the ECR 10 of a merchant does not need to be configured to be PCI-DSS compliant. Figure 2 (formed from Figures 2A and 2B) illustrates operations performed in a specific example of operation of the system of Figure 1 in more detail. The following description of this example makes reference to Figures 1 and 2.

As described above, in the example of Figure 1 partial integration between an EFT 20 and an ECR 10 is provided. This means that when, for example, one or more goods are being purchased at the ECR 10, a message is sent from the ECR 10 to the EFT 20 in accordance with an ECR-EFT protocol to create a tender. The message can include the amount of the transaction, an ECR transaction ID, a type of payment transaction (debit, credit, reservation), etc.

The EFT 20 is configured then to prompt the user 5 to present a payment card to the

EFT 20. On the payment card being presented to the terminal (for example using a magnetic strip reader, a chip reader or a near field communication (NFC) reader), the EFT 20 is operable to read the PAN and other information from the payment card.

The EFT 20 is then operable to send a validation request message to a PSP system 30 to validate the payment card, for example to determine whether the payment card is a payment card issued in the country in which the EFT 20 is located or a payment card issued in a different country which means that the user 5 is potentially entitled to a refund of general sales tax (GST) or value added tax (VAT) (referred to generically herein as a tax refund). If a return message from the PSP system 30 to the EFT 20 comprises metadata indicative that the user 5 is potentially entitled to tax refund, then the EFT 20 is operable to transmit a message (AdditionalDataCallback message) to the ECR 10 to prompt the merchant to verify the eligibility of the user 5 to receive a tax refund. For example a check can be made manually by a merchant or automatically based on information input by the user 5 (for example using information on a passport or a mobile telephone of the user 5). If the check confirms the eligibility of the user 5 to receive a tax refund, then one or more refund options may be offered to the user 5.

The refund options could be presented to a user 5 by an operator explaining the options to the user 5, or the options could be displayed to a user 5, for example on a screen of the ECR 10, or by means of a message being passed (e.g., using WiFi, NFC , etc.) to a mobile phone of the user 5.

Thus, in the example illustrated in Figure 2, the ECR 10 can be operable to offer different services to the user 5. Figure 2 illustrates three alternative services, identified as Refund Off, Fast Refund and Standard in Figure 2. These next stages in processing are described below.

Indirect Refund The refund service described herein as an indirect refund service is a service where a user 5 pays the full value for the goods including the tax payable, and subsequently receives a refund of tax in the form of, for example, a separate cash or credit card transaction conducted at a refund desk at an airport when the user 5 exports the goods that are being purchased.

In response to selection of this option (e.g., by the merchant operating a physical or displayed key button in response to the user 5 informing the merchant of his or her selection, and/or by the user 5 using a data exchange via a screen of the ECR 10 or the user's mobile phone), the ECR 10 is configured to send an updated tender message M1 to the EFT 20 that includes the user's selection of the indirect refund. The updated tender message M1 includes the gross value of the transaction including the tax to the EFT 20 and a code TFS_CC=False to indicate that the indirect refund option is selected.

The EFT 20 is then operable to prompt the user 5 to insert a personal identification number (PIN). In response to the entry of a PIN, the EFT 20 is operable to verify that the PIN is correct. The EFT 20 is configured to be PCI-DSS compliant and is therefore able to hold and process the PAN for the payment card. If the PIN is correct, then the EFT 20 is operable to send an authorisation request message M2 to the PSP system 30 for the merchant corresponding to the gross value of the transaction including the tax and the TFS_CC=False code to indicate that the indirect refund option is selected. An example authorisation request message M2 sent from the EFT 20 to the PSP system 30 can comprise, for example, the following information: PAN, expiration date, card schema, cardholder details, currency codes, payment amount, currency, terminal id, merchant id, type of payment transaction, etc.

As indicated in Figure 1 , the PSP system 30 sends an authorisation request message M3 to a merchant acquirer (MA) system 40. An example authorisation request message M3 sent from the PSP system 30 to the MA system 40 can comprise, for example, the following information: PAN, expiration date, card schema, cardholder details, currency codes, payment amount, currency, terminal id, merchant id, type of payment transaction, etc. and PSP specific information. The MA system 40 in turn communicates M4 with a card scheme (e.g., VISA, MasterCard) system 50 to obtain authorisation from a system of the card issuer (not shown) for the card system used. It is assumed here that the payment transaction is authorised by the card issuer system, in which case a positive authorisation request is received from the card issuer system by the card scheme system 50, which in turn sends an authorisation response message M5 to the MA system 40, which in turn sends an authorisation response message M6 to the PSP system 30. An example authorisation response message M6 sent from the MA system 40 to the PSP system 30 can comprise, for example, the following information: Authorisation response, credit card token, authorisation code, amount, acquirer codes, currency, etc. The PSP system 30 in the example of Figure 1 is operable to generate a transaction identity (PREF) unique to the transaction and the PSP system 30, and to generate a record that maps the PREF to the payment card number. For example, a table 700 as shown in Figure 7 can be generated using a method as described with reference to Figure 5 or Figure 6 above to link respective unique PREFs 710 (PREF₁ to PREF_n) to respective PANs 720 (PANi to PAN_n). On receipt of an authorisation response message M6 from the MA system 40, the PSP system 30 can be operable to send an authorisation response message M7 to the EFT 20. An example authorisation response message M7 sent from the PSP system 30 to the EFT 20 can comprise, for example, the following information: Authorisation response, credit card token, authorisation code, amount, acquirer codes, currency, etc. and PSP specific information such as a PSP reference number, the PREF, etc. This therefore includes the PREF.

As illustrated in Figure 2, the EFT 20 then sends to the ECR 10 a FinalTransactionResultCallback message M8 that includes the PREF and the EFT 20 displays a message to the user 5 to remove the payment card from the card reader of the EFT 20.

Fast Refund

The refund service described herein as fast refund is a service where a user 5 pays the full value for the goods including the tax payable, and subsequently receives a refund of tax in the form of an automatic credit to the payment card used for the purchase transaction in response to export of the goods. Export of the goods can be identified in response to information input to a computer terminal by a TRO operator at a refund desk, information input to an automated terminal at an airport by the user 5, input information to a mobile phone application, for example using geolocation to identify that the mobile phone is at an airport. The computer terminal, automated terminal and/or mobile phone application are operationally linked to the TROP system 120 such that a message confirming the export is transmitted to the TROP system 120.

In response to selection of this option (e.g., by the merchant operating a physical or displayed key button in response to the user 5 informing the merchant of his or her selection, and/or by the user 5 using a data exchange via a screen of the ECR 10 or the user's mobile phone), the ECR 10 is configured to send an updated tender message M1 to the EFT 20 that includes the user's selection of the fast refund. In this example, the updated tender message M1 includes the gross value of the transaction including the tax to the EFT 20 and a code TFS_CC=True to indicate that an automatic debit/credit of the payment card is authorised for the selected fast refund option. The EFT 20 is then operable to prompt the user 5 to insert a personal identification number (PIN). In response to the entry of a PIN, the EFT 20 is operable to verify that the PIN is correct. The EFT 20 is configured to be PCI-DSS compliant and is therefore able to hold and process the PAN for the payment card. In this example, if the PIN is correct, then the EFT 20 is operable to send an authorisation request message M2 to the PSP system 30 for the merchant corresponding to the gross value of the transaction including the tax and the TFS_CC=True code to indicate that an automatic debit/credit of the payment card is authorised for the fast refund option. An example authorisation request message M2 sent from the EFT 20 to the PSP system 30 can comprise, for example, the following information: PAN, expiration date, card schema, cardholder details, currency codes, payment amount, currency, terminal id, merchant id, type of payment transaction, etc.

As indicated in Figure 1 , PSP system 30 sends an authorisation request message M3 to an MA system 40. An example authorisation request message M3 sent from the PSP system 30 to the MA system 40 can comprise, for example, the following information: PAN, expiration date, card schema, cardholder details, currency codes, payment amount, currency, terminal id, merchant id, type of payment transaction, etc. and PSP specific information. The MA system 40 in turn communicates M4 with a card scheme (e.g., VISA, MasterCard) system 50 to obtain authorisation from a system of the card issuer (not shown) for the card system used. It is assumed here that the payment transaction is authorised by the card issuer system, in which case a positive authorisation request is received from the card issuer system by the card scheme system 50, which in turn sends an authorisation response message M5 to the MA system 40, which in turn sends an authorisation response message M6 to the PSP system 30. An example authorisation response message M6 sent from the MA system 40 to the PSP system 30 can comprise the following information: Authorisation response, credit card token, authorisation code, amount, acquirer codes, currency, etc.. The PSP system 30 in the example of Figure 1 is operable to generate a transaction identity (PREF) unique to the transaction and the PSP system 30, and to generate a record that maps the PREF to the payment card number. On receipt of an authorisation response message M6 from the MA system 40, the PSP system 30 can be operable to send an authorisation response message M7 to the EFT 20. An example authorisation response message M7 sent from the PSP system 30 to the EFT 20 can comprise, for example, the following information: Authorisation response, credit card token, authorisation code, amount, acquirer codes, currency, etc., and PSP specific information such as a PSP reference number, the PREF, etc. This therefore includes the TREF (identified as pspRef in Figure 2). As illustrated in Figure 2, the EFT 20 then sends to the ECR 10 a FinalTransactionResultCallback message M8 that includes the PREF and the EFT 20 displays a message to the user 5 to remove the payment card from the card reader of the EFT 20.

Refund Off

The refund service described herein as refund off is a service where a user 5 does not pay the full value for the goods, but instead pays a reduced amount equal to the full amount minus a refund amount, the refund amount corresponding to the amount of the GST or VAT reduced by a small service charge. Subsequently, if the goods are exported within a predetermined time, say 21 days, no further transaction occurs. However, if the goods are not exported within the predetermined period, then at the end of that period the full amount of the GST or VAT is debited automatically from the payment card. Export of the goods can be identified in response to information input to a computer terminal by a TRO operator at a refund desk, information input to an automated terminal at an airport by the user 5, input information to a mobile phone application, for example using geolocation to identify that the mobile phone is at an airport. The computer terminal, automated terminal and/or mobile phone application are operationally linked to the TROP system 120 such that a message confirming the export is transmitted to the TROP system 120. Non-export is identified by the absence of an identification of export within the predetermined period. The TOP system 120 monitors records for the transaction and the expiry of the time limit where export has not occurred.

In response to selection of this option (e.g., by the merchant operating a physical or displayed key button in response to the user 5 informing the merchant of his or her selection, and/or by the user 5 using a data exchange via a screen of the ECR 10 or the user's mobile phone), the ECR 10 is configured to send an updated tender message M1 to the EFT 20 that includes the user's selection of the refund off. The updated tender message M1 includes the gross value of the transaction including the tax minus the refund amount to the EFT 20 and a code TFS_CC=True to indicate that an automatic debit/credit of the payment card is authorised for the refund off option.

The EFT 20 is then operable to prompt the user 5 to insert a personal identification number (PIN). In response to the entry of a PIN, the EFT 20 is operable to verify that the PIN is correct. The EFT 20 is configured to be PCI-DSS compliant and is therefore able to hold and process the PAN for the payment card. If the PIN is correct, then the EFT 20 is operable to send an authorisation request message M2 to the PSP system 30 for the merchant corresponding to the gross value of the transaction including the tax and the TFS_CC=True code to indicate that an automatic debit/credit of the payment card is authorised for the refund off option. An example authorisation request message M2 sent from the EFT 20 to the PSP system 30 can comprise, for example, the following information: PAN, expiration date, card schema, cardholder details, currency codes, payment amount, currency, terminal id, merchant id, type of payment transaction, etc.

As indicated in Figure 1 , the authorisation request message M3 is sent to an MA system 40. An example authorisation request message M3 sent from the PSP system 30 to the MA system 40 can comprise, for example, the following information: PAN, expiration date, card schema, cardholder details, currency codes, payment amount, currency, terminal id, merchant id, type of payment transaction, etc. and PSP specific information. The MA system 40 in turn communicates M4 with a card scheme (e.g., VISA, MasterCard) system 50 to obtain authorisation from a system of the card issuer (not shown) for the card system used. It is assumed here that the payment transaction is authorised by the card issuer system, in which case a positive authorisation response message is received from the card issuer system by the card scheme system 50, which in turn sends an authorisation response message M5 to the MA system 40, which in turn sends an authorisation response message M6 to the PSP system 30. An example authorisation response message M6 sent from the MA system 40 to the PSP system 30 can comprise the following information: Authorisation response, credit card token, authorisation code, amount, acquirer codes, currency, etc. The PSP system 30 in the example of Figure 1 is operable to generate a transaction identity (PREF) unique to the transaction and the PSP system 30, and to generate a record that maps the PREF to the payment card number. On receipt of an authorisation response message M6 from the MA system 40, the PSP system 30 can be operable to send an authorisation response message M7 to the EFT 20. An example authorisation response message M7 sent from the PSP system 30 to the EFT 20 can comprise, for example, the following information: Authorisation response, credit card token, authorisation code, amount, acquirer codes, currency, etc., and PSP specific information such as a PSP reference number, the PREF, etc. This therefore includes the PREF (identified as pspRef in Figure 2).

In the example operations described above, it should be noted that the use of the TFS_CC = True flag is just one option - this enables the PSP system 30 to know which PANs to provide later to the SSP system 100. The service works also without this indication. In such a case there are various other options. In one option the SSP system 100 can query the PSP system 30 for the PAN using the TREF (payment reference). In another option the PSP system 30 pushes all card payment transactions to the SSP system 100 and the SSP system 100 resolves the TREF into a PAN wherever needed with the other payment transactions being ignored for example where SSP transaction is linked to the payment).

In each of the options described above the ECR 10 is then operable to pass an issue request message M9 to the SSP system 100 (for example the TROH system 1 10) to request a refund transaction. The issue request message can include the PREF (pspRef, the payment card metadata and issue data).

In response to the issue request, the SSP system 100 (for example the TROH system 1 10) is operable to transmit an issue response message to instruct the ECR 10 to generate (e.g., print) a tax refund form (TFF).

The ECR 10 is then operable to send a confirm cheque message to the SSP system 100 (for example the TROH system 1 10) to confirm the printing of the TFF. In the case of an early refund option, the SSP system 100 (for example the TROH system 1 10) is also operable to return a confirm cheque response message to the ECR 10 to confirm receipt of the confirm cheque message.

As discussed above, the SSP systems 100 can include one or more SSP host systems (e.g., TROH system 1 10) which interface with the ECRs 10 of the merchants, one or more SSP process systems (for example the TROP system 120), and one or more SSP financial transaction systems (for example the TROT system 130). An SSP process system 120 is operable to interface with an SSP host system 1 10 to receive information from the SSP host system 1 10. An SSP process system 120 is also operable to interface with, for example, external systems such as a customer system, a TRO refund desk system, a terminal system and/or one or more mobile applications on a user's mobile phone that are operable to determine when a user 5 has exported goods. An SSP transaction system 130 is operable to interface with an SSP process system to receive instructions to process credits and/or debits based on a message that define a PREF and an amount to be credited or debited. A SSP payment system is also operable to interface with a SSP payment system via a secure channel obtain mappings between a PREF and an associated PAN for a payment card to be credited or debited.

As further illustrated in the example flow in Figure 2, where a TFS_CC=True code is sent from the EFT 20 to the PSP system 30, the PSP system 30 is operable to send to the SSP transaction system 130 a mapping message M15 that maps the PREF to the PAN. As described with reference to Figure 1 , this can be as part of a batch process, or in response to a specific request to the PSP system 30 from the SSP transaction system 130. The mapping message can identify the PREF (which as described above in the example of Figure 1 is unique to the PSP system 30 and the PAN), the PAN uniquely identified thereby and further metadata. As the SSP transaction system 130 is PCI-DSS compliant, it is able to store and process the full PAN and other payment card details needed to effect a credit M16 and/or debit M17 transaction based on the PAN, that is with the account identified by the PAN, via a TRO acquirer systems 70 show in Figure 1 . The TRO acquirer system 70 interfaces in a conventional manner with the card scheme systems 50.

Figure 1 illustrates, by means of the dashed lines labelled S1 , S2, S3, S4 and S5, the flow of messages that include the PREF from the PSP system 30 via the EFT 20, the ECR 10, the TROH system 1 10, and the TROP system 120 to the TROT system 130. This means that a token unique to a PAN (i.e. the PREF) but not identifying the PAN can be passed via those systems. As a result, although such messages are sent by secure channels, the ECR 10, the TROH system 1 10, and the TROP system 120 do not need to be configured to be PCI-DSS compliant. Figure 1 also illustrates, by means of the bold dashed line labelled S6, the flow of a secure message that include the PREF and a mapping to the PAN directly from the PSP system 30 to the TROT system 130 via a secure PCI-DSS compliant channel. As discussed above, the PSP system 30 and the TROT system 130 are both configured to be PCI-DSS compliant.

Figure 3 is a schematic block diagram of an example embodiment providing PSP system tokenisation in a transaction system. The example of Figure 3 is the same as the example of Figure 1 with the exception that the no integration of the EFT 20 to the ECR 10 is provided. As the example of Figure 3 corresponds substantially to the example of Figure 1 , apart from the lack of integration between the EFT 20 and the ECR10, reference is made to the description of Figures 1 and 2 above, for the description of Figure 3, and like reference signs are used in Figures 3 and 1 . The only difference relates to the manner in which information is transferred between the EFT 20 and the ECR 10, an example of which will now be explained.

In the example of Figure 3, the EFT 20 is a stand-alone EFT 20 that is not integrated with the ECR 10.

For example, a merchant may enter one or more goods (for example by scanning a barcode on the or each good using a using a barcode scanner of the ECR 10) and then operate a key on the ECR 10 to generate on the ECR information to be manually entered by the operator of the ECR 10 using the user interface (e.g., a keyboard) of the EFT 20. The merchant operator can enter the value of the goods as shown on the display of the ECR 10 using the user interface of the EFT 20. As described above with reference to Figure 1 , the EFT 20 can be programmed to read payment card details from a payment card including the PAN, an expiry date, etc., for the payment card as described, for example with reference to Figure 2. The EFT 20 is configured to be PCI-DSS compliant. As also described with reference to Figure 1 , the EFT 20 can then be configured to communicate with a payment service provider (PSP) system 30 via a secure channel to pass details of the transaction including the amount of the goods and the full PAN, the expiry date, etc. in accordance with an EFT-PSP message protocol. The EFT 20 can be operable, for example to send authorisation request messages to the PSP system 30. The PSP system 30 is configured to be PCI-DSS compliant. In the example of Figure 3, the PSP system 30 is also operable to generate a transaction reference (PREF) identified as PSPRef in Figure 3, for the transaction that is unique to the PAN and the PSP system 30 and thereby provides a mapping between the PREF and the PAN. The PSP system 30 is operable to communication with a merchant acquirer system (MA system) 40 via a secure channel. The MA system 40 is configured to communicate in turn with a scheme system (MasterCard, VISA, etc.) 50 via secure channels, for example for authorisation processing in real time and for settlement processing as a batch process in a conventional manner. The MA system 40 and the scheme systems 50 are configured to be PCI-DSS compliant. The PSP system 30 is additionally configured to include the PREF in messages from the PSP system 30 to the EFT 20, for example in authorisation response messages.

In the example of Figure 3, the EFT 20 is not able automatically to communicate the PREF to the ECR 10, as it is a stand alone unit and is not integrated with the ECR 10. However, in a conventional manner, the EFT is provided with a printer for providing a printed record of a card transaction. Accordingly, in the example of Figure 3, the EFT is configured, when printing a printed record (receipt) of the card transaction, to include a barcode (e.g. a one dimensional barcode or a two dimensional barcode (QR code)) 25 that includes a representation of the PREF. This barcode can then be scanned using a scanner 15 of the ECR 10 to capture the information in the barcode. The ECR 10 can be configured to extract the PREF from the information represented by the barcode to enable the PREF to be entered into to the ECR 10. In the case, in particular, of a 2D barcode, additional information can be coded into the barcode (such as Card Schema, Expiration Date, Card Issuer Country, Card Holder Name, Masked Credit Card Number).

As a result of the process described above, the ECR 10 of Figure 3 is provided with a PREF that, with information held securely in the mapping in the PSP system 30, can be used to identify a full PAN, without actually being provided with the full PAN. The ECR 10 therefore does not need to be configured to be PCI-DSS compliant, as it does not hold the full PAN for the payment card. The PREF can then be used in the example of Figure 3 in the same manner as the PREF transferred by the partial integration in the example of Figure 1 . The further operation of the example of Figure 3 corresponds to that of Figure 1 and is not repeated herein.

Figure 3 illustrates, by means of the bold dashed lines labelled S1 , S2-1 , S2-2, S3,

S4 and S5, the flow of messages that include the PREF from the PSP system 30 via the EFT 20, the barcode 25 and scanner 15, the ECR 10, the TROH system 1 10, and the TROP system 120 to the TROT system 130. This means that a token unique to a PAN (i.e. the PREF) but not identifying the PAN can be passed via those systems. As a result, although such messages are sent by secure channels, the ECR 10, the TROH system 1 10, and the TROP system 120 do not need to be configured to be PCI-DSS compliant. Figure 1 also illustrates, by means of the bold dashed line labelled S6, the flow of a secure message that include the PREF and a mapping to the PAN directly from the PSP system 30 to the TROT system 130 via a secure PCI-DSS compliant channel. As discussed above, the PSP system 30 and the TROT system 130 are both configured to be PCI-DSS compliant.

As a result, an embodiment of the claimed subject matter as described with reference to Figure 1 or Figure 3 and Figure 2 can enable handling of a PAN in a PCI-DSS compliant manner across interconnected systems where a merchant system does not hold a PAN, while enabling provision of third party services by a SSP system that requires knowledge of a PAN for a transaction. As described the SSP systems can, for example, comprise one or more TRO host systems for providing a tax refund service. For example, TFS may be incorporated into the operation of a merchant system (e.g., an ECR) without a PAN needing to be captured by the ECR, thereby keeping the ECR out of the scope of the PCI-DSS. For payment, the PAN can be captured using a dedicated stand-alone or semi- integrated terminal. The PAN is not routed through the ECR and other merchant systems.

Figure 4 is a schematic block diagram of an example embodiment providing card scheme system tokenisation in a transaction system. In the example of Figure 4 a PREF is generated by a card scheme system 40 rather than a PSP system 30.

In the example of Figure 4, a point of sale electronic cash register (ECR) 10 is a merchant system that provides the functions of a typical electronic cash register for the input of details of one or more products to be purchased by a customer (hereafter referred as a user 5). The ECR 10 is programmed to provide functions, for example in

communications with one or more merchant systems (not shown), to compute a total value for purchases, computer tax payable etc., and also to perform functions of, for example, recording details of purchases, customers, inventory, etc. The ECR can include one or more processors, storage, one or more displays, one or more user interfaces such as a keyboard, NFC reader, barcode scanner, etc.

In the example of Figure 4, the ECR 10 is also configured, either directly or via other merchant systems (not shown), to communicate with a special service provider (SSP) system 100, for example a tax refund operator (TRO) system 100.

In an example of Figure 4, in order that the ECR 10 does not have to be PCI-DSS compliant, the ECR 10 is configured so that it does not receive the full primary account number (PAN) of a user's payment card. With this in mind, transactions using a user's payment card are performed using an electronic funds transfer payment terminal (EFT) 20. In the example of Figure 4, partial integration between the ECR 10 and the EFT 20 is provided so that certain information is passed between the ECR 10 and the EFT 20, but a full PAN is not communicated from the EFT 20 to the ECR 10 as described with the example of Figure 1 . In an alternative to this, a stand alone EFT could be provided as in the example of Figure 3.

In operation, in the example of Figure 4 when the purchase of goods is processed by the ECR 10 and a payment total is computed, the total value of the goods can then be passed electronically from the ECR 10 to the EFT 20. For example, a merchant may enter one or more goods (for example by scanning a barcode on each good using a barcode scanner of the ECR 10) and then operate a key on the ECR 10 to enable payment for the one or more goods using a payment card. A message is then sent from the ECR 10 to the EFT 20 that can include the total value of the goods in accordance with an ECR-EFT message protocol. In this example, selected information can also be passed from the EFT 20 to the ECR 10.

The EFT 20 can be programmed to read payment card details from a payment card including the PAN, an expiry date, etc., for the payment card as described above in more detail with reference to Figure 2. The EFT 20 is configured to be PCI-DSS compliant.

The EFT 20 can then be configured to communicate with a payment service provider (PSP) system 30 via a secure channel to pass details of the transaction including the amount of the goods and the full PAN, the expiry date, etc. in accordance with an EFT-PSP message protocol. The EFT 20 can be operable, for example to send authorisation request messages to the PSP system 30. The PSP system 30 is configured to be PCI-DSS compliant.

The PSP system 30 can be operable to communication with a merchant acquirer (MA) system 40 that is in turn configured to communicate with a scheme system

(MasterCard, VISA, etc.) 50 via secure channels, for example for authorisation processing in real time and for settlement processing as a batch process in a conventional manner. The MA system 40 and the scheme system 50 are configured to be PCI-DSS compliant.

In the example of Figure 4, the scheme system 50 is operable to generate a transaction reference (PREF), for the transaction that is unique to the PAN and the scheme system 50 and thereby provides a mapping between the PREF and the PAN.

The scheme system 50 is additionally configured to include the PREF in messages from the scheme system 50 (optionally via an MA system 40) to the PSP system 30, which in turn is configured to pass the PREF in messages to the EFT 20, for example in authorisation response messages.

The EFT 20 is operable to communicate the PREF to the ECR 10, but not to communicate the full PAN. As a result of the process described above, the ECR 10 is provided with a PREF that, with information held securely in the mapping in the scheme system 50, can be used to identify a full PAN, without actually being provided with the full PAN. The ECR 10 therefore does not need to be configured to be PCI-DSS compliant, as it does not hold the full PAN for the payment card.

The ECR 10 is configured, either directly or via other merchant systems (not shown), to communicate details of a transaction with an SSP system 100, for example a TRO system 1 10, in one or more messages that further identify the PREF and the identity of the PSP. Where the special service is a tax refund service, the ECR 10 can be also operable to generate a paper and/or an electronic tax refund form 12 in a conventional manner when the purchase is made, for example as described with reference to Figure 1 .

In the example of Figure 4, SSP system 100 is operable to communicate on the one hand with the merchant systems 150 for GST/VAT and commission transactions, and also with the TRO acquirer system 70 for user credits and/or debits as described with reference to Figures 1 and 2.

However, as the ECR 10 does not hold the full PAN for a payment card in respect of a transaction made using a payment card, the ECR 10 cannot pass the PAN to the SSP system 100 to enable the transactions with the TRO acquirer system 70 to be effected. Accordingly, the SSP system 100, or, more particularly that part of the SSP system 100 responsible for managing payment transactions (e.g., a TROT system corresponding to the TROT system 130 of Figure 1 ) has to obtain the full PAN in order to be able to carry out the credit or debit in respect of the user's payment card account.

In the example of Figure 4, a secure part of the SSP system 100 configured to be PCI-DSS compliant (e.g., a TROT system corresponding to the TROT system 130 of Figure 1 ) is configured to be in communication with the scheme system(s) 50 via a secure communications channel to obtain the mapping between the PREF and the full PAN associated with the transaction for a given TRID. The secure communications channel thus forms a second communications channel out of band with respect to the payment authorisation channel and a first communications channel formed by the channel by which the ECR 10 communicates with the SSP system 100.

In one example, the scheme system 50 is operable to communicate the mapping between a PREF and a full PAN to the PCI-DSS compliant part of the SSP system 100 (e.g., a TROT system corresponding to the TROT system 130 of Figure 1 ), for example in a batch process along with other mappings for other PREFs and PANs. The PCI-DSS compliant part of the SSP system 100 (e.g., a TROT system corresponding to the TROT system 130 of Figure 1 ) is then operable to store the mappings as it is also PCI-DSS compliant so that when it receives a message to debit or a credit a user account (from example from another part of the SSP system 100, it already has the mapping from the PREF to a PAN stored and can use this to credit or debit the user's payment card account as appropriate.

In another example, where a batch process as described above is not used, or where the PCI-DSS compliant part of the SSP system 100 (e.g., a TROT system

corresponding to the TROT system 130 of Figure 1 ), finds that it has not yet stored a mapping from a PREF to a PAN, it can send a request message for a mapping for a given PREF to the scheme system 50 and to receive a response message in real time from the scheme system 50.

In the example of Figure 4, therefore, the information to enable a PCI-DSS compliant part of the SSP system 100 (e.g., a TROT system corresponding to the TROT system 130 of Figure 1 ), to effect a credit or debit with a user's payment card account can be effected without a merchant system needing to be aware of a full PAN for the user's payment card, whereby the ECR 10 of a merchant does not need to be configured to be PCI-DSS compliant.

Figure 4 illustrates, by means of the dashed line labelled F1 , the flow of messages that include the PREF from the scheme system 50 via the PSP system 30, EFT 20 and the ECR 10 to a PCI-DSS compliant part of the SSP system 100 (e.g., a TROT system corresponding to the TROT system 130 of Figure 1 ). This means that a token unique to a PAN (i.e. the PREF) but not identifying the PAN can be passed via those systems. As a result, although such messages are sent by secure channels, the ECR 10 does not need to be configured to be PCI-DSS compliant. Thus, a PCI-DSS compliant part of the SSP system 100 receives transaction information via a first communications channel from the merchant system (e.g., the ECR 10), the transaction information including the PREF.

Figure 4 also illustrates, by means of the bold dashed line labelled F2, the flow of a secure message that includes the PREF and a mapping to the PAN directly from the scheme system 50 to the PCI-DSS compliant part of the SSP system 100 (e.g., a TROT system corresponding to the TROT system 130 of Figure 1 ) via a secure PCI-DSS compliant channel. Thus, the PCI-DSS compliant part of the SSP system 100 receives a mapping from the PREF to the PAN associated with the PREF via a second communications channel from a payment authorisation channel (PAC) system in an authorisation channel for authorising a card payment (in the present example from the scheme system 50). As discussed above, the scheme system 50 and the PCI-DSS compliant part of the SSP system 100 (e.g., a TROT system corresponding to the TROT system 130 of Figure 1 ) are both configured to be PCI-DSS compliant, while the ECR 10 of a merchant does not need to be configured to be PCI-DSS compliant.

With reference to the examples transaction systems shown in the respective

Figures, although in each Figure only a single ECR 10, a single EFT 20, a single PSP 30, a single MA system 40, a single card scheme system 50 and/or a single card issuer system 60 and/or a single TRO acq system 70, etc. are shown for reasons of ease of illustration and explanation, an example transaction system can include multiple such devices and systems interconnected by one or more networks. Also, as explained in the description, an SSP system 100 can include multiple TROH 1 10, TROP 12 and TROT 130 systems.

Although reference is made generically herein to payment cards, card payments and payment card numbers, it should be noted that in the context of the present document, it is to be understood that the expression payment card does not define merely traditional plastics physical cards and payments using traditional plastics payment cards, but rather defines any credit, debit and pre-paid payment devices, including, for example, mobile communications devices that incorporate electronic card wallets or payment chips and permit electronic payments using, for example a primary account number (PAN). Similarly, in the context of the present document, it is to be understood that references to card payments refer to payments using such payment devices. Also, in the context of the present document, it is to be understood that references to a payment card number are used not merely to refer to a PAN of a physical card, but rather to any primary account number (PAN) as used with such a payment device.

One or more aspects of the described embodiments can be implemented by one or more computer programs which, when executed on one or more computer systems, implement methods of operation of one or more computer system as described herein. The one or more computer programs can be in the form of one or more computer program products, for example as instructions held on one or more non-transient storage media. Numerous variations and modifications will become apparent to those skilled in the art once the above disclosure is fully appreciated. It is intended that the following claims be interpreted to include all such variations and modifications and their equivalents.

Claims

1 . A computer-implemented method, comprising:

receiving, at at least one computer system of a special service provider, "SSP", transaction information via a first communications channel from a merchant system, the transaction information including a unique reference, "PREF", generated by a payment authorisation channel system, "PAC", system, the PAC system being a system in an authorisation channel for authorising a payment and the PREF being unique to the PAC system that generated the PREF and one of the transaction or a primary account number, "PAN", associated with the transaction;

receiving, at the at least one computer system of the SSP via a second communications channel from a said PAC system in the authorisation channel, a mapping from the PREF to the PAN associated with the PREF;

processing, by the at least one computer system of the SSP, a service associated with the transaction information using the PAN associated with the PREF in accordance with the mapping.

2. The method of claim 1 , wherein the merchant system does not receive or process the PAN.

3. The method of claim 1 or claim 2, wherein the at least one computer system of the SSP receives the mapping from the PREF to the PAN associated with the PREF from the PAC system that generated the PREF.

4. The method of any one of the preceding claims, wherein the PAC system that generated the PREF is a payment service provider, "PSP", system.

5. The method of claim 4, wherein the PREF is unique to the transaction and the PSP system, the PREF mapping to the PAN for the transaction using information held by the PSP system.

6. The method of claim 4, wherein the PREF is unique to the PAN and the PSP system, the PREF mapping to the PAN for the transaction using information held by the PSP system.

7. The method of any one of claims 1 to 3, wherein the PREF is generated by a card scheme system.

8. The method of claim 7, wherein the PREF is unique to the transaction and the card scheme system, the PREF mapping to the PAN for the transaction using information held by the card scheme system.

9. The method of claim 7, wherein the PREF is unique to the PAN and the card scheme system, the PREF mapping to the PAN for the transaction using information held by the card scheme system.

10. The method of any one of the preceding claims, wherein the at least one computer system of the SSP receives the mapping from the PREF to PAN associated with the PREF in response to a request message from the at least one computer system of the SSP to said PAC system, which request message includes the PREF.

1 1 . The method of any one of claims 1 to 9, wherein the at least one computer system of the SSP receives the mapping from the PREF to PAN associated with the PREF as a result of the mapping being pushed from a said PAC system to the at least one computer system of the SSP.

12. The method of any one of the preceding claims, wherein, in response to a payment terminal routing payment transaction information including a PAN captured by the payment terminal to a PSP system, the PSP system returns the PREF for the transaction to the payment terminal.

13. The method of claim 10, wherein the PREF is provided from the payment terminal to the merchant system on authorisation of the payment transaction.

14. The method of claim 13, wherein the payment terminal is configured to transfer the PREF to the merchant system with information confirming authorisation of the transaction.

15. The method of claim 13, wherein the payment terminal is configured to print the PREF and/or a code that represents the PREF on a payment slip and scanning, by a scanner of the merchant system, the PREF and/or the code that represents the PREF to transfer the PREF to the merchant system.

16. The method of any one of the preceding claims, wherein the at least one system of the SSP is at least one system of a tax refund service provider.

17. The method of claim 16, wherein the at least one system of the SSP is operable to determine whether purchased goods have been exported within a given time of the issuing of a tax refund transaction where tax was not charged at the time of purchase, and to initiate a payment transaction using the PAN to recover tax for the purchased goods.

18. One or more computer programs which, when executed on one or more computer systems, implement the method of any one of the preceding claims.

19. A system comprising one or more computers configured and programmed to carry out the method of any one of claims 1 to 17.