WO2018029011A1 - Procédés et systèmes de traitement de transaction sécurisée - Google Patents

Procédés et systèmes de traitement de transaction sécurisée Download PDF

Info

Publication number
WO2018029011A1
WO2018029011A1 PCT/EP2017/069087 EP2017069087W WO2018029011A1 WO 2018029011 A1 WO2018029011 A1 WO 2018029011A1 EP 2017069087 W EP2017069087 W EP 2017069087W WO 2018029011 A1 WO2018029011 A1 WO 2018029011A1
Authority
WO
WIPO (PCT)
Prior art keywords
pref
pan
transaction
payment
psp
Prior art date
Application number
PCT/EP2017/069087
Other languages
English (en)
Inventor
Massimiliano COSTA
Victor KLETZER
Matthias Fritz
Garry Bryce BUCKLAND
Original Assignee
Global Blue Sa
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Global Blue Sa filed Critical Global Blue Sa
Priority to JP2019506092A priority Critical patent/JP6904636B2/ja
Priority to SG11201900938SA priority patent/SG11201900938SA/en
Priority to KR1020197006815A priority patent/KR102180400B1/ko
Publication of WO2018029011A1 publication Critical patent/WO2018029011A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/382—Payment protocols; Details thereof insuring higher security of transaction
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/42—Confirmation, e.g. check or permission by the legal debtor of payment
    • G06Q20/425—Confirmation, e.g. check or permission by the legal debtor of payment using two different networks, one for transaction and one for security confirmation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q30/00—Commerce
    • G06Q30/02—Marketing; Price estimation or determination; Fundraising

Definitions

  • the present invention relates to methods, apparatus and systems for providing secure transaction processing.
  • 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.
  • PCI Payment Card Industry
  • merchant systems 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)).
  • POS point of sale
  • ECR electronic cash register
  • 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.
  • PAN Primary Account Number
  • 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.
  • PSP payment service provider
  • 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.
  • card scheme e.g., MasterCard, VISA, etc.
  • 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.
  • the merchant enters the payment details (e.g., a transaction amount) manually into the payment terminal to conduct a card payment.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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)).
  • a tax refund service also referred to herein as a tax free service (TFS)
  • 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.
  • 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.
  • the PSP system 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.
  • PREF unique reference
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the payment terminal can be configured to transfer the
  • 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.
  • 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.
  • the PREF can be passed to the SSP system.
  • 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.
  • 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.
  • 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.
  • 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.
  • SSP special service provider
  • the ECR 10 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.
  • PAN primary account number
  • 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).
  • PAN primary account number
  • transactions using a user's payment card are performed using an electronic funds transfer payment terminal (EFT) 20.
  • EFT electronic funds transfer payment terminal
  • 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.
  • 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.
  • the total value of the goods can then be passed electronically from the ECR 10 to the EFT 20.
  • 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.
  • 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.
  • 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.
  • PREF unique reference
  • 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.
  • 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.
  • 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.
  • any suitable algorithm can be used for generating the next PREF.
  • 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.
  • the PREF can be generated as a unique token for a payment card PAN that is independent of the payment transaction itself.
  • 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.
  • 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.
  • TID transaction ID
  • EFTA address and/or identifier for the EFT
  • TAM transaction amount
  • 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.
  • 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.
  • step 612 it is determined that a PREF has not already been allocated for the
  • PREF, PREF
  • any suitable algorithm can be used for generating the next PREF.
  • 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.
  • 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.
  • 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.
  • 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.
  • SSP systems 100 include the TRO host (TROH) system
  • 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.
  • 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.
  • TID transaction identifier
  • 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.
  • 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.
  • 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.
  • the TROH system 1 10 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.
  • the TROP system 120 can receive notification that the goods associated with a transaction have been exported.
  • 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.
  • 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.
  • 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.
  • 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.
  • the merchant system e.g., the ECR 10
  • 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.
  • 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.
  • 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.
  • 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.
  • 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).
  • PAC payment authorisation channel
  • 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.
  • an EFT 20 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
  • 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 terminal for example using a magnetic strip reader, a chip reader or a near field communication (NFC) reader
  • NFC near field communication
  • 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.
  • GST general sales tax
  • VAT value added tax
  • 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.
  • a message being passed (e.g., using WiFi, NFC , etc.) to a mobile phone of the user 5.
  • 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.
  • 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.
  • 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 EFT 20 is then operable to prompt the user 5 to insert a personal identification number (PIN).
  • PIN personal identification number
  • the EFT 20 is operable to verify that the PIN is correct.
  • 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.
  • 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.
  • a card scheme e.g., VISA, MasterCard
  • 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.
  • PREF transaction identity
  • 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 1 to PREF n ) to respective PANs 720 (PANi to PAN n ).
  • 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.
  • 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.
  • 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.
  • 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.
  • the EFT 20 is then operable to prompt the user 5 to insert a personal identification number (PIN).
  • PIN personal identification number
  • the EFT 20 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.
  • 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.
  • 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.
  • a card scheme e.g., VISA, MasterCard
  • 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.
  • PREF transaction identity
  • an authorisation response message M6 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).
  • 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.
  • 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.
  • 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 EFT 20 is then operable to prompt the user 5 to insert a personal identification number (PIN).
  • PIN personal identification number
  • the EFT 20 is operable to verify that the PIN is correct.
  • 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.
  • 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.
  • a card scheme e.g., VISA, MasterCard
  • 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.
  • PREF transaction identity
  • an authorisation response message M6 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).
  • 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.
  • the SSP system 100 can query the PSP system 30 for the PAN using the TREF (payment reference).
  • 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).
  • 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).
  • 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).
  • TTF tax refund form
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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.
  • the EFT 20 is a stand-alone EFT 20 that is not integrated with the ECR 10.
  • 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.
  • 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.
  • 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 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.
  • PREF transaction reference
  • 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.
  • 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.
  • the EFT is provided with a printer for providing a printed record of a card transaction.
  • 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.
  • additional information can be coded into the barcode (such as Card Schema, Expiration Date, Card Issuer Country, Card Holder Name, Masked Credit Card Number).
  • 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.
  • FIG. 3 illustrates, by means of the bold dashed lines labelled S1 , S2-1 , S2-2, S3,
  • 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.
  • the PSP system 30 and the TROT system 130 are both configured to be PCI-DSS compliant.
  • 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.
  • the SSP systems can, for example, comprise one or more TRO host systems for providing a tax refund service.
  • 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.
  • 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.
  • FIG 4 is a schematic block diagram of an example embodiment providing card scheme system tokenisation in a transaction system.
  • a PREF is generated by a card scheme system 40 rather than a PSP system 30.
  • 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
  • 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.
  • 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.
  • SSP special service provider
  • TRO tax refund operator
  • the ECR 10 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.
  • PAN primary account number
  • transactions using a user's payment card are performed using an electronic funds transfer payment terminal (EFT) 20.
  • EFT electronic funds transfer payment terminal
  • 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 .
  • a stand alone EFT could be provided as in the example of Figure 3.
  • the total value of the goods can then be passed electronically from the ECR 10 to the EFT 20.
  • 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.
  • 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
  • the MA system 40 and the scheme system 50 are configured to be PCI-DSS compliant.
  • 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.
  • PREF transaction reference
  • 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.
  • 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.
  • 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 .
  • 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.
  • 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.
  • 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.
  • 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.
  • 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
  • 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.
  • 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
  • a PCI-DSS compliant part of the SSP system 100 e.g., a TROT system corresponding to the TROT system 130 of Figure 1
  • the ECR 10 of a merchant does not need to be configured to be PCI-DSS compliant.
  • FIG 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 ).
  • 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.
  • 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).
  • PAC payment authorisation channel
  • the scheme system 50 and the PCI-DSS compliant part of the SSP system 100 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.
  • an example transaction system can include multiple such devices and systems interconnected by one or more networks.
  • an SSP system 100 can include multiple TROH 1 10, TROP 12 and TROT 130 systems.
  • 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).
  • PAN primary account number
  • references to card payments refer to payments using such payment devices.
  • 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.

Landscapes

  • Business, Economics & Management (AREA)
  • Accounting & Taxation (AREA)
  • Engineering & Computer Science (AREA)
  • Strategic Management (AREA)
  • Finance (AREA)
  • General Physics & Mathematics (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Development Economics (AREA)
  • Computer Security & Cryptography (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Game Theory and Decision Science (AREA)
  • Economics (AREA)
  • Marketing (AREA)
  • Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

La gestion d'un numéro de compte principal (PAN) d'une manière conforme à la norme PCI-DSS est facilitée, comprenant un système marchand ne contenant pas de PAN tout en permettant, néanmoins, à des services tiers qui nécessitent la connaissance d'un PAN d'effectuer une transaction.
PCT/EP2017/069087 2016-08-12 2017-07-27 Procédés et systèmes de traitement de transaction sécurisée WO2018029011A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2019506092A JP6904636B2 (ja) 2016-08-12 2017-07-27 セキュアな取引処理のための方法、コンピュータプログラム及びシステム
SG11201900938SA SG11201900938SA (en) 2016-08-12 2017-07-27 Methods and systems for secure transaction processing
KR1020197006815A KR102180400B1 (ko) 2016-08-12 2017-07-27 보안 트랜잭션 프로세싱을 위한 방법들 및 시스템들

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1613863.8 2016-08-12
GBGB1613863.8A GB201613863D0 (en) 2016-08-12 2016-08-12 Methods and systems for secure transaction processing

Publications (1)

Publication Number Publication Date
WO2018029011A1 true WO2018029011A1 (fr) 2018-02-15

Family

ID=56985807

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2017/069087 WO2018029011A1 (fr) 2016-08-12 2017-07-27 Procédés et systèmes de traitement de transaction sécurisée

Country Status (5)

Country Link
JP (1) JP6904636B2 (fr)
KR (1) KR102180400B1 (fr)
GB (1) GB201613863D0 (fr)
SG (1) SG11201900938SA (fr)
WO (1) WO2018029011A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009112207A1 (fr) * 2008-03-10 2009-09-17 Global Refund Holdings Ab Système et procédé de remboursement
US20150161642A1 (en) * 2013-12-06 2015-06-11 Mastercard International Incorporated Method and system to track merchant loyalty and incentives via a credit card
WO2015121172A1 (fr) * 2014-02-11 2015-08-20 Global Blue S.A. Procédé et système

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20100069535A (ko) * 2008-12-15 2010-06-24 김경호 외국인 쇼핑객을 위한 세금 환급 시스템과 장치 및 운영방법
GB2468340A (en) * 2009-03-04 2010-09-08 Global Refund Holdings Ab Validation of tax refunds
JP5422365B2 (ja) * 2009-12-17 2014-02-19 株式会社エヌ・ティ・ティ・データ 取引システム、取引方法およびカード情報提供サーバ
WO2015009100A1 (fr) * 2013-07-18 2015-01-22 (주)큐브리펀드 Système et procédé d'exploitation de comptoir de remboursement
KR101638787B1 (ko) * 2014-12-30 2016-07-22 (주)에이텍티앤 위치정보와 단말기 고유번호 기반의 모바일 티켓 보안시스템 및 그 방법

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009112207A1 (fr) * 2008-03-10 2009-09-17 Global Refund Holdings Ab Système et procédé de remboursement
US20150161642A1 (en) * 2013-12-06 2015-06-11 Mastercard International Incorporated Method and system to track merchant loyalty and incentives via a credit card
WO2015121172A1 (fr) * 2014-02-11 2015-08-20 Global Blue S.A. Procédé et système

Also Published As

Publication number Publication date
KR102180400B1 (ko) 2020-11-19
GB201613863D0 (en) 2016-09-28
JP6904636B2 (ja) 2021-07-21
SG11201900938SA (en) 2019-02-27
JP2019527895A (ja) 2019-10-03
KR20190039753A (ko) 2019-04-15

Similar Documents

Publication Publication Date Title
JP5935142B2 (ja) 動的通貨換算システム及び方法
CA2896755C (fr) Systemes et methodes de production de transmission de donnees securisee entre systemes informatiques en reseau
US8205791B2 (en) Payment system and methods
US20170262828A1 (en) Universal check-out system for mobile payment applications/platforms
US20150324767A1 (en) System and method for recovering refundable taxes
US20110004528A1 (en) Refund system and method
CN108027925B (zh) 一种使用二维码的无卡支付方法及其系统
US20130013502A1 (en) Facilitation of Transactions Using a Transaction Code
KR102096692B1 (ko) 방법 및 시스템
US20140034725A1 (en) Payment System and Methods
US20150142672A1 (en) Method and apparatus for conducting offline commerce transactions
US10664816B2 (en) Method and system for making electronic payments
CN109214815B (zh) 接受双重功能支付凭证的系统和方法
US20100161478A1 (en) Computer payment banking system and method
US20130159118A1 (en) System and Method for Mobile Retail Transaction Processing
KR101886573B1 (ko) 카드 결제 시스템
US20160098706A1 (en) Method and apparatus for conducting fund transfer between two entities and its application as a cell phone wallet
WO2015195217A1 (fr) Système de paiement final universel pour des applications/plateformes de paiement mobile
US11288931B2 (en) Systems and methods for facilitating load cash transactions with a debit card at a point of sale system
AU2018200623A1 (en) Application currency code for dynamic currency conversion transactions with contactless consumer transaction payment device
KR102180400B1 (ko) 보안 트랜잭션 프로세싱을 위한 방법들 및 시스템들
US9792610B2 (en) Non-payment communications using payment transaction network
KR20170072658A (ko) 자동화 결제 방법 및 그 장치
US20090134214A1 (en) Transaction systems and methods
KR20040037720A (ko) 아이알에프엠을 이용한 아이알에프엠 쿠폰 시스템 및아이알에프엠 쿠폰 서비스 방법

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 17748713

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2019506092

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 20197006815

Country of ref document: KR

Kind code of ref document: A

122 Ep: pct application non-entry in european phase

Ref document number: 17748713

Country of ref document: EP

Kind code of ref document: A1