JP2019527895A - Method and system for secure transaction processing - Google Patents

Abstract

A third-party service that facilitates the handling of card membership numbers (PANs) in a PCI-DSS compliant format and requires knowledge of the PAN to execute transactions, even though the merchant system does not hold the PAN Make it executable. [Selection] Figure 1

Description

background

  The present invention relates to a method, apparatus, and system for providing secure transaction processing.

  Use a payment card such as a credit card or debit card, or an alternative payment device (hereinafter collectively referred to as a payment card) such as a mobile communication device such as a telephone or a wristwatch provided with means for electronic payment. Transactions performed using credit, debit, and other payment accounts are subject to regulations in accordance with standards established by the Payment Card Industry (PCI) Security Standards Council.

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

  Maintaining the system to meet these standards is a tedious task. As a result, retail organizations typically use payment terminals that are separate from merchant front-end and back-end systems (hereinafter collectively referred to as merchant systems). An example of a merchant front-end system is a merchant point-of-sale (POS) terminal (eg, an electronic cash register (ECR)). Examples of merchant backend systems can include inventory systems and accounting systems. Since merchant systems such as ECR do not store or process payment card numbers (card membership numbers or PANs) used in card transactions, merchant systems are outside the scope of PCI-DSS. A dedicated payment terminal is used to receive and process the PAN for payment card transactions and communicate in a secure manner with a payment service provider (PSP) acquirer system according to PCI-DSS. The PSP system is then integrated with a card scheme (eg, MasterCard, VISA, etc.) system that uses a secure channel according to PCI-DSS.

  In some implementations, the merchant system is completely separate from the payment terminal, in which case no electronic data is exchanged between the payment terminal and the merchant system. Typically, in such implementations, the merchant manually enters payment details (eg, transaction amount) into the payment terminal to perform card payment.

  In other implementations, a degree of integration is provided that allows some transaction details, such as the transaction amount, to be passed from the merchant system to the payment terminal and / or the payment terminal selects the selected information from the merchant. Configured to communicate only to the system. For example, the selected information passed from the payment terminal to the merchant system includes an authorization code for the transaction and a truncated portion of the PAN (ie, the last four digits) to confirm the authorization of the payment using the card. be able to. However, in such a configuration, the merchant system does not need to be configured to meet PCI-DSS, so the full PAN is not passed to the merchant system.

  For example, a service provider that provides one or more specialized, specific, or selected services (hereinafter, these service providers are distinguished from payment service providers (PSPs) that form part of a payment authorization channel. (Referred to as a “special service provider” or “SSP”), for example, a tax refund operator to provide a tax refund service for a general sales tax (GST) or value added tax (VAT) refund ( If additional or specialized services are provided by a third party, such as a TRO) system, dynamic currency selection service provider, the merchant system can be configured to communicate with the SSP system. In such a configuration, the merchant system may, for example, determine the amount of transaction available to the merchant system, ordinary tax payables, product descriptions, payment cardholder qualifications to receive tax refunds at the point of sale, etc. Can provide information on transactions. However, since the merchant system cannot use the PAN for payment, the PAN cannot be passed to the SSP system. Therefore, third party systems such as SSP systems cannot provide services that may require the use of PAN.

  Thus, there is a technical problem of how to provide a third party service associated with a payment transaction if a PAN may be required but cannot be used by the merchant system.

Overview

  Aspects of the invention are defined in the claims.

  The embodiment of the claimed subject matter allows third party third parties to handle PANs in a PCI-DSS compliant manner where the merchant system does not hold PANs, while requiring PAN knowledge for transactions. Allows services to be provided. As indicated above, an SSP system is a system of a service provider that provides one or more specialized, unique, or selected services that are out of band with respect to a payment authorization channel. The SSP system can include, for example, one or more TRO host systems for providing a tax refund service (also referred to herein as a tax exemption service (TFS)).

  For example, TFS may be incorporated into the operation of a merchant system (e.g., ECR) that does not require PAN capture by ECR and thus maintains ECR outside the range of PCI-DSS. Upon payment, a dedicated standalone or semi-integrated terminal can be used to capture the PAN. PANs are not routed through ECR and other merchant systems.

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

  In one example, the PREF is generated by the PSP system, where the PREF may be specific to the transaction or PAN and PSP. The PREF is then mapped to a PAN for trading using information held by the PSP system and held in a PCI-DSS compliant manner. Alternatively, the PREF can be generated to be specific to the PAN independently of the payment transaction itself, in which case the PREF then uses information held by the PSP system in a PCI-DSS compliant manner. Mapping directly to the PAN.

  In another example, the PREF is generated by a card scheme system, where the PREF may be specific to the transaction and card scheme system. The PREF is then mapped to a PAN for transactions using information held by the card scheme system and held in a PCI-DSS compliant manner. Alternatively, the PREF can be generated to be specific to the PAN independently of the payment transaction itself, in which case the PREF then uses the information held by the card scheme system in a PCI-DSS compliant manner And mapped directly to the PAN.

  Thus, in the example where the PREF is provided to the merchant system, the merchant system is then authorized to communicate with the PSP system and / or the card scheme system as needed to obtain the PREF to PAN mapping. It is possible to hold a PREF that can be used by a certified third party system and pass it to an approved third party system.

  In a semi-integrated system, the payment terminal can be configured to forward PREF (but not all PANs) to the merchant system along with conventional information authorizing payment using the associated payment card.

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

  If the merchant system communicates with the SSP system, eg, a TRO system for providing TFS services, the PREF can be passed to the SSP system.

  In this way, a PREF that can be mapped to a PAN for payment transactions is passed to the SSP system via the merchant system in a PCI-DSS compliant manner without having to make the merchant system itself compliant with PCI-DSS. Can do.

  Thereafter, the SSP system may optionally connect with the PSP system or card scheme system to link the PREF to the PAN held by the PSP system or card scheme system in a PCI-DSS compliant manner. It is possible to communicate.

  When implemented, one or more aspects can be implemented by one or more computer programs that cause one or more computer systems to implement one or more aspects.

  Exemplary embodiments will be described with reference to the accompanying drawings.

FIG. 1 is a schematic block diagram illustrating an exemplary embodiment that provides tokenization of a PSP system in a trading system. FIG. 2A is a flowchart illustrating an example transaction. FIG. 2B is a flowchart illustrating an example transaction. FIG. 3 is a schematic block diagram illustrating another exemplary embodiment for providing PSP tokenization in a trading system. FIG. 4 is a schematic block diagram illustrating an exemplary embodiment that provides for tokenization of a card scheme system in a trading system. FIG. 5 is a flowchart illustrating an exemplary method for generating unique references. FIG. 6 is a flowchart illustrating another exemplary method for generating unique references. FIG. 7 is an example of a unique reference to the PAN mapping table.

Detailed description

  FIG. 1 is a schematic block diagram of an exemplary embodiment that provides tokenization of a PSP system in a trading system. FIG. 1 also illustrates some operations performed in the trading system of FIG.

  Point-of-sale information management electronic cash register (ECR) 10 is a typical electronic cash register for entering details of one or more products to be purchased by a customer or traveler (hereinafter referred to as a user). It is a merchant system that provides the functions of The ECR 10 provides functions for calculating the total amount of purchases, calculating unpaid taxes, etc., for example in communication with one or more merchant systems (not shown), and for example, purchasing, It is also programmed to perform functions that record details such as customers, inventory, etc. ECR can be one or more processors, storage, user interface devices (eg, displays, touch-sensitive displays, keyboards, etc.), communication interfaces (eg, Ethernet, WiFi, Bluetooth, NFC) Reader, barcode scanner, etc.).

  In the example of FIG. 1, the ECR 10 communicates with a special service provider (SSP) system, such as a tax refund operator host server system, either directly or through another merchant system, such as a merchant server system (not shown). Also configured.

  In the example of FIG. 1, since the ECR 10 does not need to comply with PCI-DSS, the ECR 10 is configured not to receive the entire card membership number (PAN) of the user's payment card. When referring to “payment card”, this term refers to any payment device (eg, conventional debit, credit or prepaid plastic card, electronic card, for example, for electronic payment using a card membership number (PAN). Used generically to describe mobile communication devices that incorporate wallet payment chips). With this in mind, transactions using a user's payment card are performed using an electronic funds settlement payment terminal (EFT) 20. The EFT 20 typically has a display, a keyboard for user input, one or more communication interfaces for connection to one or more of a telephone line, wired or wireless network, ECR, etc. A card reader for reading one or more of a magnetic stripe on a payment card, a chip on the payment card, etc. via contactless (NFC) communication, and a printer, eg, a thermal printer. In the example of FIG. 1, ECR 10 and EFT 20 are interconnected and partial integration is provided between ECR 10 and EFT 20 so that certain information is passed between ECR 10 and EFT 20, but will be described in more detail below. As such, the entire PAN is not sent from the EFT 20 to the ECR 10.

  In operation, if the purchase of the merchandise is processed by the ECR 10 and the total payment is calculated, then the total price of the merchandise can be passed electronically from the ECR 10 to the EFT 20. For example, the merchant enters one or more items (eg, by scanning a barcode on each item using an ECR 10 barcode scanner) and then operates a key on the ECR 10 to enter a payment card. You may be able to pay for one or more items that use. For example, the key may be a physical key switch on the ECR or a key displayed on the ECR touch screen. Thereafter, in accordance with the conventional ECR-EFT message protocol, a message M1 that can include the total price of the product is transmitted from the ECR 10 to the EFT 20. As will be described later, in this example, the 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 for the payment card, including PAN, expiration date, etc., as described in more detail with reference to FIG. The EFT 20 is configured to comply with PCI-DSS.

  The EFT 20 then follows the conventional EFT-PSP message protocol over a secure channel (eg, via a telephone line or computer network) to pass transaction details including the amount of goods and all PANs, expiration dates, etc. And can be configured to communicate with a payment service provider (PSP) system 30. The EFT 20 may be operable to send an approval request message M2 to the PSP system 30, for example. The PSP system 30 is configured to comply with PCI-DSS.

  In the example of FIG. 1, the PSP system 30 provides a payment service platform that implements the infrastructure for connecting the EFT 20 to the merchant acquirer system 30 and other systems. The PSP system 30 may be a PSP computer server system that includes one or more processors, storage, network interfaces, and the like. The PSP system 30 is operable to generate a unique reference (PREF), identified as PSPRef in FIG. 1, that links or maps directly or indirectly to the PAN.

  For example, the PREF can be specific to the transaction and PSP system 30, and the PSP system 30 can be arranged to store a record that includes the PREF, the transaction, and the PAN associated with the transaction, and thus PREF Provides a mapping between PREF and PAN. For example, PSP system 30 may be operable to generate a new, different PREF for each successive transaction that PSP system 30 processes. Each PREF can be a unique number, for example, the PSP system 30 increments (or decrements) the PSP system 30 by incrementing (or decrementing) a given number, eg, 1 for the most recent payment transaction processed by the PSP system 30. Generate a PREF for a given payment transaction to be processed by the system 30. In this way, the PREF can be traced back to the transaction, which can then be used to link to the PAN using records about the transaction maintained by the PSP system 30.

  An example of such a process is shown in FIG.

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

In step 512, the PSP system 30 increments the value of the PREF most recently allocated to the transaction by the PSP system 30 (ie, PREF _i = PREF _i-1 +1). In other examples, any suitable algorithm can be used to generate the next PREF.

  In step 514, the PSP system 30 creates a new transaction record for the new transaction, a new transaction record that stores the TRID along with the new PREF, and a PAN and, for example, EFTA, TRAM, etc. (eg, in the storage of the PSP system 30). To remember).

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

  An example of such a process is shown in FIG.

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

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

  If it is determined in step 612 that a PREF has already been allocated to the PAN, in step 614, the PSP system 30 stores the TRID with the existing PREF for the PAN, and PAN and, for example, EFTA, A new transaction record for the new transaction is created and stored (eg, in the storage of the PSP system 30) that further stores TRAM and the like.

If it is determined in step 612 that no PREF has been allocated to the PAN, then in step 616, the PSP system 30 increments the value of the PREF last allocated to the PAN by the PSP system 30 by one (ie, PREF _i = PREF _i−1 +1). In other examples, any suitable algorithm can be used to generate the next PREF.

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

  As an alternative to, or in addition to, the transaction records identified above in FIGS. 5 and 6, the PSP system 30 may add a simple TREF to a PAN conversion table accessible to map TREF directly to the corresponding PAN. Can be stored.

For example, the table 700 shown in FIG. 7 was described with reference to FIG. 5 or FIG. 6 to link each unique PREF 710 (PREF ₁ to PREF _n ) to each PAN 720 (PAN ₁ to PAN _n ). Can be generated using the method.

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

  The PSP system 30 is additionally configured to include PREF in a message from the PSP system 30 to the EFT 20, for example, an approval response message M7.

  The EFT 20 is operable to communicate PREF to the ECR 10 with, for example, a payment completion message M8, but not all PANs. As a result of the foregoing process, the ECR 10 is used to identify all PANs, without actually providing all PANs, with information kept securely in the mapping within the PSP system 30 record. A possible PREF is provided. Thus, the ECR 10 does not need to be configured to comply with PCI-DSS because it does not hold the entire PAN for the payment card.

  The ECR 10 provides the transaction details in one or more tax refund processing messages M9 that further identify the PREF and PSP system 30 identification information, either directly or through another merchant system (not shown). 100, eg, configured to communicate with a tax refund operator host system 110.

  In the example of FIG. 1, the SSP system 100 includes a TRO host (TROH) system 110, a TRO process (TROP) system 120 for handling TRO operations including integration with external systems (eg, customs and / or tax systems). And a TRO transaction (TROT) system 130 for performing payment and / or withdrawal operations. While TROH system 110 and TROP system 120 are preferably not configured to be compliant with PCI-DSS, TROT system 130 is configured to be compliant with PCI-DSS. Each of the TROH system 110, 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 one or more hardware computers. It can be implemented by one or more virtual servers running the system. The TROH system 110, the TROP system 120, and the TROT system 130 can also be implemented by a computer cloud-based system.

  If the special service is a tax refund service, the ECR 10 may be operable to generate a traditional style paper and / or electronic tax refund form upon purchase. The tax refund form includes transaction details and a transaction identifier (TRID) unique to the tax refund form, unlike PREF. The tax refund form, for example, allows the transaction details to be tracked to determine whether the goods associated with the tax refund form transaction are exported and thus the refund is authorized. For example, a paper refund form can be presented at an airport refund desk, or in response to, for example, a TRO operator scanning a barcode on a paper receipt at the refund desk, or a user can verify a kiosk The electronic form can be retrieved from the TROH system 110 or the TROP host system 120 by entering information at or using a mobile phone application at an airport, for example. To facilitate these operations, the ECR 10 communicates with the TROH system 110, either directly or through another merchant system (not shown), and an identifier (PSPID) for the TRID, PREF, and PSP system 30. Submit an electronic tax refund form that includes transaction details including.

  When the TROH system 110 receives transaction details including TRID, PREF, and PSPID from the ECR 10, the TROH system 110 passes M11 the transaction details including TRID, PREF, and PSPID to the TROP system 120. The TROP system 120 can be configured to communicate with a customs system or an export authorization system (not shown), for example, to receive information regarding whether the goods associated with the purchase have been exported. In this way, if the user authenticates the export of goods, for example, at a refund desk or refund kiosk at an airport or border area, or by using a mobile phone refund authorization application, the TROP system 120 may A notification can be received that the associated merchandise has been exported.

  If the export of goods triggers a tax refund payment, for example by crediting the payment card, the TROP system 120 will be credited to the TRID, PREF, and PSPID details and to the user's payment card. Other details, including monetary amounts, can be made operational, such as M13 that provides TROT system 130.

  In an alternative scenario as discussed below, the product or products associated with the transaction are not exported within a predetermined time from the point of purchase (eg, within 21 days of the initial purchase), and the initial transaction ( For example, when purchasing a product with VAT-OFF or early refund transaction), the associated general sales tax (GST), value added tax (VAT), etc. are not paid, after which the TROP system 120 is configured with TRID, PREF, And the PSPID details, along with other details, including amounts based on the associated general sales tax (GST), value added tax (VAT), etc., which will then be deducted from the user's payment card, along with the TOT system 130 M14 can be made operable.

  However, in either case, the TROP system 120 is not fully PAN because the TROH system 110 and the TROP system 120 may not be PCI-DSS compliant, regardless of whether the debit or credit is made. The TROT system 130 will have to obtain a full PAN in order to be able to perform a credit or debit on the user's payment card account.

  In either case, TROT system 130 receives transaction information from a merchant system (eg, ECR 10) via a first communication channel that includes TROH system 110 and TROP system 120, and the transaction information includes PREF.

  In the example of FIG. 1, the TROT system 130 is configured with the PSP system 30 via a secure communication channel to M15 to obtain a mapping between PREF and all PANs associated with a transaction for a given TRID. Configured to communicate. The secure communication channel forms a payment communication channel and a second communication channel that is out of band with respect to the first communication channel including the TROH system 110 and the TROP system 120.

  In one example, the PSP system 30 sends (ie, pushes) a mapping between PREF and the entire PAN to the TROT system 130, eg, in a batch process, along with other mappings for other PREFs and PANs, for example. Is operable. Thereafter, since the TROT system 130 is also PCI-DSS compliant, it is operable to store all or selected ones of the mappings, and the TROP system to debit or credit the user's account. When receiving a message from 120, we already have a mapping from PREF to the stored PAN, which can be used to credit or debit the user's payment card account as needed. In such a batch process, the PREF and PAN can be broadcast over a secure channel, and the TROT system 130 can either either map all or only the mapping for the PREF needed to process the current transaction. , And to ignore the mapping for any PREF that TROT system 130 does not currently need.

  In another example, the TROT system 130 discovers that a batch process as described above is not used, or has not yet stored the PREF to PAN mapping, and the TROT system 130 can be used for a given PREF. To send a mapping request message M15R to the PSP system 30 and to receive a response message M15 from the PSP system 30 in real time. In this manner, the TROTO system 130 is responsible for authorizing card payments (in this example, from the PSP system 30) over the second communication channel to the mapping from PREF to the PAN associated with the PREF. Receive from a payment authorization channel (PAC) system within an authorization channel.

  Thus, in the example of FIG. 1, the information that enables the TROT system 130 to perform a credit or debit on the user's payment card account is not necessary for the merchant system to know the entire PAN for the user's payment card. This is possible, so the merchant's ECR 10 need not be configured to be PCI-DSS compliant.

  FIG. 2 (consisting of FIGS. 2A and 2B) shows in more detail the operations performed in a particular example of the operation of the system of FIG. An example of this will be described below with reference to FIGS.

  As described above, in the example of FIG. 1, partial integration is provided between the EFT 20 and the ECR 10. This means that, for example, if one or more products are purchased at ECR 10, a message is sent from ECR 10 to EFT 20 according to the ECR-EFT protocol for creating payments (tenders). . The message may include a transaction amount, an ECR transaction ID, a payment transaction type (debit, credit, reservation), etc.

  Thereafter, the EFT 20 is configured to instruct the user 5 to present a payment card to the EFT 20. When the payment card is presented to the terminal (eg, using a magnetic strip reader, chip reader, or near field communication (NFC) reader), the EFT 20 reads the PAN and other information from the payment card. It is possible to operate.

  The EFT 20 is then, for example, a payment card issued in the country in which the EFT 20 is located, or the user 5 is potentially subject to general sales tax (GST) or value added tax (VAT). To authorize a payment card to determine if it is a payment card issued in a different country, which means it is entitled to a refund (collectively referred to herein as a tax refund) The authentication request message is operable to be sent to the PSP system 30. If the return message from the PSP system 30 to the EFT 20 includes metadata that indicates that the user 5 is potentially entitled to a tax refund, the EFT 20 may allow the user 5 to receive a tax refund. It is operable to transmit a message (Additional Data Callback message) to the ECR 10 to instruct the merchant to verify the credentials. For example, the check can be performed manually by the merchant or automatically based on information entered by the user 5 (eg, using the user 5 passport or mobile phone information). If this check confirms that the user is eligible to receive a tax refund, one or more refund options may be provided to user 5.

  It is possible for the operator to present the refund option to the user 5 by explaining the refund option to the user 5, or to send a message to the user 5's mobile phone (eg using WiFi, NFC, etc.) By passing, the options can be displayed to the user 5 on the screen of the ECR 10, for example.

Thus, in the example shown in FIG. 2, the ECR 10 can be operable to provide different services to the user 5. FIG. 2 shows three alternative services identified in FIG. 2 as Refund Off, Fast Refund, and Standard. In the following, these next steps in the process are described.
Indirect refund

  The refund service described in this specification as an indirect refund service means that the user 5 pays the total amount for the product including unpaid tax, and then, for example, when the user 5 exports the product purchased by the user 5 A service that receives a tax refund in the form of another cash card or credit card transaction made at the refund desk.

  This option (e.g., in response to the user 5 notifying the merchant of his / her choice, by activating the physical or displayed key button and / or the ECR 10 screen or the user's mobile In response to the selection (by user 5 using a data exchange via the telephone), ECR 10 is configured to send an updated tender message M1 to EFT 20 that includes the user's indirect refund selection. The updated tender message M1 includes the total amount of transactions including taxes to the EFT 20 and the code TFS_CC = False to indicate that the indirect refund option has been selected.

  Thereafter, the EFT 20 is operable to instruct the user 5 to insert a personal identification number (PIN). In response to the input of the PIN, the EFT 20 is operable to verify that the PIN is correct. The EFT 20 is configured to be compliant with PCI-DSS and is therefore capable of holding and processing the PAN for the payment card. If the PIN is correct, the EFT 20 will send an approval request message M2 to the PSP system 30 for the merchant corresponding to the total amount of the transaction, including tax and TFS_CC = False code to indicate that the indirect refund option has been selected. Operable to transmit. An exemplary authorization request message M2 sent from the EFT 20 to the PSP system 30 includes, for example, PAN, expiration date, card schema, cardholder details, currency code, payment amount, currency, terminal ID, merchant ID, payment transaction Information, such as the type of

As shown in FIG. 1, the PSP system 30 sends an approval request message M3 to the merchant acquirer (MA) system 40. Examples of the approval request message M3 transmitted from the PSP system 30 to the MA system 40 include, for example, PAN, expiration date, card schema, cardholder details, currency code, payment amount, currency, terminal ID, merchant ID, payment Information such as the type of transaction and information specific to the PSP can be included. The MA system 40 then communicates M4 with a card scheme (eg, VISA, MasterCard) system 50 to obtain authorization from the card issuer (not shown) system for the card system used. Here, it is assumed that the payment transaction has been approved by the card issuer system, in which case the card scheme system 50 receives a positive approval request from the card issuer system, and then the card scheme system 50 The message M5 is transmitted to the MA system 40, and then the MA system 40 transmits an approval response message M6 to the PSP system 30. An exemplary authorization response message M6 sent from the MA system 40 to the PSP system 30 may include information such as, for example, an authorization response, a credit card token, an authorization code, an amount, an acquirer code, currency, and the like. The PSP system 30 in the example of FIG. 1 is operable to generate transactions and transaction identification information (PREF) specific to the PSP system 30, and to generate records that map PREF to payment card numbers. is there. For example, the table 700 shown in FIG. 7 is described above with reference to FIG. 5 or FIG. 6 to link each unique PREF 710 (PREF ₁ to PREF _n ) to each PAN 720 (PAN ₁ to PAN _n ). Can be generated using the method described in. Upon receipt of the approval response message M6 from the MA system 40, the PSP system 30 may be operable to send an approval response message M7 to the EFT 20. An exemplary approval response message M7 transmitted from the PSP system 30 to the EFT 20 includes, for example, information such as an approval response, a credit card token, an approval code, an amount, an acquirer code, a currency, and a PSP reference number, PREF, etc. PSP specific information can be included. This therefore includes PREF.

As shown in FIG. 2, the EFT 20 then sends a FinalTransactionResultCallback message M8 containing PREF to the ECR 10, and the EFT 20 displays a message for removing the payment card from the card reader of the EFT 20 to the user 5.
Quick refund

  The refund service described herein as a quick refund is the automatic payment to a payment card used for a purchase transaction in response to the export of the goods after the user 5 has paid the total amount for the goods including unpaid tax. A service that receives a tax refund in the form of a loan. Information input to the computer terminal by the TRO operator at the refund desk, information input to the automation terminal by the user 5 at the airport, mobile phone application using, for example, geolocation information to identify that the mobile phone is at the airport In response to the input information, the export of goods can be identified. Computer terminals, automation terminals, and / or mobile phone applications are operably linked to the TROP system 120 so that a message confirming the export is transmitted to the TROP system 120.

  This option (e.g., in response to the user 5 notifying the merchant of his / her choice, by activating the physical or displayed key button and / or the ECR 10 screen or the user's mobile In response to the selection (by user 5 using a data exchange via telephone), ECR 10 is configured to send an updated tender message M1 to EFT 20 that includes the user's quick refund selection. In this example, the updated tender message M1 indicates the total amount of transactions including taxes to the EFT 20 and that payment card automatic debit / credit has been approved for the selected quick refund option. Code TFS_CC = True.

  Thereafter, the EFT 20 is operable to instruct the user 5 to insert a personal identification number (PIN). In response to the input of the PIN, the EFT 20 is operable to verify that the PIN is correct. The EFT 20 is configured to be compliant with PCI-DSS and is therefore capable of holding and processing the PAN for the payment card. In this example, if the PIN is correct, the EFT 20 will transact the transaction including tax and TFS_CC = True code to indicate that payment card automatic debit / credit is approved for the quick refund option. Is operable to send an approval request message M2 to the PSP system 30 for the merchant corresponding to the total amount. An exemplary authorization request message M2 sent from the EFT 20 to the PSP system 30 includes, for example, PAN, expiration date, card schema, cardholder details, currency code, payment amount, currency, terminal ID, merchant ID, payment transaction Information, such as the type of

  As shown in FIG. 1, the PSP system 30 transmits an approval request message M3 to the MA system 40. Examples of the approval request message M3 transmitted from the PSP system 30 to the MA system 40 include, for example, PAN, expiration date, card schema, cardholder details, currency code, payment amount, currency, terminal ID, merchant ID, payment Information such as the type of transaction and information specific to the PSP can be included. The MA system 40 then communicates M4 with a card scheme (eg, VISA, MasterCard) system 50 to obtain authorization from the card issuer (not shown) system for the card system used. Here, it is assumed that the payment transaction has been approved by the card issuer system, in which case the card scheme system 50 receives a positive approval request from the card issuer system, and then the card scheme system 50 The message M5 is transmitted to the MA system 40, and then the MA system 40 transmits an approval response message M6 to the PSP system 30. An exemplary authorization response message M6 sent from the MA system 40 to the PSP system 30 may include information such as, for example, an authorization response, a credit card token, an authorization code, an amount, an acquirer code, currency, and the like. The PSP system 30 in the example of FIG. 1 is operable to generate transactions and transaction identification information (PREF) specific to the PSP system 30, and to generate records that map PREF to payment card numbers. is there. Upon receipt of the approval response message M6 from the MA system 40, the PSP system 30 may be operable to send an approval response message M7 to the EFT 20. An exemplary approval response message M7 transmitted from the PSP system 30 to the EFT 20 includes, for example, information such as an approval response, a credit card token, an approval code, an amount, an acquirer code, a currency, and a PSP reference number, PREF, etc. PSP specific information can be included. This therefore includes TREF (identified as pspRef in FIG. 2).

As shown in FIG. 2, the EFT 20 then sends a FinalTransactionResultCallback message M8 containing PREF to the ECR 10, and the EFT 20 displays a message for removing the payment card from the card reader of the EFT 20 to the user 5.
With refund

  The refund service described in this specification as a refund is a service in which the user 5 does not pay the total amount for the product, but instead pays a reduction equal to the total amount minus the refund amount, and the refund amount is a small service fee This is equivalent to the amount of GST or VAT that is deducted. Subsequently, if the merchandise is exported within a predetermined time, for example within 21 days, no further transactions will occur. However, if the merchandise is not exported within a predetermined period, at the end of that period, the total amount of GST or VAT is automatically withdrawn from the payment card. Information input to the computer terminal by the TRO operator at the refund desk, information input to the automation terminal by the user 5 at the airport, mobile phone application using, for example, geolocation information to identify that the mobile phone is at the airport In response to the input information, the export of goods can be identified. Computer terminals, automation terminals, and / or mobile phone applications are operably linked to the TROP system 120 so that a message confirming the export is transmitted to the TROP system 120. By not identifying an export within a predetermined period, no export is identified. The TOP system 120 monitors transaction records and expiration of deadlines when no exports have occurred.

  This option (e.g., in response to the user 5 notifying the merchant of his / her choice, by activating the physical or displayed key button and / or the ECR 10 screen or the user's mobile In response to the selection (by user 5 using a data exchange via the telephone), ECR 10 is configured to send an updated tender message M1 containing the user's deduction selection to EFT 20. The updated tender message M1 indicates the total amount of the transaction, including the tax on EFT 20 minus the refund amount, and that the payment card automatic debit / credit is approved for the refund option. Code TFS_CC = True.

  Thereafter, the EFT 20 is operable to instruct the user 5 to insert a personal identification number (PIN). In response to the input of the PIN, the EFT 20 is operable to verify that the PIN is correct. The EFT 20 is configured to be compliant with PCI-DSS and is therefore capable of holding and processing the PAN for the payment card. If the PIN is correct, the EFT 20 will respond to the total value of the transaction, including tax and TFS_CC = True code to indicate that payment card automatic debit / credit has been approved for the refund option For the merchant to perform, it is operable to send an approval request message M2 to the PSP system 30. An exemplary authorization request message M2 sent from the EFT 20 to the PSP system 30 includes, for example, PAN, expiration date, card schema, cardholder details, currency code, payment amount, currency, terminal ID, merchant ID, payment transaction Information, such as the type of

  As shown in FIG. 1, the approval request message M3 is transmitted to the MA system 40. Examples of the approval request message M3 transmitted from the PSP system 30 to the MA system 40 include, for example, PAN, expiration date, card schema, cardholder details, currency code, payment amount, currency, terminal ID, merchant ID, payment Information such as the type of transaction and information specific to the PSP can be included. The MA system 40 then communicates M4 with a card scheme (eg, VISA, MasterCard) system 50 to obtain authorization from the card issuer (not shown) system for the card system used. Here, it is assumed that the payment transaction has been approved by the card issuer system, in which case the card scheme system 50 receives a positive approval response message from the card issuer system and then the card scheme system 50 approves. The response message M5 is transmitted to the MA system 40, and then the MA system 40 transmits an approval response message M6 to the PSP system 30. An exemplary authorization response message M6 sent from the MA system 40 to the PSP system 30 may include information such as an authorization response, a credit card token, an authorization code, an amount, an acquirer code, currency, and the like. The PSP system 30 in the example of FIG. 1 is operable to generate transactions and transaction identification information (PREF) specific to the PSP system 30, and to generate records that map PREF to payment card numbers. is there. Upon receipt of the approval response message M6 from the MA system 40, the PSP system 30 may be operable to send an approval response message M7 to the EFT 20. An exemplary approval response message M7 transmitted from the PSP system 30 to the EFT 20 includes, for example, information such as an approval response, a credit card token, an approval code, an amount, an acquirer code, a currency, and a PSP reference number, PREF, etc. PSP specific information can be included. This therefore includes PREF (identified as pspRef in FIG. 2).

  As shown in FIG. 2, the EFT 20 then sends a FinalTransactionResultCallback message M8 containing PREF to the ECR 10, and the EFT 20 displays a message for removing the payment card from the card reader of the EFT 20 to the user 5.

  Note that in the exemplary operation described above, the use of the TFS_CC = True flag is just one option, which allows the PSP system 30 to later know which PAN to provide to the SSP system 100. I want. The service works without this instruction. In such cases, there are various other options. In one option, the SSP system 100 can query the PSP system 30 for a PAN using TREF (payment basis). In another option, the PSP system 30 pushes all card payment transactions to the SSP system 100, which may need to ignore other payment transactions if, for example, the SSP transaction is linked to payment. Always break TREF into PAN.

  For each option described above, the ECR 10 is then operable to pass an issue request message M9 to the SSP system 100 (eg, the TROH system 110) to request a refund transaction. The issue request message may include PREF (pspRef, payment card metadata, and issue data).

  In response to the issue request, the SSP system 100 (eg, TROH system 110) operates to transmit an issue response message to instruct the ECR 10 to generate (eg, print) a tax refund form (TFF). Is possible.

  The ECR 10 is then operable to send a confirmation check message to the SSP system 100 (eg, TROH system 110) to confirm TFF printing. For the early refund option, the SSP system 100 (eg, TROH system 110) is also operable to return a confirmation check response message to the ECR 10 to confirm receipt of the confirmation check message.

  As discussed above, the SSP system 100 may include one or more SSP host systems (eg, TROH system 110), one or more SSP process systems (eg, TROP system 120) that interface with the merchant's ECR 10. And one or more SSP financial transaction systems (eg, TROT system 130). SSP process system 120 is operable to interface with SSP host system 110 to receive information from SSP host system 110. The SSP process system 120 may be, for example, one or more mobiles of a customs system, a TRO refund desk system, a terminal system, and / or a user's mobile phone that is operable to identify when the user 5 has exported goods. It can also operate to interface with external systems, such as applications. The SSP trading system 130 is adapted to interface with the SSP process system to receive instructions for processing the lending and / or debiting based on the message that defines the PREF and the amount to be debited or debited. It is possible to operate. The SSP payment system is also operable to interface with the SSP payment system via a secure channel to obtain a mapping between the PREF and the associated PAN for the loaned or debited payment card It is.

  As further shown in the exemplary flow of FIG. 2, a TFS_CC = True code is sent from the EFT 20 to the PSP system 30, and the PSP system 30 sends a mapping message M15 that maps the PREF to the PAN to the SSP trading system 130. Is operable. As described with reference to FIG. 1, this is possible as part of a batch process or as a response to a specific request from the SSP trading system 130 to the PSP system 30. The mapping message can identify PREF (as described above, which is unique to PSP system 30 and PAN in the example of FIG. 1), so that PAN and even metadata is uniquely identified. The Since the SSP transaction system 130 is PCI-DSS compliant, it stores all PAN and other payment card details necessary to conduct a Lending M16 and / or Debit M17 transaction based on the PAN. With the account identified by the PAN via the TRO acquirer system 70 shown in FIG. The TRO acquirer system 70 interfaces with the card scheme system 50 in a conventional manner.

  FIG. 1 shows a PREF from a PSP system 30 to a TROT system 130 via EFT 20, ECR 10, TROH system 110, and TROP system 120 using dashed lines labeled S1, S2, S3, S4, and S5. The flow of a message containing This means that tokens that are unique to the PAN (ie, PREF) but do not identify the PAN can be passed through those systems. As a result, such messages are transmitted over a secure channel, but ECR 10, TROH system 110, and TROP system 120 need not be configured to comply with PCI-DSS. FIG. 1 shows a direct PAN mapping from a PSP system 30 to a TROT system 130 over a secure PCI-DSS compliant channel using a secure dashed line labeled S6 and a thick dashed line labeled S6. A flow including As discussed above, both PSP system 30 and TROT system 130 are configured to comply with PCI-DSS.

  FIG. 3 is a schematic block diagram of an exemplary embodiment that provides tokenization of a PSP system in a trading system. The example of FIG. 3 is the same as the example of FIG. 1 except that the EFT 20 is not integrated into the ECR 10. The example of FIG. 3 substantially corresponds to the example of FIG. 1 except that there is no integration between the EFT 20 and the ECR 10, and therefore, for the explanation of FIG. Reference is made to the description of FIG. 2, and similar reference symbols are used in FIGS. The only difference is related to the manner in which information is transferred between the EFT 20 and the ECR 10, an example of which will now be described.

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

  For example, the merchant enters one or more items (eg, by scanning a barcode on the item or each item using the ECR10 barcode scanner) and then operating the ECR10 key. Then, ECR information to be manually input by an operator of the ECR 10 may be generated using a user interface (for example, a keyboard) of the EFT 20. The merchant operator can use the EFT 20 user interface to enter the price of the item shown on the display of the ECR 10.

  As described above with reference to FIG. 1, the EFT 20 reads from the payment card details of the payment card including the PAN, expiration date, etc. for the payment card, for example as described with reference to FIG. Can be programmed. The EFT 20 is configured to comply with PCI-DSS. Also, as explained with reference to FIG. 1, the EFT 20 then pays over the secure channel to pass the transaction details including the amount of goods and all PANs, expiration dates, etc. according to the EFT-PSP message protocol. It can be configured to communicate with a service provider (PSP) system 30. The EFT 20 may be operable to send an approval request message to the PSP system 30, for example. The PSP system 30 is configured to comply with PCI-DSS. In the example of FIG. 3, the PSP system 30 is unique to the PAN and PSP system 30, so for a transaction that provides a mapping between PREF and PAN, the transaction criteria identified as PSPRef in FIG. 3 (PREF ). The PSP system 30 is operable to communicate with a merchant acquirer system (MA system) 40 via a secure channel. Next, the MA system 40 communicates with a scheme system (MasterCard, VISA, etc.) 50 via a secure channel, for example, for real-time approval processing and for payment processing as a batch process in a conventional manner. Configured to do. The MA system 40 and the scheme system 50 are configured to comply with PCI-DSS. The PSP system 30 is additionally configured to include PREF in a message from the PSP system 30 to the EFT 20, eg, an approval response message.

  In the example of FIG. 3, since the EFT 20 is a stand-alone unit and is not integrated with the ECR 10, the PREF cannot be automatically transmitted to the ECR 10. However, in a conventional manner, a printer is provided to the EFT to provide a printed record of card transactions. Accordingly, in the example of FIG. 3, when the EFT prints a printed record (receipt) of a card transaction, the barcode including the representation of PREF (eg, a one-dimensional barcode or a two-dimensional barcode (QR code)). 25 to be included. This barcode can then be scanned using the 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 so that the PREF can be input to the ECR 10. Particularly in the case of 2D barcodes, additional information (card schema, expiration date, card issuer's country name, cardholder name, masked credit card number, etc.) can be coded in the barcode.

  As a result of the foregoing process, the ECR 10 of FIG. 3 can be used to identify all PANs without actually providing all PANs, with the information kept securely in the mapping at the PSP system 30. PREF is provided. Thus, the ECR 10 does not need to be configured to comply with PCI-DSS because it does not hold all PANs for payment cards. Thereafter, in the example of FIG. 3, the PREF can be used in the same manner as the PREF is transferred by partial integration in the example of FIG. The further operation of the example of FIG. 3 corresponds to the operation of FIG. 1 and will not be repeated here.

  FIG. 3 shows the EFT 20, barcode 25 and scanner 15, ECR 10, TROH system 110, and TROP system 120 using thick dashed lines labeled S 1, S 2-1, S 2-2, S 3, S 4, and S 5. The flow of a message including PREF from the PSP system 30 to the TROT system 130 is shown through FIG. This means that tokens that are unique to the PAN (ie, PREF) but do not identify the PAN can be passed through those systems. As a result, such messages are transmitted over a secure channel, but ECR 10, TROH system 110, and TROP system 120 need not be configured to comply with PCI-DSS. FIG. 1 shows a direct PAN mapping from a PSP system 30 to a TROT system 130 over a secure PCI-DSS compliant channel using a secure dashed line labeled S6 and a thick dashed line labeled S6. A flow including As discussed above, both PSP system 30 and TROT system 130 are configured to comply with PCI-DSS.

  As a result, the claimed subject matter embodiments described with reference to FIG. 1 or FIG. 3 and FIG. 2 are in a PCI-DSS compliant manner across interconnected systems where the merchant system does not hold a PAN. While it may be possible to handle PANs, it also allows third party services to be provided by SSP systems that require PAN knowledge for transactions. As described, the SSP system can include, for example, one or more TRO host systems for providing tax refund services. For example, the TFS may be incorporated into the operation of a merchant system (eg, ECR) without having to capture the PAN with the ECR, so that the ECR can be kept out of the PCI-DSS range. For payment, a dedicated stand-alone or semi-integrated terminal can be used to capture the PAN. PANs are not routed through ECR and other merchant systems.

  FIG. 4 is a schematic block diagram of an exemplary embodiment that provides for tokenization of a card scheme system in a trading system. In the example of FIG. 4, PREF is generated by the card scheme system 40 instead of the PSP system 30.

  In the example of FIG. 4, point-of-sale information management electronic cash register (ECR) 10 is exemplary for entering details of one or more products to be purchased by a customer (hereinafter referred to as user 5). It is a merchant system that provides a function of a simple electronic cash register. The ECR 10 provides functions for calculating the total amount of purchases, calculating unpaid taxes, etc., for example in communication with one or more merchant systems (not shown), and for example, purchasing, It is also programmed to perform functions that record details such as 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, an NFC reader, a barcode scanner, and the like.

  In the example of FIG. 4, the ECR 10 is also configured to communicate with a special service provider (SSP) system 100, such as a tax refund operator (TRO) system 100, either directly or through another merchant system (not shown). Is done.

  In the example of FIG. 4, since the ECR 10 does not need to comply with PCI-DSS, the ECR 10 is configured not to receive the entire card membership number (PAN) of the user's payment card. With this in mind, transactions using a user's payment card are performed using an electronic funds settlement payment terminal (EFT) 20. In the example of FIG. 4, partial integration is provided between the ECR 10 and the EFT 20 so that certain information is passed between the ECR 10 and the EFT 20, but as described with reference to the example of FIG. Is not sent from the EFT 20 to the ECR 10. Alternatively, a stand-alone EFT can be provided as in the example of FIG.

  In operation, in the example of FIG. 4, if the purchase of the product is processed by the ECR 10 and the payment total is calculated, then the total price of the product can be passed electronically from the ECR 10 to the EFT 20. For example, the merchant enters one or more items (eg, by scanning a barcode on each item using an ECR 10 barcode scanner) and then operates a key on the ECR 10 to enter a payment card. You may be able to pay for one or more items that use. Thereafter, according to the ECR-EFT message protocol, a message that can include the total price of the product is transmitted from the ECR 10 to the EFT 20. In this example, the 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 for the payment card, including the PAN, expiration date, etc., as described in more detail above with reference to FIG. The EFT 20 is configured to comply with PCI-DSS.

  The EFT 20 then communicates with the Payment Service Provider (PSP) system 30 via a secure channel to pass transaction details including the amount of goods and all PANs, expiration dates, etc. according to the EFT-PSP message protocol. Can be configured. The EFT 20 may be operable to send an approval request message to the PSP system 30, for example. The PSP system 30 is configured to comply with PCI-DSS.

  The PSP system 30 is operable to communicate with a merchant acquirer (MA) system 40, which then, for example, for real-time approval processing and as a batch process in a conventional manner. Is configured to communicate with a scheme system (MasterCard, VISA, etc.) 50 via a secure channel. The MA system 40 and the scheme system 50 are configured to comply with PCI-DSS.

  In the example of FIG. 4, scheme system 50 is specific to PAN and scheme system 50, and thus operates to generate a trading standard (PREF) for a transaction that provides a mapping between PREF and PAN. Is possible.

  The scheme system 50 is additionally configured to include PREF in messages from the scheme system 50 (optionally via the MA system 40) to the PSP system 30, and then the PSP system 30 may include messages, eg, The PREF in the approval response message is configured to be passed to the EFT 20.

  The EFT 20 is operable to communicate PREF to the ECR 10 but not all PANs. As a result of the process described above, ECR 10 is used to identify all PANs, without actually providing all PANs, with information held securely in the mapping within scheme system 50. A possible PREF is provided. Thus, the ECR 10 does not need to be configured to comply with PCI-DSS because it does not hold the entire PAN for the payment card.

  The ECR 10 is one or more messages that further identify the identity of the PREF and PSP, either directly or through other merchant systems (not shown), with transaction details and SSP systems 100, eg, TRO systems 110. Configured to communicate with. If the special service is a tax refund service, the ECR 10 generates a paper and / or electronic tax refund form 12 in a conventional manner when a purchase is made, eg, as described with reference to FIG. Can also be operable.

  In the example of FIG. 4, the SSP system 100, on the one hand, operates with the merchant system 150 for GST / VAT and fee transactions, and as described with reference to FIGS. Alternatively, it is operable to communicate with the TRO acquirer system 70 for debiting.

  However, since ECR 10 does not maintain a full PAN for a payment card for transactions performed using a payment card, ECR 10 may use a PAN as an SSP system to enable transactions with TRO acquirer system 70 to be performed. Cannot pass to 100. Accordingly, the SSP system 100, or more specifically, the portion of the SSP system 100 that is responsible for managing payment transactions (eg, the TROT system corresponding to the TROT system 130 of FIG. 1) is associated with the user's payment card account. All PANs must be acquired in order to be able to perform lending or debiting.

  In the example of FIG. 4, a secure portion of the SSP system 100 configured to comply with PCI-DSS (eg, a TROT system corresponding to the TROT system 130 of FIG. 1) is a transaction for a PREF and a given TRID. Is configured to communicate with the scheme system (s) 50 via a secure communication channel to obtain a mapping between all PANs associated with the. Thus, the secure communication channel forms an out-of-band second communication channel relative to the payment approval channel and the first communication channel formed by the channel used when the ECR 10 communicates with the SSP system 100.

  In one example, the scheme system 50 can map a mapping between PREF and all PANs, eg, in a batch process, along with other mappings for other PREFs and PANs, such as a PCI-DSS compliant part of the SSP system 100 (eg , A TROT system corresponding to the TROT system 130 of FIG. 1. Thereafter, a PCI-DSS compliant portion of the SSP system 100 (eg, a TROT system corresponding to the TROT system 130 of FIG. 1) is also operable to store the mapping because it is also PCI-DSS compliant. Yes (for example, if you receive a message from another part of the SSP system 100 to debit or credit a user account, you already have a mapping from PREF to the stored PAN and use this Thus, the user's payment card account can be lent or borrowed as necessary.

  In another example, a batch process is not used as described above, or a PCI-DSS compliant portion of the SSP system 100 (eg, a TROT system corresponding to the TROT system 130 of FIG. 1) is transferred from the PREF to the PAN. If it finds that the mapping has not yet been stored, it can send a request message for mapping for a given PREF to the scheme system 50 and receive a response message from the scheme system 50 in real time.

  Therefore, in the example of FIG. 4, the PCI-DSS-compliant portion of the SSP system 100 (for example, the TROT system corresponding to the TROT system 130 of FIG. 1) performs lending or debiting with the user's payment card account. The information to enable can be implemented without the merchant system needing to know the full PAN for the user's payment card, so the merchant's ECR 10 needs to be configured to be PCI-DSS compliant There is no.

  FIG. 4 illustrates a PCI-DSS compliant portion of the SSP system 100 (eg, TROOT in FIG. 1) from the scheme system 50 through the PSP system 30, EFT 20, and ECR 10 using a dashed line labeled F1. The flow of a message including PREF up to (TROT system corresponding to the system 130) is shown. This means that tokens that are unique to the PAN but do not identify the PAN (ie, PREF) can be passed through those systems. As a result, such messages are sent over a secure channel, but the ECR 10 need not be configured to comply with PCI-DSS. Accordingly, the PCI-DSS compliant portion of the SSP system 100 receives transaction information from the merchant system (eg, ECR 10) via the first communication channel, and the transaction information includes PREF. FIG. 4 shows a PCI-DSS compliant portion of the SSP system 100 from a scheme system 50 through a secure PCI-DSS compliant channel and a secure PCI-DSS compliant channel using a thick dashed line labeled F2. For example, a flow including mapping to a direct PAN to a TROT system corresponding to the TROT system 130 of FIG. 1 is also shown. Accordingly, the PCI-DSS compliant portion of the SSP system 100 is configured to connect a second communication channel from a payment authorization channel (PAC) system (in this example, from the scheme system 50) in an authorization channel for authorizing card payments. The PREF to PAN mapping associated with the intervening PREF is received. As described above, the PCI-DSS compliant portion of the scheme system 50 and the SSP system 100 (eg, the TROT system corresponding to the TROT system 130 of FIG. 1) are both configured to be compliant with PCI-DSS. On the other hand, the merchant's ECR 10 need not be configured to comply with PCI-DSS.

  Referring to the example trading system shown in each figure, each figure includes a single ECR 10, a single EFT 20, a single PSP 30, a single MA system for ease of illustration and description. 40, only a single card scheme system 50, and / or a single card issuer system 60, and / or a single TRO acquirer system 70, etc. are shown, but one exemplary transaction system is Or a plurality of such devices and systems interconnected by a plurality of networks. Also, as described, the SSP system 100 can include a plurality of TROH 110, TROP 120, and TROT 130 systems.

  Although this specification generically refers to payment cards, card payments, and payment card numbers, the term payment card in the context of this document is simply a conventional plastic physical card and a conventional plastic card. Rather than defining payments using any payment card, rather, any mobile communication device that includes, for example, an electronic card wallet or payment chip and allows electronic payments using, for example, a card membership number (PAN) Note that it will be understood to define credit, debit, and prepaid payment devices. Similarly, in the context of this document, it will be understood that references to card payments represent payments using such payment devices. Also, in the context of this document, references to payment card numbers are used not only to describe physical card PANs, but rather to describe any card membership number (PAN) used with such payment devices. You will understand that it is.

  One or more aspects of the described embodiments perform the method of operation of one or more computer systems described herein when executed on one or more computer systems. It can be implemented by one or more computer programs. The one or more computer programs may be in the form of one or more computer program products such as, for example, instructions maintained on one or more persistent 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 construed to include all such variations and modifications and their equivalents.

Claims (19)

In at least one computer system of a special service provider “SSP”, receiving transaction information from a merchant system via a first communication channel, said transaction information being received by a payment authorization channel system, “PAC” system Including a unique reference “PREF” generated, wherein the PAC system is a system in an approval channel for approving payments, the PREF and the card membership number “PAN” associated with the transaction or the transaction. Receiving transaction information that is specific to the PAC system that generated one of
Receiving at the at least one computer system of the SSP a mapping from the PREF to the PAN associated with the PREF via a second communication channel from the PAC system in the authorization channel;
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 according to the mapping;
A computer-implemented method comprising:   The method of claim 1, wherein the merchant system does not receive or process the PAN.   The method of claim 1 or 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. .   The method according to claim 1, 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 specific to the transaction and the PSP system, and the PREF maps to the PAN for the transaction using information maintained by the PSP system.   5. The method of claim 4, wherein the PREF is specific to the PAN and the PSP system, and the PREF maps to the PAN for the transaction using information maintained by the PSP system.   The method according to claim 1, wherein the PREF is generated by a card scheme system.   The PREF is specific to the transaction and the card scheme system, and the PREF maps to the PAN for the transaction using information held by the card scheme system. Method.   The PREF is unique to the PAN and the card scheme system, and the PREF maps to the PAN for the transaction using information held by the card scheme system. Method.   The at least one computer system of the SSP receives the mapping from the PREF to the PAN associated with the PREF in response to a request message from the at least one computer system of the SSP to the PAC system. The method according to claim 1, wherein the request message includes the PREF.   The at least one computer system of the SSP has the mapping from the PREF to the PAN associated with the PREF as a result of the mapping being pushed from the PAC system to the at least one computer system of the SSP. 10. The method according to any one of claims 1 to 9, wherein:   In response to the payment terminal routing payment transaction information including the PAN captured by the payment terminal to the PSP system, the PSP system returns the PREF for the transaction to the payment terminal. Item 12. The method according to any one of Items 1 to 11.   The method of claim 10, wherein the PREF is provided from the payment terminal to the merchant system upon approval of the payment transaction.   14. The method of claim 13, wherein the payment terminal is configured to forward the PREF to the merchant system along with information confirming approval of the transaction.   The payment terminal prints a code representing the PREF and / or the PREF on a payment slip and transfers the PREF to the merchant system by means of a scanner of the merchant system. The method of claim 13, configured to scan the code representing.   16. A method according to 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.   The at least one system of the SSP determines whether a purchased item was exported within a given time of issuance of a tax refund transaction if the purchased item was not taxed at the time of purchase. The method of claim 16, wherein the method is operable to initiate a payment transaction using the PAN to collect taxes on the purchased goods.   One or more computer programs that, when executed on one or more computer systems, implement the method according to any one of the preceding claims.   A system comprising one or more computers configured and programmed to perform the method of any one of claims 1-17.

Images