KR20190039753A - METHODS AND SYSTEMS FOR SECURE TRANSACTION PROCESSING - Google Patents

Abstract

It becomes easier to handle the primary account number (PAN) in a PCI-DSS compliant manner, in which case the merchant system enables third party services that do not have a PAN but nevertheless require the knowledge of the PAN to perform the transaction .

Description

METHODS AND SYSTEMS FOR SECURE TRANSACTION PROCESSING

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

Such as mobile communication devices such as phones, clocks, etc., having payment cards such as credit or debit cards, or means for electronic payment (hereinafter referred to as payment cards) Using devices, transactions made using credit, debit, and other payment accounts are regulated in accordance with standards set by the Payment Card Industry (PCI) Security Standards Association.

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

Maintaining systems to meet these standards is cumbersome. As a result, retail organizations typically use payment terminals that are separate from merchant front-end and back-end systems (hereinafter generally referred to as merchant systems). An example of a merchant front end system is a merchant point of sale (POS) terminal (e.g., an electronic cash register (ECR)). Examples of merchant back end systems may include inventory and accounting systems. Merchant systems do not fall within the PCI-DSS range because merchant systems such as ECR do not store or process payment card numbers (primary account number, or PAN) used in card transactions. The designated payment terminals are used to receive and process the PAN for payment card transactions and to communicate securely with payment service provider (PSP) acquirer systems in accordance with PCI-DSS. PSP systems are then integrated with card schemes (e.g., MasterCard, VISA, etc.) systems that use secure channels according to PCI-DSS.

In some implementations, merchant systems are completely separate from payment terminals, in which case there are no electronic data paths between payment terminals and merchant systems. In such an implementation, typically, the merchant manually enters the payment details (e.g., transaction quantity) into the payment terminal to perform card payment.

In other implementations, some degree of integration is provided which allows certain transaction details, such as the number of transactions, to be transferred from the merchant system to the payment terminal and / or the payment terminal is configured to communicate only selected information to the merchant system. For example, the selected information passed from the payment terminal to the merchant system may include a verification code for the transaction and a truncated part (last four digits) of the PAN for verifying authentication of the payment using the card. have. However, in such a configuration, the merchant system is not configured to comply with PCI-DSS, so that the entire PAN is not delivered to the merchant system.

Additional or specialized services may be provided by a third party, for example, a service provider (such as a payment service provider that forms part of a payment authentication channel) that provides one or more specialized, Such as a general sales tax (GST) or a value added tax (VAT), to distinguish it from a PSP (hereinafter referred to as a "professional service provider" or "SSP" ), A tax refund operator (TRO) system that provides a tax refund service for refund of a merchant system, a dynamic call selection service provider, and the like, the merchant system may be configured to communicate with the SSP system. In such a configuration, the merchant system may include information relating to the transactions available to the merchant system, such as the number of transactions, a description of goods normally paid, a description of goods, a point of sale And the like. However, the PAN for settlement can not be delivered to the SSP system because the merchant system is not available. Therefore, third-party systems such as SSP systems do not provide services that may require the use of PAN.

Therefore, there is a technical problem of how to provide third party services associated with payment transactions that may require PAN, but the merchant system can not obtain it.

Aspects of the invention are defined in the claims.

An embodiment of the claimed subject matter allows for the handling of the PAN in a PCI-DSS compliant manner when the merchant system does not have a PAN, Enables third party services to be provided by the system. As shown above, the SSP system is a service provider's system that provides one or more specialized, specific, or selected services out of band for the payment authentication channel. The SSP system may include, for example, one or more TRO host systems for providing a tax refund service (also referred to herein as a tax exempt service (TFS)).

For example, a TFS can be embedded in the work of a merchant system (e.g., an ECR) without the PAN being caught by the ECR, thereby keeping the ECR outside the scope of the PCI-DSS. For payment, the PAN may be captured using a specified stand-alone or semi-integrated terminal. PANs are not routed through ECR and other merchant systems.

In the example, the payment terminal routes the payment transaction information including the PAN captured by the payment terminal to the PSP system (the payment service provider system of the payment authentication channel) and then sends the relevant information including the PAN to the card scheme system , The PSP system returns a unique reference (PREF) that is mapped to the PAN to the payment terminal.

In one example, the PREF is generated by the PSP system, in which case the PREF may be unique to the transaction or PAN and PSP. Next, the PREF is mapped to the PAN for the transaction using information held by the PSP system in a PCI-DSS conforming manner. Alternately, the PREF may be generated to be unique to the PAN independent of the payment transaction itself, in which case the PREF is then mapped directly to the PAN using information held by the PSP system in a PCI-DSS conforming manner do.

In another example, the PREF is generated by a card scheme system, in which case the PREF may be unique to the transaction and card scheme system. Next, the PREF is mapped to the PAN for the transaction using the information held by the card scheme system, which is retained in a PCI-DSS conforming manner. Alternatively, the PREF may be generated unique to the PAN independent of the payment transaction itself, in which case the PREF is then mapped directly to the PAN using information held by the card scheme system in a PCI-DSS conforming manner.

Thus, in an example, if the PREF is provided by a merchant system, the merchant system may then be accessed by a third party system that is properly authorized to communicate with the PSP systems and / or the card scheme system to obtain a mapping from the PREF to the PAN. Retains a PREF that can be used, and can pass it to authenticated third-party systems.

In a semi-integrated system, the payment terminal may be configured to send the PREF ( not the entire PAN) to the merchant system with conventional information authenticating a payment using the associated payment card.

In a stand-alone system in which the payment terminal is not connected to the merchant system, the payment terminal may be configured to output a bar code, a QR code, etc. indicating a PREF on the PREF, and / or a payment slip. In such a case, the merchant may then scan the bar code, QR code, etc. indicating PREF, and / or PREF to create a link between the payment transaction and merchant records.

When a merchant system communicates with an SSP system, for example, a TRO system to provide TFS services, the PREF may be delivered to the SSP system.

In this way, a PREF that can be mapped to a PAN for a payment transaction can be delivered to the SSP system via the merchant system in a PCI-DSS conforming manner, without the merchant system itself needing to conform to PCI-DSS.

Next, the SSP system may appropriately communicate with the PSP system or the card scheme system to link the PREF to the PAN maintained by the PSP system or the card scheme system in a PCI-DSS compliant manner.

One or more aspects may be implemented by one or more programs that, when executed, cause one or more computer systems to perform one or more aspects.

Exemplary embodiments are described with reference to the accompanying drawings.
1 is a schematic block diagram illustrating an exemplary embodiment for providing PSP system tokenization in a transactional system.
Figure 2, including Figures 2a and 2b, is an exemplary transaction flow diagram.
3 is a schematic block diagram illustrating another illustrative embodiment for providing PSP tokenization in a transactional system.
4 is a schematic block diagram illustrating an exemplary embodiment for providing card-card system tokenization in a transactional system.
5 is a flow chart illustrating an exemplary method for generating unique references.
6 is a flow chart illustrating another exemplary method for generating a unique reference.
Figure 7 is an illustration of a unique reference to the PAN mapping table.

1 is a schematic block diagram of an exemplary embodiment for providing PSP system tokenization in a transactional system. Figure 1 also illustrates a number of operations performed in the transaction system of Figure 1.

The point-of-sale electronic cash register (ECR) 10 is a merchant system that provides the functions of a typical electronic cash register for input of details of one or more products purchased by a customer or traveler (hereinafter referred to as a user). The ECR 10 may communicate with, for example, one or more merchant systems (not shown) to provide functions, calculate the total purchase amount, calculate the tax payable, etc., , Customers, inventory, and so on. The ECR may include one or more processors, storage, user interface devices (e.g., a display, a touch sensitive display, a keyboard, etc.), a communication interface (e.g., Ethernet, WiFi, Bluetooth, NFC reader, barcode scanner, etc.) .

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

In the example of Figure 1, the ECR 10 is configured not to receive the entire primary account number (PAN) of the user's payment card so that the ECR 10 need not be PCI-DSS compliant. Where a " payment card " is referenced, the term generally refers to any payment device (e.g., a conventional debit, credit, or prepayment card) for electronic payments using, for example, a primary account number Cards, electronic card wallets, mobile communication devices incorporating payment chips, etc.). With this in mind, transactions using the user's payment card are performed using an electronic funds transfer payment terminal (EFT) 20. The EFT 20 generally includes a magnetic interface for the payment card via a display, one or more communication interfaces for connection to one or more of a keyboard, telephone line, wired or wireless network, ECR, etc., contact or non-contact (NFC) A card reader for reading one or more of the chips of the payment card, and a printer, for example a thermal printer. 1, the ECR 10 and the EFT 20 are interconnected and specific information is conveyed between the ECR 10 and the EFT 20, but as will be described below the entire PAN is transmitted from the EFT 20 Partial integration is provided between the ECR 10 and the EFT 20 so as not to be communicated to the ECR 10.

In operation, when the purchase of goods is processed by ECR 10 and the total amount of payment is calculated, the total amount of goods is then electronically transferred from ECR 10 to EFT 20. For example, the merchant may enter one or more merchandise (e.g., by scanning the barcode of each merchandise using the bar code scanner of the ECR 10) and then enable payment of one or more merchandise using the payment card The key of the ECR 10 can be operated. The key may be, for example, a physical key switch of the ECR or a key that is displayed on the touch screen of the ECR. Next, a message M1 is transmitted from the ECR 10 to the EFT 20, which may include the total amount of goods according to the conventional ECR-EFT message protocol. As will be described below, in this example, the selected information may also be conveyed from the EFT 20 to the ECR 10.

The EFT 20 may be programmed to read payment card details, including PAN, expiration date, etc., from the payment card for the payment card, as will be described in more detail with reference to FIG. EFT 20 is configured to be PCI-DSS compliant.

Next, the EFT 20 sends the transaction history (e.g., via a telephone line or a computer network) to deliver transaction details, including quantity of goods, total PAN, expiration date, etc., in accordance with the conventional EFT- To the payment service provider (PSP) system 30 via the Internet. The EFT 20 may operate, for example, to send authentication request messages M2 to the PSP system 30. [ The PSP system 30 is configured to be PCI-DSS compliant.

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

For example, the PREF may be unique to the transaction and PSP system 30, and the PSP system 30 may be adapted to store a record containing the PRE associated with the PREF, the transaction, and the transaction, And PAN. For example, the PSP system 30 may be enabled to generate new and different PREFs for each successive transaction that the PSP system 30 processes. Each PREF may be associated with the PSP system 30 by, for example, increasing (or decreasing) the PREF of the last payment transaction processed by the PSP system 30 by a given number, e.g., Lt; RTI ID = 0.0 > PREF < / RTI > for a given payment transaction to be processed. In this way, the PREF is again linked to the transaction, which can eventually be used to link to the PAN using records of transactions held by the PSP system 30. [

An example of such a process is shown in Fig.

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

At step 512, the PSP system 30 increments the PREF value assigned to the last transaction by the PSP system 30 by one (i.e., PREF _i = PREF _i-1 + 1). In other instances, any suitable algorithm may be used to generate the next PREF.

At step 514, the PSP system 30 generates and stores a new transaction record for the new transaction (e.g., within the storage of the PSP system 30) and the new transaction record stores the TRID along with the new PREF , PAN, and, for example, EFTA, TRAM, and the like.

Alternatively, the PREF may be generated as a unique token of the payment card PAN independent of the payment transaction itself. In such an example, when processing a new payment transaction, the PSP system 30 may check whether it has already created a PREF for a given PAN, and if the PREF has not already been created for the PAN, (Or by reducing) the new PRE for the PAN, otherwise simply use the already generated PREF for that PAN.

An example of such a process is shown in Fig.

At step 610, the PSP system 30 receives an authentication request for a new transaction from the EFT 20. The authentication request includes, for example, the transaction ID (TRID) from the EFT, the address and / or identifier (EFTA) of the EFT, the PAN used in the transaction, the transaction quantity (TRAM)

At step 612, the PSP system 30 examines the existing records to determine if a PREF has already been allocated for the PAN for the new transaction.

If it is determined in step 612 that a PREF has already been assigned for the PAN, then in step 614, the PSP system 30 stores the TRID along with the existing PREF for the PAN, (E. G., Within the storage of the PSP system 30) a new transaction record for a new transaction that further stores the EFTA, TRAM, and so on.

If it is determined in step 612 that a PREF has not already been assigned to the PAN, then in step 616 the PSP system 30 determines the value of the PREF finally assigned to the PAN by the PSP system 30 1 (i. E., PREF _i = PREF _i-1 + 1). In another example, any suitable algorithm may be used to generate the next PREF.

At step 618, the PSP system 30 next stores the TRID with a new PREF for the PAN and creates and stores a new transaction record for the new transaction that further stores the PAN and, for example, EFTA, TRAM, (E.g., within the storage of the PSP system 30).

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

For example, the table 700 shown in FIG. 7 may be used to link each of the unique PREFs 710 (PREF ₁ to PREF _n ) and respective PANs 720 (PAN ₁ to PAN _n ) May be generated using the method described with reference to FIG. 5 or FIG.

The PSP system 30 may operate to send authentication request messages M3 over the secure channel to the merchant buyer (MA) system 40 and receive authentication response messages M6 from the MA system. The MA system 40 may include one or more computer server systems and may be used for real-time authentication processing using, for example, authentication request messages M4 and authentication response messages M5, (MasterCard, Visa, and so on) 50 via secure channels for settlement processing as a service (e. The MA system 40 and the scheme system 50 are configured to be PCI-DSS compliant.

The PSP system 30 is further configured to include the PREF in messages from the PSP system 30 to the EFT 20, e.g., authentication response messages M7.

The EFT 20 may operate, for example, to communicate the PREF to the ECR 10 in the settlement message M8, but not to communicate the entire PAN. As a result of the process described above, a PREF is provided to the ECR 10 that can be used to identify the entire PAN without actually providing the entire PAN, with the information securely retained in the mapping in the records of the PSP system 30 . The ECR 10 therefore does not have the entire PAN of the payment card and therefore need not be configured to be PCI-DSS compliant.

The ECR 10 sends the history of transactions in one or more tax refund processing messages M9 that further identify the PREF and the identity of the PSP system 30 either directly or through other merchant systems (not shown) System 100, e. G., The tax refund operator host system 110. < / RTI >

In the example of FIG. 1, the SSP systems 100 include a TRO host system (TROH) 110 for processing TRO operations, including integration with external systems (e.g., customs and / or revenue systems) (TROP) system 120 for performing TRO process (TROP) system 120, and settlement and / or debit operations. The TROH system 110 and the TROP system 120 are preferably not configured for PCI-DSS compliance, while the TROT system 130 is configured for PCI-DSS conformance. Each TROH system 110, TROP system 120, and TROT system 130 may be implemented by one or more respective hardware server systems, including processors, storage, etc., or they may be implemented on one or more hardware computer systems May be implemented by one or more virtual servers running. The TROH system 110, the TROP system 120, and the TROT system 130 may also be implemented by computer cloud based systems.

When the special service is a tax refund service, the ECR 10 may operate to generate a paper and / or electronic tax refund form in a conventional manner when purchasing is made. The tax refund form includes transaction details, and a transaction identifier (TRID) that is unique to the tax refund form, different from the PREF. The tax refund form allows the details of the transaction to be tracked, for example, to determine if the goods associated with the tax return form transaction have been exported and thus the refund is valid. For example, the document refund form may be filed at the airport's refund window, or the electronic form may be provided, for example, in response to a TRO operator scanning the bar code of a paper receipt at the refund window, or in a confirmation kiosk, Can be retrieved from the TROH system 110 or the TROP host system 120 by entering information using an application of the mobile phone at the airport. In order to facilitate these operations, the ECR 10 may include an electronic transaction containing the TRID, PREF, and the identifier (PSPID) of the PSP system 30, directly or through other merchant systems (not shown) And communicates with the TROH system 110 to communicate the tax refund form.

When the TROH system 110 receives history of transactions including TRID, PREF, and PSPID from the ECR 10, the TROH system 110 updates the history M11 of the transaction including TRID, PREF, and PSPID to TROP To the system (120). The TROP system 120 may be configured to communicate with a customs system or export verification system (not shown), for example, to receive information M12 about whether goods associated with the purchase have been exported. Thus, when the user confirms the export of goods, for example, at the refund counter or refund kiosk at the airport or border area, or by using the mobile phone's refund verification application, the TROP system 120 determines that the goods associated with the transaction have been exported Notification can be received.

For example, if the export of goods triggers the settlement of the tax refund by credit to the payment card, for example, the TROP system 120 may send the details M13 of TRID, PREF, and PSPID to the payment card of the user And to provide the TROT system 130 with other details including the amount.

In an alternative scenario to be described below, one or more merchandise associated with a transaction is not exported within a determined period of time from purchase (e.g., within 21 days of the initial purchase) and is associated with an associated general sales tax (GST), value added tax (For example, a VAT-OFF or early refund transaction), then the TROP system 120 will next determine the associated general sales tax to be debited from the user's payment card , PREF, and PSPID along with other details including quantity based on the GID, GST, VAT, and the like, to the TROT system 130.

However, the TROP system 120 does not have a full PAN since the TROH system 110 and the TROP system 120 may not be PCI-DSS compliant, regardless of whether the withdraw or deposit is made in both cases, (130) must acquire the entire PAN in order to be able to deposit or withdraw money for the user's payment card account.

In both cases, TROT system 130 receives transaction information from a merchant system (e.g., ECR 10) over a first communication channel that includes TROH system 110 and TROP system 120, Gt; PREF < / RTI >

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

In one example, the PSP system 30 sends a mapping M15 between the PREF and the entire PAN to a TROT (e.g., TROT) to communicate (i.e., push) the batch M process with other mappings for, for example, May operate on system 130. The TROT system 130 is also PCI-DSS compliant, so it can then operate to store all or selected of the mappings, thereby, when receiving a message to withdraw or deposit from the user account from the TROP system 120, The mapping to the PAN is already stored and you can use it to deposit or withdraw funds appropriately to your payment card account. In such a batch process, the PREFs and PANs may be broadcast over a secure channel, and the TROT system 130 may capture the entire mappings or capture the mappings of the PREFs necessary to process current transactions, ) To ignore the mappings of any PREFs that are not currently needed.

If the batch process described above is not used in another example, or if the TROT system 130 finds that the mapping from the PREF to the PAN has not yet been stored, the TROT system 130 sends a request message for the mapping of the given PREF M15R to the PSP system 30 and receive the response message M15 from the PSP system 30 in real time. Thus, the TROT system 130 can transfer the PREF from the PREF to the PAN (in this example, from the PSP system 30) via the second communication channel from the payment authorization channel (PAC) system of the authentication channel for authenticating the card payment Lt; / RTI >

Thus, in the example of FIG. 1, the information that enables the TROT system 130 to make deposits or withdrawals to the user's payment card account can be achieved without the merchant system needing to know the entire PAN of the user's payment card , Whereby the ECR 10 of the merchant does not need to be configured to conform to PCI-DSS.

Fig. 2 (formed with Figs. 2A and 2B) shows in more detail the operations performed in the concrete example of the tasks of the system of Fig. The following description of this example refers to Figures 1 and 2.

As described above, partial integration between the EFT 20 and the ECR 10 is provided in the example of FIG. For example, when one or more merchandise is being purchased at the ECR 10, a message is sent from the ECR 10 to the EFT 20 to create a tender in accordance with the ECR-EFT protocol. The message may include the quantity of the transaction, the ECR transaction ID, and the type of payment transaction (withdrawal, deposit, reservation).

The EFT 20 is then configured to prompt the user 5 to present the payment card to the EFT 20. (E. G., Using a magnetic stripe reader, a chip reader, or a near field communication (NFC) reader) so that the EFT 20 reads the PAN and other information from the payment card Can operate.

Next, the EFT 20 determines whether the payment card is a payment card issued in the country where the EFT 20 is located or whether the user 5 is potentially a general sales tax (GST) or a value added tax May be operable to send an acknowledgment message to the PSP system 30 to determine if it is a payment card issued in another country, which means that it is entitled to a VAT refund (hereinafter generally referred to as a tax refund). If the return message from the PSP system 30 to the EFT 20 contains metadata indicating that the user 5 is potentially eligible for a tax refund, then the EFT 20 will send a message to the merchant to accept the tax refund (AdditionalDataCallback message) to the ECR 10 that prompts the user 5 to verify the eligibility. For example, the checking can be done manually by the merchant, or automatically (for example, using the passport of the user 5 or the information of the mobile phone) based on the information entered by the user 5. [ If the check confirms the eligibility of the user 5 to accept the tax refund, then one or more refund options may be offered to the user 5.

The refund options may be presented to the user 5 by the operator 5 describing the options to the user 5 or the options may be provided to the user 5 on the screen of the ECR 10, (E. G., Using WiFi, NFC, etc.) that is communicated to < / RTI >

Therefore, in the example shown in Fig. 2, the ECR 10 can operate to provide different services to the user 5. [ Figure 2 shows three alternative services identified in Figure 2 as Refund Off, Fast Refund, and Standard. These next steps in processing are described below.

Indirect Refund

The refund service described herein as an indirect refund service is a method in which the user 5 pays the full value of the goods including the tax to be paid and then refunds the airports, It is a service that receives tax refunds in the form of separate cash or credit card transactions performed at the counter.

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

Next, the EFT 20 may operate to prompt the user 5 to insert a personal identification number (PIN). In response to the input of the PIN, the EFT 20 can operate to verify that the PIN is correct. The EFT 20 is configured to be PCI-DSS compliant and therefore can retain and process the payment card's PAN. If the PIN is correct then the EFT 20 then sends an authentication request message M2 corresponding to the total value of the transaction including the TFS_CC = False code and tax to indicate that the indirect refund option is selected, to the PSP system 30 for the merchant, Lt; / RTI > Examples of the authentication request message M2 transmitted from the EFT 20 to the PSP system 30 include, for example, the following information: PAN, expiration date, card schema, cardholder information, currency codes, id, merchant id, type of payment transaction, and so on.

As shown in FIG. 1, the PSP system 30 sends an authentication request message M3 to the merchant buyer (MA) system 40. Examples of the authentication request message M3 sent from the PSP system 30 to the MA system 40 include, for example, the following information: PAN, expiration date, card schema, cardholder information, currency codes, id, merchant id, type of payment transaction, etc., and PSP-specific information. Finally, the MA system 40 communicates with a card scheme (e.g., VISA, MasterCard) system 50 (M4) to obtain authentication from the card issuer's system (not shown) for the card system used. Here, it is assumed that the payment transaction is authenticated by the card issuer system, in which case a positive authentication request is received from the card issuer system by the card scheme system 50 and the card scheme system, in turn, Message M5, and the MA system in turn sends an authentication response message M6 to the PSP system 30. Examples of authentication response messages M6 sent from the MA system 40 to the PSP system 30 include, for example, the following information: authentication response, credit card token, authentication code, quantity, buyer codes, . The PSP system 30 of the example of FIG. 1 may be operable to generate a transaction and a transaction identity (PREF) unique to the PSP system 30 and to generate a record mapping the PREF to the payment card number. For example, the table 700 shown in FIG. 7 may be used to link each of the unique PREFs 710 (PREF ₁ to PREF _n ) to the respective PANs 720 (PAN ₁ to PAN _n ) Can be generated using the method described with reference to FIG. 5 or FIG. Upon receiving the authentication response message M6 from the MA system 40, the PSP system 30 may operate to send an authentication response message M7 to the EFT 20. Examples of the authentication response message M7 sent from the PSP system 30 to the EFT 20 include, for example, the following information: authentication response, credit card token, authentication code, quantity, buyer codes, Number, PREF, and so on. This therefore includes the PREF.

2, the EFT 20 then sends a FinalTransactionResultCallback message M8 containing the PREF to the ECR 10 and the EFT 20 sends a message to remove the payment card from the card reader of the EFT 20 To the user (5).

Quick refund

The refund service, which is described herein as a quick refund, pays the total value of the goods containing the tax to be paid by the user 5, and then, in response to the export of the goods, ) Is a service that accepts tax refunds. The export of the goods may include information entered into the computer terminal by the TRO operator of the refund window, information input by the user 5 to the automated terminal of the airport, e.g., geographic location (e.g., geolocation < / RTI > in a mobile phone application. The computer terminal, the automated terminal, and / or the mobile telephony application are operatively linked to the TROP system 120 such that a message confirming the export is sent to the TROP system 120. [

In response to the selection of this option (e. G., By the user 5 operating the physical or displayed key button in response to the merchant informing him of his choice, and / Or by using a data exchange via the screen of the user's mobile phone), the ECR 10 is configured to send the updated tenderer message M1 to the EFT 20, which includes the user's choice of quick refund. In this example, the updated tenderer message M1 includes the total value of the transaction including the tax on the EFT 20 and the code TFS_CC = True to indicate that the automatic withdrawal / deposit of the payment card has been authorized for the selected quick return option do.

Next, the EFT 20 may operate to prompt the user 5 to enter a personal identification number (PIN). In response to the input of the PIN, the EFT 20 may operate to verify that the PIN is correct. The EFT 20 is configured to be PCI-DSS compliant and therefore can retain and process the payment card's PAN. If the PIN in this example is correct then EFT 20 then responds to the total value of the transaction including the TFS_CC = True code and tax to indicate that the automatic withdrawal / deposit of the payment card for the selected quick refund option is authorized Lt; RTI ID = 0.0 > M2 < / RTI > Examples of the authentication request message M2 transmitted from the EFT 20 to the PSP system 30 include, for example, the following information: PAN, expiration date, card schema, cardholder information, currency codes, id, merchant id, type of payment transaction, and so on.

As shown in FIG. 1, the PSP system 30 sends an authentication request message M3 to the MA system 40. Examples of the authentication request message M3 sent from the PSP system 30 to the MA system 40 include, for example, the following information: PAN, expiration date, card schema, cardholder information, currency codes, id, merchant id, type of payment transaction, etc., and PSP-specific information. Finally, the MA system 40 communicates with a card scheme (e.g., VISA, MasterCard) system 50 (M4) to obtain authentication from the card issuer's system (not shown) for the card system used. Here, it is assumed that the payment transaction is authenticated by the card issuer system, in which case a positive authentication request is received from the card issuer system by the card scheme system 50 and the card scheme system, in turn, Message M5, and the MA system in turn sends an authentication response message M6 to the PSP system 30. An example of the authentication response message M6 sent from the MA system 40 to the PSP system 30 may include the following information: authentication response, credit card token, authentication code, quantity, buyer codes, currency, The PSP system 30 of the example of FIG. 1 may be operable to generate a transaction and a transaction identity (PREF) unique to the PSP system 30 and to generate a record mapping the PREF to the payment card number. Upon receiving the authentication response message M6 from the MA system 40, the PSP system 30 may operate to send an authentication response message M7 to the EFT 20. Examples of the authentication response message M7 sent from the PSP system 30 to the EFT 20 include, for example, the following information: authentication response, credit card token, authentication code, quantity, buyer codes, Number, PREF, and so on. This therefore includes TREF (identified as pspRef in FIG. 2).

2, the EFT 20 then sends a FinalTransactionResultCallback message M8 containing the PREF to the ECR 10 and the EFT 20 sends a message to remove the payment card from the card reader of the EFT 20 To the user (5).

Stop refunding

The refund service described herein as refund denial means that the user 5 does not pay the full value of the goods but instead pays the reduced quantity equal to the limit of the refund quantity in the total quantity and the refund quantity is reduced by a nominal fee Service corresponding to the number of GST or VAT. Thereafter, if the goods are exported within a predetermined time, for example 21 days, no further transaction occurs. However, if the goods are not exported within a predetermined period, then the total quantity of GST or VAT is automatically debited from the payment card at the end of the period. The export of the goods may include information entered into the computer terminal by the TRO operator at the reimbursement window, information input by the user 5 to the automated terminal of the airport, e.g., geographic location to identify that the mobile telephone is at the airport May be identified in response to input information to the mobile phone application being used. The computer terminal, the automated terminal, and / or the mobile phone application are operatively linked to the TROP system 120 such that a message confirming the export is sent to the TROP system 120. [ Non-export is identified by the absence of identification of the export within a predetermined period of time. The TOP system 120 monitors the expiration of the records of the transaction and the time limit if no export occurred.

In response to the selection of this option (e. G., By the merchant operating the physical or displayed key button in response to the user 5 informing the merchant of his choice) and / Or by using a data exchange via a screen of the user's mobile phone), the ECR 10 is configured to send the updated tenderer message M1 to the EFT 20, including the user's choice of refund suspension. The updated tenderer message M1 includes a code TFS_CC = True indicating that the automatic withdrawal / deposit of the payment card has been authorized for the refund stop option and the total refund value of the transaction including the tax refunded to the EFT (20) do.

Next, the EFT 20 may operate to prompt the user 5 to insert a personal identification number (PIN). In response to the input of the PIN, the EFT 20 can operate to verify that the PIN is correct. The EFT 20 is configured to be PCI-DSS compliant and therefore can retain and process the payment card's PAN. If the PIN is correct, then the EFT 20 sends an authentication request message (TFS_CC = True) indicating the automatic withdrawal / deposit of the payment card for the refund stop option is authenticated, corresponding to the total value of the transaction including the code and tax M2 to the PSP system 30 for the merchant. Examples of the authentication request message M2 transmitted from the EFT 20 to the PSP system 30 include, for example, the following information: PAN, expiration date, card schema, cardholder information, currency codes, id, merchant id, type of payment transaction, and so on.

An authentication request message M3 is sent to the MA system 40, as shown in Fig. Examples of the authentication request message M3 transmitted from the PSP system 30 to the MA system 40 include, for example, the following information: PAN, expiration date, card schema, cardholder information, currency codes, id, merchant id, type of payment transaction, etc., and PSP-specific information. Finally, the MA system 40 communicates with the card scheme (e.g., VISA, MasterCard) system 50 (M4) to obtain authentication from the card issuer's system (not shown) for the card system used, . Here, it is assumed that the payment transaction is authenticated by the card issuer system, in which case a positive authentication response message is received from the card issuer system by the card scheme system 50, which in turn authenticates the MA system 40 Response message M5, and the MA system in turn sends an authentication response message M6 to the PSP system 30. [ An example of the authentication response message M6 sent from the MA system 40 to the PSP system 30 may include the following information: authentication response, credit card token, authentication code, quantity, buyer codes, currency, The PSP system 30 of the example of FIG. 1 may be operable to generate a transaction and a transaction identity (PREF) unique to the PSP system 30 and to generate a record mapping the PREF to the payment card number. Upon receiving the authentication response message M6 from the MA system 40, the PSP system 30 may operate to send an authentication response message M7 to the EFT 20. Examples of the authentication response message M7 sent from the PSP system 30 to the EFT 20 include, for example, the following information: authentication response, credit card token, authentication code, quantity, buyer codes, Number, PREF, and so on. This therefore includes PREF (identified as pspRef in FIG. 2).

2, the EFT 20 then sends a FinalTransactionResultCallback message M8 containing the PREF to the ECR 10 and the EFT 20 sends a message to remove the payment card from the card reader of the EFT 20 To the user (5).

It should be noted that, in the example of the operations described above, the use of the TFS_CC = True flag is only one option, which allows the PSP system 30 to know which PANs to provide to the SSP system 100 at a later time do. The service can operate without this indication. In such cases, there are various other options. In one option, the SSP system 100 may query the PAN for the PSP system 30 using a TREF (payment reference). In another option, the PSP system 30 pushes all of the card payment transactions to the SSP system 100, and the SSP system 100 decomposes the TREF into PANs whenever necessary, and other payment transactions can, for example, If linked with this payment, it will be ignored.

In each of the options described above, the ECR 10 may then operate to forward the issuance request message M9 to the SSP system 100 (e. G., 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 issuance request, the SSP system 100 (e.g., the TROH system 110) issues an issuance order to instruct the ECR 10 to generate (e.g., print) a tax return form (TFF) Response message. ≪ / RTI >

Next, the ECR 10 may operate to send a check message to the SSP system 100 (e.g., the TROH system 110) to confirm the printing of the TFF. In the case of the early refund option, the SSP system 100 (e. G., The TROH system 110) may also operate to return a check check response message to the ECR 10 to confirm receipt of the confirmation check message .

As discussed above, SSP systems 100 may include one or more SSP host systems (e.g., TROH system 110), one or more SSP process systems (e.g., TROP system 120), and one or more SSP financial transaction systems (e.g., TROT system 130). The SSP process system 120 may operate to interface with the SSP host system 110 to receive information from the SSP host system 110. The SSP process system 120 may also include one or more of the user's mobile phone, which may be operable to determine, for example, a customer system, a TRO redemption window system, a terminal system, and / Lt; RTI ID = 0.0 > mobile applications. ≪ / RTI > The SSP transaction system 130 may operate to interface with the SSP process system to receive messages defining the PREF and instructions for processing deposits and / or withdrawals based on the quantity to be deposited or withdrawn. The SSP payment system may also operate to interface with the SSP payment system via a secure channel to obtain mappings between the PREF and the PAN associated with the payment card to be deposited or withdrawn.

2, if the TFS_CC = True code is sent from the EFT 20 to the PSP system 30, the PSP system 30 maps the PREF to the PAN in the SSP transaction system 130 And to transmit the mapping message M15. As described with reference to FIG. 1, this may be a part of a batch process, or a response to a specific request to the PSP system 30 from the SSP transaction system 130. The mapping message may identify the PREF (unique to the PSP system 30 and the PAN as described above in the example of FIG. 1), and thus the PAN is uniquely identified, plus the metadata is uniquely identified. Since the SSP transaction system 130 is PCI-DSS compliant, it can store and process other payment card details needed to perform deposit M16 and / or withdraw M17 transactions based on the overall PAN and PAN, With the account identified by the PAN via the TRO Buyer systems 70 shown in FIG. The TRO Buyer system 70 interfaces with the card scheme systems 50 in a conventional manner.

Figure 1 shows a block diagram of a TROT system using the dotted lines labeled S1, S2, S3, S4 and S5 from the PSP system 30 to the EFT 20, the ECR 10, the TROH system 110 and the TROP system 120, ≪ / RTI > shows the flow of messages including the PREF to the system 130. FIG. This means that tokens that are unique to the PAN (i.e., PREF), but that do not identify the PAN, can be passed through these systems. Consequently, although such messages are transmitted by a secure channel, the ECR 10, TROH system 110, and TROP system 120 do not need to be configured to be PCI-DSS compliant. Figure 1 also shows a direct flow of a secure message from the PSP system 30 to the TROT system 130 over a secure PCI-DSS compliant channel, including a mapping to the PREF and PAN with a thick dashed line labeled S6. As shown above, both the PSP system 30 and the TROT system 130 are configured to PCI-DSS compliance.

3 is a schematic block diagram of an exemplary embodiment for providing tokenization of a PSP system in a transaction system; The example of FIG. 3 is the same as the example of FIG. 1 except that the integration of the EFT 20 for the ECR 10 is not provided. 3 corresponds substantially to the example of FIG. 1, apart from the absence of the integration between the EFT 20 and the ECR 10, so that the description of FIGS. 1 and 2 above for the description of FIG. 3 And the same reference numerals as in Fig. 3 and Fig. 1 are used. The only difference relates to the manner in which information is passed 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, a merchant may enter one or more merchandise (e.g., by scanning the barcode of each merchandise using a barcode scanner of the ECR 10) and then the user interface of the EFT 20 ) To manipulate the keys of the ECR 10 to generate for ECR information to be manually entered by the operator of the ECR 10. [ The merchant operator can use the user interface of the EFT 20 to enter the value of goods displayed on the display of the ECR 10.

As described above with reference to FIG. 1, the EFT 20 can be programmed to read payment card details from the payment card, including, for example, a PAN for a payment card, an expiration date, etc., as described with reference to FIG. have. EFT 20 is configured to be PCI-DSS compliant. 1, the EFT 20 may then send a payment through the secure channel to deliver the details of the transaction, including the quantity of goods, the total PAN, the expiration date, etc., in accordance with the EFT-PSP message protocol And is configured to communicate with a service provider (PSP) system 30. The EFT 20 may be enabled to send authentication request messages to the PSP system 30, for example. The PSP system 30 is configured with PCI-DSS compliance. In the example of Figure 3, the PSP system 30 also generates a transaction reference (PREF) identified as PSPRef in Figure 3 for transaction specific to the PAN and PSP system 30, thereby mapping between the PREF and the PAN Lt; / RTI > The PSP system 30 is operable to communicate with the merchant buyer system (MA system) 40 via a secure channel. As a result, the MA system 40 is configured to communicate with a scheming system (MasterCard, VISA, etc.) 50 via secure channels, for example, for real-time authentication processing and for settlement processing as a batch process in a conventional manner . The MA system 40 and the scheme systems 50 are configured with PCI-DSS conformance. The PSP system 30 is further configured to include PREF in messages from the PSP system 30 to the EFT 20, e.g., authentication response messages.

In the example of Figure 3, the EFT 20 is a stand-alone unit and can not automatically communicate PREF to the ECR 10 because it is not integrated into the ECR 10. However, in a conventional manner, the EFT is provided with a printer that provides printed records of card transactions. Thus, in the example of FIG. 3, the EFT is a barcode (e.g., a one-dimensional barcode or a two-dimensional barcode (QR code)) 25 containing a representation of a PREF when outputting a printed record (receipt) ). This bar code can then be scanned to capture the information of the bar code using the scanner 15 of the ECR 10. The ECR 10 may be configured to extract the PREF from the information appearing in the barcode such that the PREF may be input to the ECR 10. Specifically, in the case of 2D barcodes, additional information (e.g., card schema, expiration date, card issuer country, cardholder name, masked credit card number) may be coded in the barcode.

As a result of the process described above, the ECR 10 of FIG. 3 is provided with a PREF that can be used to identify the entire PAN with information securely retained in the mapping of the PSP system 30 without actually being provided with the entire PAN. Therefore, the ECR 10 therefore does not need to be configured to conform to PCI-DSS, since it does not have a full PAN of the payment card. In the example of FIG. 3, the PREF may then be used in the same manner as the PREF transmitted by partial integration in the example of FIG. The additional operation of the example of FIG. 3 corresponds to that of FIG. 1 and is not repeated here.

FIG. 3 shows the EFT 20, barcode 25 and scanner (not shown) from the PSP system 30 of messages containing the PREF as thick dashed lines labeled S1, S2-1, S2-2, S3, S4, 15, the ECR 10, the TROH system 110, and the TROT system 130 via the TROP system 120. FIG. This means that tokens that are unique to the PAN but do not identify the PAN (ie PREF) can be passed through these systems. As a result, ECR 10, TROH system 110, and TROP system 120 do not need to be configured for PCI-DSS conformance, although such messages are transmitted by secure channels. 1 also shows a flow of a secure message comprising a mapping from a PSP system 30 to a TROT system 130 via a secure PCI-DSS compliant channel to a PREF and PAN, with a thick dashed line labeled S6. As discussed above, both the PSP system 30 and the TROT system 130 are configured to be PCI-DSS compliant.

As a result, the embodiment of the claimed subject matter described with reference to FIG. 1 or 3 and 2 allows the merchant system to process the PAN in a PCI-DSS compliant manner across interconnected systems that do not have a PAN On the other hand, it is possible to provide third party services by SSP systems that require knowledge of PAN for transactions. As described, the SSP system may include, for example, one or more TRO host systems to provide tax refund services. For example, TFS can be integrated into the operation of a merchant system (e. G., ECR) without PAN needing to be captured by ECR, thus keeping ECR out of the scope of PCI-DSS. For payment, the PAN may be captured using a designated stand-alone or semi-integrated terminal. The PAN may not be routed through the ECR and other merchant systems.

4 is a schematic block diagram of an exemplary embodiment for providing card-scheme system tokenization in a transactional system. In the example of FIG. 4, the PREF is generated by the card scheme system 40 rather than the PSP system 30.

4, a point-of-sale electronic cash register (ECR) 10 stores the functions of a typical electronic cash register for entry of the 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. The ECR 10 provides functions such as, for example, total purchase amount in communication with one or more merchant systems (not shown), calculating the tax to pay, and the like, And records the history of the program. The ECR may include one or more user interfaces, such as one or more processors, storage, one or more displays, a keyboard, an NFC reader, a barcode scanner, and the like.

In the example of Figure 4, the ECR 10 may also be connected to a professional service provider (SSP) system 100, for example a tax refund operator (TRO) system 100, directly or through other merchant systems .

In the example of Figure 4, the ECR 10 is configured not to receive the entire primary account number (PAN) of the user's payment card so that the ECR 10 need not be PCI-DSS compliant. With this in mind, transactions using the user's payment card are performed using an Electronic Funds Transfer (EFT) 4, specific information is conveyed between the ECR 10 and the EFT 20, but the entire PAN is not transmitted from the EFT 20 to the ECR 10, as described in the example of FIG. 10) and the EFT 20 are provided. As an alternative to this, a standalone EFT may be provided as in the example of FIG.

In operation, when the purchase of goods in the example of FIG. 4 is processed by the ECR 10 to calculate the total amount of payment, the total amount of goods can then be electronically transferred from the ECR 10 to the EFT 20 . For example, the merchant may enter one or more merchandise (e.g., by scanning the barcode of each merchandise using a barcode scanner of the ECR 10) and then enable payment of one or more merchandise using the payment card The key of the ECR 10 can be operated. Next, a message is transmitted from the ECR 10 to the EFT 20, which may include the total amount of goods in accordance with the ECR-EFT message protocol. In this example, the selected information may also be passed from the EFT 20 to the ECR 10.

The EFT 20 can be programmed to read payment card details from the payment card, including the PAN expiration date for the payment card, as described in more detail above with reference to FIG. The EFT 20 is configured with PCI-DSS compliance.

Next, the EFT 20 communicates with the payment service provider (PSP) system 30 through a secure channel to deliver transaction details including the quantity of goods, the total PAN, and the expiration date according to the EFT-PSP message protocol . The EFT 20 may be enabled to send authentication request messages to the PSP system 30, for example. The PSP system 30 is configured with PCI-DSS compliance.

The PSP system 30 may be operable to communicate with the merchant buyer (MA) system 40 and the merchant buyer system may ultimately be used for real-time authentication processing, for example, as a batch process in a conventional manner, (MasterCard, VISA, etc.) 50 via the channels. The MA system 40 and the scheme system 50 are configured with PCI-DSS compliance.

In the example of FIG. 4, the scheme system 50 may operate to generate a transaction reference (PREF) for transactions unique to the PAN and scheme system 50, thereby providing a mapping between PREF and PAN.

The scheme system 50 is further configured to include a PREF in messages from the scheme system 50 (optionally via the MA system 40) to the PSP system 30, Lt; / RTI > to authentication response messages, e. G., Authentication response messages.

The EFT 20 communicates the PREF to the ECR 10, but the entire PAN can operate to not communicate. As a result of the process described above, the ECR 10 is provided with a PREF, which can be used to identify the entire PAN with information securely retained in the mapping of the scheme system 50, without actually providing the entire PAN . Therefore, the ECR 10 does not need to be configured to conform to PCI-DSS since it does not have the entire PAN of the payment card.

The ECR 10 may transfer the history of transactions with the SSP system 100, for example, the TRO system 110, directly or through other merchant systems (not shown), to one that further identifies the identity of the PREF and the PSP The above message is configured to communicate. If the professional service is a tax refund service, the ECR 10 also generates a paper and / or electronic tax refund form 12 at the time of purchase, in the usual manner, for example, as described with reference to Figure 1 Can operate.

In the example of FIG. 4, the SSP system 100 communicates with merchant systems 150 for GST / VAT and fee transactions, on the one hand, as described with reference to FIGS. 1 and 2, and also user deposits and / And to communicate with the TRO Buyer system 70 for withdrawals.

However, since ECR 10 does not retain the entire PAN of the payment card with respect to the transaction made using the payment card, ECR 10 sends PAN to SSP system (e. G. 100). Thus, that portion of the SSP system 100 (e.g., the TROT system corresponding to the TROT system 130 of FIG. 1) that is in charge of the management of the SSP system 100, or more specifically of the settlement transactions, The entire PAN must be acquired in order to be able to make deposits or withdrawals in connection with the payment card account.

In the example of FIG. 4, the secure portion of the SSP system 100 configured to be PCI-DSS compliant (e.g., the TROT system corresponding to the TROT system 130 of FIG. 1) is associated with the entire PAN associated with the transaction for a given TRID (S) 50 over a secure communication channel to obtain a mapping between the scheme system (s) 50 and the PREF. Thus, the secure communication channel forms a first communication channel formed by the channel in which the ECR 10 communicates with the SSP system 100 and a second communication channel out of band for the payment authentication channel.

In one example, the scheme system 50 may map the mapping between the PREF and the entire PAN to the PCI-DSS matching portion of the SSP system 100 (e.g., the TROT system corresponding to the TROT system 130 of FIG. 1) , For example communicating in a batch process with other PREFs and other mappings to the PANs. Next, the PCI-DSS conforming portion of the SSP system 100 (e.g., the TROT system corresponding to the TROT system 130 of FIG. 1) is also PCI-DSS conformant and can operate to store the mappings, (E. G., From another part of the SSP system 100), it is already storing the PREF to PAN mapping and sending it to the user's payment card account as appropriate To be deposited or withdrawn.

In another example, if the batch process described above is not used, or if the PCI-DSS matching portion of the SSP system 100 (e.g., the TROT system corresponding to the TROT system 130 of FIG. 1) It may send a request message for the mapping for a given PREF to the scheme system 50 and receive the response message in real time from the scheme system 50 .

Thus, in the example of FIG. 4, the PCI-DSS conforming portion of the SSP system 100 (e.g., the TROT system corresponding to the TROT system 130 of FIG. 1) may initiate a deposit or withdrawal of the user's payment card account Can be made without the merchant system needing to know the entire PAN of the user's payment card so that the ECR 10 of the merchant does not need to be configured for PCI-DSS conformance.

Figure 4 shows the PCI-DSS conforming portion of the SSP system 100 (e. G., Via the PSP system 30, the EFT 20, and the ECR 10) from the scheming system 50, The TROT system corresponding to the TROT system 130 of FIG. 1). This means that tokens that are unique to the PAN but do not identify the PAN (ie PREF) can be passed through these systems. As a result, although such messages are transmitted by secure channels, the ECR 10 need not be configured to conform to PCI-DSS. Thus, the PCI-DSS conforming portion of the SSP system 100 receives transaction information from the merchant system (e.g., ECR 10) over the first communication channel, and the transaction information includes the PREF. 4 also shows the PCI-DSS conforming portion of the SSP system 100 (e. G., The TROT system (FIG. ≪ RTI ID = 130), to the PREF and to the PAN. Thus, the PCI-DSS conforming portion of the SSP system 100 may be accessed from the Payment Authentication Channel (PAC) system (from the scheme system 50 in this example) of the authentication channel for authenticating card settlement via the second communication channel PREF and the mapping to the associated PAN. As discussed above, the scheme system 50 and the PCI-DSS conforming portion of the SSP system 100 (e.g., the TROT system corresponding to the TROT system 130 of FIG. 1) are both configured to be PCI-DSS compliant While the ECR 10 of the merchant does not need to be configured to conform to PCI-DSS.

A single EFT 20, a single PSP 30, a single MA system 40 (see FIG. 4) for reasons of illustration and description in each of the figures, ), A single card scheme system 50, and / or a single card issuer system 60 and / or a single TRO buyer system 70, etc. are illustrated, an exemplary transaction system may include a plurality of such devices And systems. Also, as described in the description of the invention, the SSP system 100 may include a plurality of TROH 110, TROP 12, and TROT 130 systems.

Although the description herein generally refers to payment cards, card payments, and payment card numbers, the expression of a payment card in the context of this document merely refers to payments made using conventional plastic physical cards and conventional plastic payment cards But not limited to, any credit, debit, and / or credit card, including, for example, mobile electronic devices that incorporate electronic card purses or payment chips and permit electronic payments, for example, using a primary account number It should be understood that it is to be understood that pre-payment devices are defined. Similarly, it should be understood that reference to card payments in the context of this document refers to payments using such payment devices. It should also be understood that references to payment card numbers in the context of this document are not used to refer only to the physical card's PAN but rather to any primary account number (PAN) used with such payment device.

One or more aspects of the described embodiments may be implemented by one or more computer programs that, when executed on one or more computer systems, implement the methods of operation of one or more computer systems as described herein. One or more computer programs may be in the form of instructions stored on one or more computer program products, e.g., on one or more non-transient storage media.

Various modifications and alterations will become apparent to those skilled in the art upon a complete understanding of the above disclosure. The following claims are to be construed as including all such modifications and corrections as well as all of their equivalents.

Claims (19)

A computer-implemented method,
In at least one computer system of a special service provider (" SSP "), receiving transaction information from a merchant system over a first communication channel, (PREF) generated by a PAC system, wherein the PAC system is a system in an authentication channel for authenticating a payment and the PREF is a PAC system that has generated the PREF, And a transaction or a primary account number (" PAN ") associated with the transaction;
Receiving, at the at least one computer system of the SSP, a mapping from the PREF to the PAN associated with the PREF over a second communication channel from the PAC system in the authentication channel; And
Processing, by the at least one computer system of the SSP, a service associated with the transaction information using the PAN associated with the PREF, in accordance with the mapping;
≪ / RTI > 2. The method of claim 1, wherein the merchant system does not receive or process the PAN. 3. 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. 4. The method of any one of claims 1 to 3, wherein the PAC system that generated the PREF is a payment service provider (" PSP ") system. 5. The method of claim 4, wherein the PREF is unique to the transaction and the PSP system, and wherein the PREF is mapped to the PAN for the transaction using information held by the PSP system. 5. The method of claim 4, wherein the PREF is unique to the PAN and the PSP system, and wherein the PREF is mapped to the PAN for the transaction using information held by the PSP system. 4. The method according to any one of claims 1 to 3, wherein the PREF is generated by a card scheme system. 8. The method of claim 7, wherein the PREF is unique to the transaction and the card scheme system, and wherein the PREF is mapped to the PAN for the transaction using information held by the card scheme system. 8. The method of claim 7, wherein the PREF is unique to the PAN and the card scheme system, and wherein the PREF is mapped to the PAN for the transaction using information held by the card scheme system. 10. The system according to any one of the preceding claims, wherein the at least one computer system of the SSP is adapted to receive, from the PREF in response to a request message to the PAC system from the at least one computer system of the SSP, And wherein the request message comprises the PREF. 10. The system according to any one of claims 1 to 9, wherein the at least one computer system of the SSP is a computer system in which the mapping is pushed from the PAC system to the at least one computer system of the SSP, And receiving the mapping from the PREF to the PAN associated with the PREF. 12. The method of any one of claims 1 to 11, wherein in response to the payment terminal routing payment transaction information including PANs captured by the payment terminal to the PSP system, Returning the PREF to the payment terminal. 11. The method of claim 10, wherein the PREF is provided to the merchant system from a payment terminal in an authorization of a payment transaction. 14. The method of claim 13, wherein the payment terminal is configured to send the PREF to the merchant system with information confirming authentication of the transaction. 14. The merchant system of claim 13, wherein the payment terminal prints a code representing the PREF and / or the PREF on a payment slip, and sends the PREF to the merchant system by a scanner of the merchant system And to scan the code representing the PREF and / or the PREF. 16. The method of any one of claims 1 to 15, wherein the at least one system of the SSP is at least one system of a tax refund service provider. 17. The system of claim 16, wherein the at least one system of the SSP determines whether purchased goods were exported within a given time of issuing a tax refund transaction if the tax was not charged at the time of purchase, and to initiate a settlement transaction using the PAN to recover the settlement transaction. 17. A computer program for implementing the method of any one of claims 1 to 17 when executed on one or more computer systems. 17. A system, comprising: one or more computers configured and programmed to perform the method of any one of claims 1 to 17.

Images