JP7222453B2 - System, apparatus, server and method for transaction security - Google Patents

Description

Detailed description of the invention

The techniques of the present invention relate to security.

Viewed from a first exemplary configuration, a transaction terminal system, a storage circuit for storing information indicative of a terminal system currency of the transaction terminal system; an input circuit for receiving a token identifier; The identifier includes information indicative of the user currency and information associated with the user payment account information, such that the input circuit compares the terminal system currency and the user currency and, if there is a difference, provides a currency selection offer. and, in response to selection of the user currency, for transmitting a message to cause transactions to be conducted using the user currency with respect to the user payment account, the message comprising user payment account information and A transaction terminal system is provided that includes associated information.

Viewed from a second exemplary configuration, the steps of storing information indicative of the terminal system currency of the transaction terminal system and receiving a token identifier, the token identifier being information indicative of the user currency and the user receiving including information associated with payment account information; and comparing the terminal system currency and the user currency, causing a currency selection suggestion to be displayed if a difference exists. and responsive to selection of the user currency, sending a message to cause transactions to be conducted using the user currency with respect to the user payment account, the message comprising information associated with the user payment account information. A method is provided, comprising:

Viewed from a third exemplary configuration, an input circuit for receiving user payment account information and information indicative of a user currency; A data processing apparatus is provided comprising processing circuitry for generating, the token identifier including information indicative of a user currency, and output circuitry for providing the token identifier.

Viewed from a fourth exemplary configuration, receiving user payment account information and information indicative of the user currency; and generating a token identifier using the payment account information and information indicative of the user currency. and providing the token identifier, wherein the token identifier includes information indicative of the user currency.

Viewed from a fifth exemplary configuration, an input circuit configured to receive a message to cause a transaction to be conducted in a user currency with respect to a user payment account, the message an input circuit including information associated with payment account information; a storage circuit including a plurality of mappings from the information to user payment account information; responsive to receiving the message, retrieving the user payment account information from the storage circuit; A server is provided comprising a processing circuit configured to cause transactions to be conducted.

Viewed from a sixth exemplary configuration, receiving a message to cause a transaction to be conducted in a user currency with respect to a user payment account, the message comprising information associated with the user payment account information storing in a storage circuit a plurality of mappings from the information to user payment account information; retrieving the user payment account information from the storage circuit in response to receiving the message; is performed.

For purposes of illustration only, the techniques of the present invention will be further described with reference to the embodiments shown in the accompanying drawings.
1 is a block diagram representing entities that may be included in a card payment system; FIG. 1 is a block diagram of an exemplary POS terminal according to some embodiments; FIG. 1 is a block diagram of an exemplary payment service provider according to some embodiments; FIG. 1 is a block diagram of an exemplary tokenizer or tokenized data processor in accordance with some embodiments; FIG. Fig. 3 shows an example of a token identifier as generated by a tokenizer or tokenized data processor; Fig. 3 shows an example of a token identifier as generated by a tokenizer or tokenized data processor; FIG. 4 illustrates an exemplary communication exchange according to some embodiments; FIG. 4 illustrates another exemplary communication exchange when a claim is about to be settled, according to some embodiments; FIG. 7 illustrates a process 700 performed by a POS terminal when conducting a payment in some embodiments. FIG. 8 illustrates a process 800 performed by tokenizer 300 to generate token identifier 400 according to some embodiments. FIG. 9 illustrates a process 900 performed by PSP 200 during settlement, according to some embodiments.

Prior to discussing embodiments with reference to the accompanying drawings, the following description of embodiments and associated advantages is provided.

According to one exemplary arrangement, a transaction terminal system, a storage circuit for storing information indicative of a terminal system currency of the transaction terminal system; an input circuit for receiving a token identifier; compares the input circuit, including information indicative of the user currency and information associated with the user payment account information, the terminal system currency and the user currency, and if a difference exists, a currency selection presentation is provided; and processing circuitry, responsive to selection of the user currency, for transmitting a message to cause transactions to be conducted using the user currency with respect to the user payment account, the message associated with the user payment account information. A trading system terminal is provided that includes information to be provided.

A transaction terminal may, for example, take the form of a computer or point of sale device (POS device). The device can be used to receive payment for services. The transaction terminal system is configured to store information indicative of the currency of the transaction terminal system using storage circuitry. For example, a trading terminal system provided in the United Kingdom may be configured to store that the currency of the trading terminal system is British Pounds (GBP). On the other hand, a transaction terminal system configured in Australia may store the fact that the currency of the transaction terminal system is the Australian dollar (AUD). An input circuit is used to receive the token identifier. The token identifier may have been previously obtained as a result of the customer providing his card details, e.g., when the card is presented while checking in at a hotel and a pre-authorized transaction is conducted. be done. By storing and utilizing the token identifier, which is typically captured at this point, instead of the Primary Account Number (PAN), organizations using transaction terminal systems can avoid the need to securely store the PAN. It only needs to store a token identifier that can be released and instead returned in a pre-authorization response. These can be stored, for example, in a Property Management System (PMS) or an Electronic Cash Register (ECR), which can then use the tokens at a later time, such as checkout in the case of hotels. can. In fact, even if a hacker were able to obtain token identifiers, they would be largely unable to process them, as token identifiers are not generally available. The token identifier is such that it contains information indicative of the user currency and information associated with the user payment account information. Information indicative of the user currency may simply be an identifier for the user currency itself. For example, the abbreviation GBP may be used to indicate that the user currency is British pounds. The user currency may differ from the system currency of the transaction terminal system in that the user currency is the currency in which the user of the payment account wishes to be charged and/or operates his account. Typically, these two currencies will differ when a foreign visitor visits another country. In particular, the visitor's account will operate using one currency and the transaction terminal system itself will operate using the local currency. User payment account information may be PAN. The information associated with the User Payment Account Information is such that it is impossible to identify the User Payment Account Information from the information, even though there may be a one-to-one mapping between the information and the User Payment Account Information. can be Processing circuitry compares the terminal system currency and the user currency. If there is a difference between these, a currency selection offer is given. From here, the user may be able to select whether they wish to be billed using terminal system currency or user currency. If a user currency is selected, a message is sent to cause the transaction to be conducted in the user currency with respect to the user payment account. This is accomplished by messages containing information associated with user payment account information. In other words, the message need not contain sensitive user payment account information such as PAN. As a result of this, as can occur at checkout in the case of a hotel, the user has no user payment account information at the time the transaction is made, and the ) to engage in trading. For example, a retailer could be given a token or otherwise store the user payment account information at a later time (e.g., at check-in in the case of a hotel). may have previously been converted to . A token identifier containing information indicative of the user currency may provide a choice as to whether the final transaction should be conducted using the user currency or the terminal system currency. Therefore, dynamic currency conversion can be performed despite the absence of sensitive user payment account information.

In some embodiments, the message includes the token identifier. The token identifier may include other information passed along with the user payment account information in messages sent to allow the transaction to occur.

In some embodiments, the token identifier includes a subset of user payment account information. By providing a subset of the user payment account information within the token identifier, it may be possible to immediately perform a sanity check as to whether the token identifier corresponds with the user payment account information. In particular, if a subset of the user payment account information does not match the token identifier, it can be readily determined that the token identifier does not correspond to the user payment account information. For example, a user may be able to distinguish between different PANs using token identifiers.

In some embodiments, the user payment account information is the primary account number and the subset of the user payment account information is the last x digits of the user's primary account number. Typically, the last digit of the PAN is a checksum digit used to verify that the other digits in the number are correct. Therefore, it is convenient to use the last few digits of the PAN as a designator or identifier for a particular PAN.

In some embodiments, the token identifier comprises a random or pseudo-random number. By providing a random or pseudo-random number, it is possible to effectively prevent any conversion of the token identifier back to user payment account information. Note that the random numbers generated by the computer system may not be truly random, and thus may instead be pseudo-random. Such a number can be large enough that it is impossible or effectively impossible for two numbers to have the same random number.

In some embodiments, the token identifier includes the result of applying a one-way hash to the user payment account information. One-way hashing is a mathematical process used to transform between input and output domains. A one-way hash function is such that the same input always produces the same result. As a result, it is possible to ascertain the token identifier of the user account information, but since the hash function is one-way, converting the result of the hash function back to user payment account information is mathematically intractable. be. However, multiple inputs may produce the same result using the hash function (a scenario referred to as a "collision", which is so unlikely that it is considered infeasible) .

In some embodiments, the token identifier includes an operator's designator of the user payment account. The indicator may be in the form of a card scheme, for example. Such tokens can be used to give the payment gateway a "clue" at the time the payment should be made, eg, the server to which the transaction request should be issued.

In some embodiments, the token identifier includes at least one digit, the token identifier includes a checksum value for the at least one digit, and the checksum value verifies the integrity of other characters (eg, digits). used for verification. This is accomplished by performing a mathematical function on one or more of the characters in the identifier. In theory, even a small change to one character would be expected to change the checksum. Thus, if a checksum operation is performed on every character and differs from the checksum that forms part of the token identifier, it can be assumed that one or more characters of the entire identifier are incorrect.

In some embodiments, the checksum value is implemented using the Luhn algorithm, which is one of several examples of checksum algorithms (also known as the modulus 10 algorithm). In general, the Luhn algorithm is known to detect any single digit error and most transpositions of adjacent digits. Such a checksum algorithm is therefore suitable for verifying number input where a single digit may be in error, or where two digits may have been entered transposed. be.

In some embodiments, the information indicative of user currency includes a billing currency code identifier, currency code identifier, or country code identifier. The currency may be, for example, as identified by ISO4217 and the country code may be, for example, as identified by ISO3166.

In some embodiments, the token identifier includes one or more leading non-numeric characters. For example, it is possible to distinguish the token identifier from other account identifiers, such as PAN, by giving it one leading non-numeric character. In some other embodiments, the token identifier consists entirely of numbers.

In some embodiments, the token identifier consists of 16 alphanumeric characters. Many existing systems are configured to accept payment account numbers as 16 alphanumeric characters. For example, most credit card numbers are 16 digit numbers. Thus, it is possible to take advantage of existing systems that expect payment numbers to be 16 characters long by providing the token identifier as 16 alphanumeric characters.

In some embodiments, the input circuitry includes a keypad for entering token identifiers. Such a keypad may be, for example, an alphanumeric keypad allowing letters and/or numbers to be inserted. Therefore, the token identifier can be entered using the keypad.

In some embodiments, the input circuitry comprises an interface for connecting to a processing device from which the token identifier can be received. Input circuitry can be used to issue payments through a computing system or a more sophisticated vending device. For example, such a sales device may interface with an inventory system or an ongoing billing system that allows charges incurred by a person over a period of time to be billed. Such a system would be able to track the token identifier and, as a result, bill the user directly at a later date without having to store the PAN or require the user to provide payment details multiple times. can do.

In some embodiments, the amount of the transaction is determined as a result of entering information about the goods or services to be purchased.

In some embodiments, the processing circuitry is configured to operate in at least one of a sales mode of operation in which the transaction is for a sale and a refund mode of operation in which the transaction is for a refund. Thus, a transaction may be a sale in which money is deducted from the PAN in exchange for goods or services being purchased by the user, or a previous transaction may be voided resulting, for example, in the return of goods or cancellation of services. As a result, money may be returned to the PAN with respect to refunds. In either case, currency conversion may be performed. Currency conversions for refunds can use currency conversions that occurred in the sales transaction that is to be voided, or can be done using more current conversion data (e.g., period or transaction amount difference is greater than the threshold).

In some embodiments, in response to determining that the terminal system currency and the user currency are different, the processing circuitry uses the current currency conversion value from the transaction currency to the user currency and the current currency conversion value. At least one of the transaction amounts converted by the remote server is configured to be downloaded from the remote server to the transaction terminal system. Accordingly, the transaction terminal system may be able to obtain up-to-date information regarding currency conversions between the terminal system currency and the user currency. Therefore, the conversion is performed based on the actual converted value between the two currencies rather than old or estimated values that may introduce uncertainty into the nature of the transaction being conducted.

In some embodiments, the currency selection presentation includes at least one of the current currency conversion value and the amount of the transaction converted to the user currency using the current currency conversion value. In the selection presentation, the selection may be made based on current currency conversion values available in the transaction terminal system for currency conversion between the user selected currency and the transaction terminal system currency. Additionally or alternatively, the amount of the transaction converted to the user-selected currency may be provided by providing the amount of the transaction, the user determining the amount of the transaction using the current currency conversion value. No need. By providing current currency conversion values, the user can determine whether a good exchange rate is being offered. Therefore, in some embodiments, both information can be provided during the currency selection presentation.

In some embodiments, the input circuitry is configured to receive information associated with the user payment account information and data related to the user currency, and the processing circuitry receives information associated with the user payment account information. and, in response to receiving data related to the user currency, generating encrypted information by encrypting at least information associated with the user payment account information, and transmitting the encrypted information and the data related to the user currency. configured to transmit to a server, the trading terminal system comprising receiving circuitry for receiving a token identifier in response to transmitting the encrypted information; the trading terminal system having an output for outputting the token identifier; Have a circuit. By presenting data related to payment account information and user currency at the transaction terminal system, the transaction terminal system can request the corresponding token identifier from the server. The token identifier may then be used, for example, by displaying the token identifier to a user or operator, storing the token identifier locally for later use, or printing the token identifier on the merchant copy of the receipt and/or Or by outputting the token identifier in some other manner, such as sending the token identifier to a PMS or ECR for storage or later use (eg, hotel checkout). Thus, by first presenting the user payment account information, further payments can be processed using the retrieved token without the card being re-presented. The DCC can be presented at a later point in time because the token identifier contains information indicative of the user currency, determined from data related to the user currency.

According to another exemplary arrangement, input circuitry for receiving user payment account information and information indicative of the user currency; and generating a token identifier using the payment account information and information indicative of the user currency. A data processing apparatus is provided, comprising processing circuitry for processing the token identifier, the token identifier including information indicative of the user currency, and output circuitry for providing the token identifier.

Such data processors are capable of generating token identifiers based on user payment account information. The token identifier is then used to conduct transactions involving the user payment account information without the user payment account information being provided. In this manner, the token identifier can be used as a substitute for user payment account information, thus obviating the need for such sensitive information to be transmitted. This also allows the recipient of the token identifier to initiate transactions without being required to store sensitive information that could be leaked or hacked. The token identifier generated by the data processing device contains information indicative of the user currency. In this way, the originator of the transaction can determine whether the user should be given the opportunity to have the transaction converted to the user's currency. This determination can be made even if the user payment account information does not exist at the time of the transaction. Note that in some embodiments, the user payment account information itself may indicate the user payment account information. Additionally, in some instances, the data processing device may have card reading capabilities for locally reading cards and generating tokens. In such cases, those card reader functions themselves may be able to receive information indicative of the user currency from the transaction card.

In some embodiments, the information indicative of user currency is one of user payment account information, currency code, or issuer country code. Currency code and/or user payment account information (eg, in the form of primary account number) and/or issuer country code may be obtained, for example, via the EMV chip.

In some embodiments, the input circuitry includes magnetic stripe read circuitry. Magnetic stripe reader circuitry is used to read magnetic stripes that can be found on several different payment cards. Such magnetic stripes can be used to store small amounts of information such as user payment account information and information indicative of user currency. Once the magnetic stripe data is obtained, the processing circuitry can then generate a stored token identifier. User payment account information and other sensitive information can then be destroyed.

In some embodiments, the input circuitry includes EMV circuitry. Europay, Mastercard and Visa (EMV) chips are used to provide so-called "chip and pin" functionality, where a payment card is associated with the card and can only be operated in conjunction with a PIN number known to the user. be. By providing EMV circuitry, information stored on the chip can be accessed when the user presents the card and enters the associated PIN.

In some embodiments, the input circuitry includes NFC communication circuitry. As noted above, the input circuitry may include Near Field Communication (NFC) communication circuitry that may be used to relay information between the payment card and the data processing device. Such information may include information indicative of user payment account information and user currency. Again, once the token identifier is generated, such sensitive information can be discarded.

In some embodiments, the input circuitry includes a keypad. By providing a keypad, the input circuitry allows the user to manually enter information. Such information may include information indicative of user payment account information and user currency. As noted above, such information may be discarded once a token identifier is generated by the processing circuitry with such information being input.

In some embodiments, the input circuitry includes communication circuitry for communicating with one or more additional data processing devices over a network. By providing communication circuitry as part of the input circuitry, the data processing device can receive information indicative of, for example, user payment account information and user currency. Once the token identifier is generated by processing circuitry, such sensitive information (eg, user payment account information and/or information indicative of user currency) can be discarded.

In some embodiments, the output circuitry includes communication circuitry for communicating with one or more additional data processing devices over a network. The output circuitry can be used to provide token identifiers generated by the processing circuitry back to the merchant for later use. Token identifiers are designed for use by specific payment service providers and are therefore restricted from use by third parties. Additionally, both the token identifier and the user payment account information can be provided to the payment service provider to allow transactions to be conducted with respect to the payment account information when provided the token identifier.

In some embodiments, the output circuit is configured to provide the token identifier to the sender of the user payment account information, eg, the merchant.

In some embodiments, user payment account information is provided in encrypted form. User payment account information may be encrypted by the terminal system using a key that is not available to the operator of the terminal system, but only to the data processor.

According to another exemplary arrangement, an input circuit configured to receive a message to cause a transaction to be conducted in a user currency with respect to a user payment account, the message being a user payment an input circuit containing information associated with account information; a storage circuit containing a plurality of mappings from the information to user payment account information; A server is provided comprising a processing circuit configured to perform:

The server can be used to conduct transactions using information associated with the user payment account information rather than the user payment account information itself. Information associated with user payment account information may take the form of token identifiers as described above. A storage circuit at the server contains a plurality of mappings between information associated with user payment account information and user payment accounts. Thus, given the information associated with the user payment account information, it is possible at the server to determine the user payment account information for which the transaction is to be performed. After receiving the message, the processing circuitry, using the storage circuitry, thus determines the user payment account information given the information associated with the user payment account information, thus performing a transaction with respect to the user payment account information. be implemented. In this manner, transactions can be performed using only information associated with the user payment account information, rather than the user payment account information itself. Additionally, by providing data relating to the user currency, transactions can be conducted using the user currency.

In some embodiments, the message includes user currency.

In some embodiments, the message includes an indication that the user currency is a currency other than the currency associated with the sender of the message. Thus, instead of providing a user currency that can be stored or otherwise retrieved by the server, the message is simply a currency other than the currency that the user currency is associated with the sender of the message, and the transaction may include an indication that the is to be done using the user currency. The server is then responsible for determining the currency in which the transaction will be conducted, ie the user currency, and then ensuring that the transaction is conducted in the user currency. This can reduce bandwidth requirements between the merchant and the server, as the currency in which the transaction will be conducted does not itself need to be transmitted.

In some embodiments, the message includes the transaction amount and the current currency conversion value, or the transaction amount converted to the user currency using the current currency conversion value. By providing the transaction amount and currency conversion value, the server can determine the value and currency of the transaction to be made. Alternatively, by providing an already converted transaction amount, the server need only ensure that the transaction is made for the requested amount in terms of the user's currency. This latter process has the advantage of reducing the processing load on the server, since the server does not have to perform the conversion itself.

Specific embodiments will now be described with reference to the drawings.

FIG. 1 shows a block diagram representing entities that may be included in a card payment system and the transfer of information between such entities in a typical card payment system. Cardholder 10 obtains transaction card 60 from issuer 40 . Issuer 40 may typically be a retail banking or financial institution. Issuer 40 provides transaction card 60 for use at point-of-sale (POS) terminal 70 located at merchant 20 . For example, transactions initiated by a hotel property management system (PMS) or restaurant interface electronic cash register (ECR) with a POS terminal 70 are acquired and processed by the acquirer 30 via the card scheme manager 50. be. Examples of current card schemes include MasterCard, VISA, Diners Club and American Express schemes. Cardholder 10 uses his or her transaction card 60 to conduct financial transactions at merchant 20 (eg, hotel). For example, if cardholder 10 is a credit cardholder, the cardholder may swipe his or her card through a POS terminal 70 located at merchant 20's facility (or insert his or her card into the terminal). or bring their contactless card close to the terminal). POS terminal 70 extracts account details from transaction card 60, including the card number that identifies the financial account of cardholder 10 with the associated financial institution (ie, issuer 40). POS terminal 70 is connected or connectable to network 80 . For example, smaller merchants 20 may connect to network 80 through a dial-up connection to the PSTN network. Alternative public or private local and/or wide area networks based on industry standards, or proprietary wired or wireless technologies and network connections may be used for central processing of transactions. The account details and transaction details are then sent to and received by the acquirer 30 . The transaction details may include the POS terminal 70 ID, the merchant 20 ID, the transaction card 60 number, the value of the transaction requested, and the currency of the transaction requested. Once the transaction details are received, the acquirer 30 sorts the transactions into groups according to card scheme and sends the transactions pertaining to the card scheme to the appropriate card scheme manager 50 (only one is shown in FIG. 1). do. The first few digits of the transaction card 60 number typically identify the card scheme. The card scheme manager 50 then sorts the transactions it receives by the issuer 40 of the transaction card 60 . This can be accomplished by looking up the bank identification number (BIN), which is often the first six digits of the credit card's primary account number (PAN). Each issuing bank is assigned one or more BINs, so that all cards issued by that issuer 40 start with one of those BINs. Once the transaction details are received, issuer 40 sends a response back to card scheme manager 50 . Card scheme administrator 50 forwards the response to acquirer 30, who responds back to POS terminal 70 with an authorization code.

If the transaction is successful, the issuer 40 then manages the transfer of funds between the cardholder's 10 account and the card scheme administrator 50 . Card scheme administrator 50 transfers the funds to acquirer 30 , who then settles the funds to merchant 20 . The acquirer 30 transmits the merchant's 20 account description and the issuer transmits the cardholder's 10 account description. In many cases, the acquirer 30 is also the issuer 40 . If the merchant's 20 local currency does not match the cardholder's 10 local currency, for example, if the cardholder 10 is traveling abroad, the cardholder 10 will correctly assess the true value of the transaction. can be difficult. This is because traditionally transactions are conducted in the currency of the merchant 20 and the card scheme administrator 50 accommodates the required foreign exchange. Dynamic Currency Conversion (DCC) allows cardholder 10 to conduct transactions at merchant 20 in their own local currency instead of merchant 20's local currency. A fee is charged for the service. The advantage of DCC, when used in the correct terms, is that cardholders 10 can verify the exact value found in their account description from their respective issuer 40 at the time of the transaction. In a DCC transaction, it is the acquirer 30, not the card scheme manager 50 and/or the issuer, that handles the required foreign exchange.

In some circumstances, merchant 20 may keep account details obtained from transaction card 60 on file. For example, in the hotel industry it is common to capture account details in a property management system (PMS) so that cardholder 10 can quickly check out of the hotel at the end of their stay. . Additionally, costs incurred during the stay can be retained by the PMS and billed together at the end of the guest's stay. However, account details can be accidentally leaked or maliciously obtained (hacked) by a third party. Therefore, more recently, some merchants 20 have moved to systems that use tokens. In such systems, the POS terminal 70 obtains account details and transmits the account details (usually in encrypted format) to a tokenization service that may be associated with the acquirer 30 . The Tokenization Service uses the account details to generate a token, which is sent back to the merchant 20 for storage in the merchant's PMS. Future transactions (such as checkouts) can be conducted from the merchant 20 at the acquirer 30 using the generated tokens, thus the merchant 20 need not continue to hold sensitive account data. do not have. However, tokens can only be used by merchant 20 in conjunction with acquirer 30, so loss of token information is not necessarily detrimental to cardholder 10 or any of the other entities involved.

The method of implementing DCC described above relies on the BIN (and possibly additional digits of the card number) to retrieve the corresponding user currency. However, BINs may not be available if tokens are provided in place of user payment account data. The present embodiment includes information that associates the user's payment currency with the token, thus allowing DCC to occur despite the absence of user payment account information (eg, at checkout).

FIG. 2 shows a block diagram of an exemplary POS terminal 70. As shown in FIG. POS terminal 70 transmits and receives information via modem 110 or other network communication system or device. POS terminal 70 includes RAM and ROM (eg, EEPROM) components, memory 120 containing instructions stored in ROM that control the operation of the controller of POS terminal 70 . Additionally, the currency of the POS terminal (eg, merchant) is stored in ROM.

The POS terminal 70 is responsible for obtaining the PAN of the transaction card and using the PAN to request a token identifier from the tokenized data processing service 300 . This may be done during a pre-approval operation in which the issuer withholds transactions for 30 days so that the merchant can determine that sufficient funds are available. In response, the POS terminal can receive the token identifier. By storing the token identifier (eg in the PMS or ECR) rather than the PAN itself, security can be improved as the sensitive PAN is not stored by the merchant. Token identifiers, on the other hand, are unique to merchants and payment service providers and therefore cannot be easily reused by third parties.

A request to provide a token may include additional data regarding the cardholder's 10 currency. In some cases, user currency is stored on and provided by transaction card 60 . Such information may be obtained by using one or more of Near Field Communication (NFC) module 140 , smart card reader 150 , card reader 160 , keypad 170 , or EMV circuitry 195 . In other cases, the RAM may store a table 130 containing a list of current domestic (DOM) issuers of cards. The DOM issuer can be identified by the BIN number on the transaction card. The RAM can also store a list of international (INTL) issuers of cards by issuer's BIN number and a list of billing currencies for that INTL issuer. For example, for INTL issuer 132459, issuer 40 may charge cardholder 10 using a currency that is not supported by card scheme administrator 50, and DCC may be provided to cardholder 10 as a result. do not have. Of course, the RAM does not have to store the entry for BIN number 132459, which has the same effect. Those skilled in the art will appreciate that some of the information shown in table 130 may be stored external to the POS terminal 70, and the POS terminal may receive the information as needed to conduct the transaction. be understood. For example, a list of DOM issuers may be stored at the POS terminal 70, while a list of INTL issuers and the billing currency associated with each INTL issuer may be stored at the POS terminal 70, e.g. may be stored remotely from the Additional information may also be included in the RAM of the POS terminal 70 .

In some embodiments, the cardholder's 10 currency is not given in the request for the token. Alternatively, the currency data may be obtained by the tokenized data processor 300 itself, for example using the PAN's BIN.

The request to provide the token includes the PAN of the transaction card 60 and information identifying the user's currency (which may be the PAN itself). Such information may be obtained by one or more of NFC module 140, smart card reader 150, card reader 160, keypad 170, or EMV circuitry 195 (one or more of which may be POS available on terminal 70). Once that information is obtained, controller 180 encrypts the PAN and sends the PAN as part of the request (e.g., (via modem 110). The key may be the shared or public key of tokenized data processor 300, which is part of a (public key, private key) symmetric key pair. Using a symmetric key pair means that once the PAN is encrypted, the POS terminal 70 does not contain any means to decrypt the PAN.

The tokenization data processor 300 returns the resulting token identifier, which can be output to the merchant's PMS. The token identifier contains (eg, is encoded within) the user's currency.

Alternatively, when a transaction (e.g. payment or refund) is about to be performed (e.g. during hotel checkout or when a restaurant bill is about to be paid), input module 190 (PMS or ECR to token ), or via one of NFC module 140, smart card reader 150, card reader 160, keypad 170, or EMV circuit 195. be able to. By comparing the user's currency (provided in the token identifier) with the POS terminal system currency (eg, stored in memory 120), POS terminal 70 determines whether DCC should be provided. can judge. If such an offer is allowed, modem 110 can be used to execute DCC transactions using the selected currency using the token identifier. If not allowed (in any of the previous cases), modem 110 can be used to perform normal transactions using the token identifier.

POS terminal 70 may also receive the latest exchange rate via modem 110, for example. The exchange rate may be stored in memory 120 . Thus, when DCC is provided, it is possible to show the transaction amount in the user's currency and/or the exchange rate offered at the time of the transaction without having to request live data.

FIG. 3 shows a block diagram of an exemplary payment service provider (PSP) as may be provided by the acquirer 30. As shown in FIG. Payment service provider 200 is an example of a claimed server. PSP 200 includes input circuitry 210 that receives requests from POS terminal 70 to perform either normal transactions or DCC transactions. In either case, the request includes the token identifier and the information necessary to execute the transaction (amount, whether the transaction is a sale or a refund, and in the case of DCC, the selected currency). including. The request is passed to controller 220 , which uses the token identifier to determine the corresponding PAN from storage circuit 230 . Here, the PSP 200 includes a set of translations between PANs and token identifiers, which can be obtained from a tokenization server, for example. In other embodiments, the PSP may send a request for the PAN, for example, to the tokenizing data processor 300 that originally generated the token. In any event, once the PAN information is collected, controller 220 then issues a request via modem 240 to conduct a transaction (either normal or DCC) for that PAN. At that stage of the process, the token identifier has been replaced with the PAN, so the process for executing transactions can proceed as normal.

FIG. 4 shows a block diagram of an exemplary tokenizer or tokenizing data processor 300 as may be provided by the acquirer 30. As shown in FIG. Tokenizer 300 is an example of a claimed data processing device. Tokenizer 300 receives the encrypted PAN and may also receive information indicating the currency of cardholder 10 via modem 310 . Tokenizer 300 can decrypt the encrypted PAN using either a shared key or a private key that is part of a (public key, private key) pair, for example, in a symmetric encryption operation. Alternatively, if transaction card 60 is physically present, the PAN can be obtained using either NFC module 320, smart card reader 330, card reader 340, keypad 350, or EMV circuitry 355. can. Using PAN, controller 360 generates a token identifier that is output by controller 360 via communication circuit 370 . Controller 360 generates the token identifier such that the token identifier includes the cardholder's 10 currency. Cardholder currency is stored on the transaction card 60 if the transaction card 60 is available locally, for example from the PAN's BIN (as previously described with respect to the POS terminal) using memory 380. or from the request to provide the token received from the POS terminal 70 . Note that in some embodiments, additional digits of the PAN (beyond just the BIN) are used to more accurately derive the cardholder currency.

FIG. 5A shows an example of token identifier 400 as generated by tokenizer or tokenized data processor 300 . In this embodiment, the token contains 16 characters, thus having the same number of characters as a typical PAN. This potentially allows the token identifier 400 to be backwards compatible with systems that allow PANs to be 16 characters long. Here, the token identifier 400 is prefixed with a single leading character 410 . For example, the letter "T" may be used. This makes it possible to distinguish the token from the actual PAN. In some other embodiments, the leading character will be a number such that whole digits are used (similar to typical conversions of primary account numbers). In any event, the leading character is followed by three digits 420 used to help identify the cardholder's 10 currency. There are multiple ways this can be achieved, such as using a textual representation of the country or currency. However, in this embodiment, a 3-digit currency code represented by ISO4217 is used. In this currency code, the number for Great Britain (the currency is British Pound) is 826. The numeric code for the United States (currency is US dollars) is 840. On the other hand, the numeric code for Australia (the currency is the Australian dollar) is 036. Note that in other embodiments, the currency type itself may be encoded using three digits. In any event, the digits are followed by an 8-digit number such as random or pseudo-random digit 430 . In some embodiments, the number may be based on the PAN, such as by performing a one-way hash of the PAN using an algorithm like MD5 or SHA-1. Using a one-way hash makes it possible to verify that the token identifier 400 is associated with the correct PAN. On the other hand, using random numbers allows the same PAN to be used multiple times. At the end of the token identifier 400, the last three digits 440 of the PAN are provided along with a final check digit 450. Including the trailing digits 440 of the PAN allows the user to identify the PAN with which the token identifier 400 is associated without knowing the PAN itself. This may be useful, for example, if the user has multiple different transaction cards 60 . A check digit 450 is provided to prevent the use of incorrectly typed or provided token identifiers. Such an algorithm for performing the test may be Luhn's algorithm. Since the token identifier encodes the user's currency into the token identifier, it is possible to determine whether DCC should be provided to the user based solely on the user's token without the PAN becoming accessible to the merchant 20. Note that it is possible to determine

FIG. 5B shows a further example of token identifier 460 as generated by tokenizer or tokenized data processor 300 . In this further example, most of the fields remain the same. However, the numeric value 430 has been shortened to 6 characters (eg, numbers). The "stored" two digits are used to encode the IID, which can be used to identify the card issuer and/or scheme (e.g., Visa or Mastercard) or operator of the payment account. can. The IID allows a further level of validation (to ensure that the token corresponds to the proper primary account number) to be performed, allowing the user to determine which primary account number was used by looking at the token. can be used to help identify Additionally, knowledge of the card issuer and/or scheme can be used to help route transaction messages when payment is finally made. This can be accomplished without the need to fully decrypt the token, thus maintaining security and allowing for more efficient programming logic within the POS terminal and acquirer system.

FIG. 6 shows an exemplary communication exchange. First, card 60 provides the PAN to POS terminal 70 . The PAN is encrypted by the POS terminal 70, which then sends a RequestToken message to the tokenizer 300 containing the encrypted PAN. Tokenizer 300 then responds with the corresponding token. Note that in this example, the PAN can be used to determine the currency of the card 60 user. This determination may be made, for example, by the tokenizer 300 performing an analysis of the PAN to determine the country of the issuer and from this country the currency in which the issuer trades (e.g. a UK-based issuer may can be traded using In another example, the PAN can directly determine the billing currency itself without first having to derive the issuer's country. The determined currency is encoded in the generated token (eg, as discussed with reference to FIGS. 5A and 5B). In another embodiment, additional information can be sent with the PAN. For example, the additional information may take the form of a currency code or an issuer country code, either of which may be inferred from information available on card 60 .

Tokens do not need to be encrypted because they are separate and do not need to be handled sensitively. Tokenizer 300 is sent to PMS 500 where the tokenizer is stored. Fees and the like may be accumulated against the cardholder 10 as desired. A TransactionRequest message may be sent from the PMS 500 to the POS terminal 70 when the entire bill is to be settled. The TransactionRequest message includes the appropriate token, amount to be traded, and transaction type (eg, refund or sale). In some embodiments, the ID of the PoS terminal 70 is also included. Transaction type can be combined with amount. For example, if the bill is raised, the transaction is a sale and therefore the amount is positive. In another example, a refund may have been provided and the amount will be negative. In any event, the POS terminal determines the cardholder's 10 currency from the token. The currency determination is made by the POS terminal 70 storing the currency of each country by examining characters 2-4 of the token identifier and determining that the currency of the listed country is different than the currency of the POS terminal 70. can break If these currencies do not differ, the transaction proceeds as normal by requesting the transaction for the amount provided in the token identifier. This is sent to the payment service provider 200 who performs the transaction (translates the token identifier in the process). If the currencies are different, a choice is provided as to whether to charge in the cardholder's 10 currency or the POS terminal's 70 currency. An exchange rate or one or more of the transaction amount to be converted to the cardholder's 10 currency may be provided to guide the user's decision. These may be provided from a stored set of exchange rates that are frequently updated by the POS terminal 70 or by requesting live exchange rates by the payment service provider 200 . If the transaction is to proceed using the currency of the POS terminal 70, the process proceeds as previously described. Otherwise, a DCCPaymentRequest message is generated containing the token identifier, amount and currency in which the transaction will be made. The message is sent to payment service provider 200 . As noted above, the payment service provider 200 obtains the PAN from the token identifier (either via local storage or by making a request to the tokenizer 300, for example). PSP 200 then executes the transaction.

Note that there are various ways in which the POS terminal 70 can conduct a DCC transaction. In some embodiments, for example, the POS terminal 70 may only indicate that DCC should be used, while the PSP 200 stores or determines the cardholder 10 currency.

FIG. 7 shows another exemplary communication exchange when a claim is about to be settled. The PMS 500 sends a request to a payment proxy server (PPS) to effect the payment. The PPS can be used to mediate the routing of messages (and any necessary protocol conversion between devices such as the PMS 500, payment terminals 70, payment DCC routing servers and payment gateway servers). The PPS forwards the request to payment terminal 70 . From there, payment terminal 70 issues a DCC rate request message, which is forwarded via the PPS to the PSP, which forwards the request to currency conversion service 600 . Currency conversion services may be provided by acquirer 30 . The currency conversion service responds with a DCC rate response, which is provided to PSP 200, and PSP 200 provides the DCC rate response to payment terminal 70 via the PPS. The DCC rate response provides an indication of the currency conversion rate between the payment terminal 70 currency and the user's currency. In some other embodiments, the transaction amount can be sent as part of the DCC rate request and the DCC rate response returns the converted transaction amount. Here, the payment terminal 70 can provide DCC if the currency of the cardholder 10 and the currency of the payment terminal 70 are different. A payment request is then issued to the PPS based on the outcome of this selection. At the same time, a receipt can be printed if this option is enabled and/or required. At the end of the day, the payments are consolidated by the PPS and issued to PSP 200 , which issues the payments to Acquirer 30 . The acquirer responds with a payment response, which is provided back to the PPS via PSP 200 . The settlement response is then provided to PMS 500 . At the end of the day, a compiled transaction log file is also provided to currency converter 600 .

FIG. 8 illustrates a process 700 performed by POS terminal 70 when conducting a payment in some embodiments. The process begins at step 710, where the terminal currency indicator is stored. Token identifier 400 is then received at step 720 . At step 730 , the currency of cardholder 10 is determined from token identifier 400 . At step 740, it is determined whether the terminal currency and the user currency are the same. If so, at step 750 the transaction is performed using the terminal system currency. If not, at step 760 a currency selection is provided. If the user currency is not selected, then again at step 750 the transaction is conducted using the terminal system currency. If a user currency is selected, at step 780 the transaction is performed using the user currency.

FIG. 9 shows a process 800 performed by tokenizer 300 to generate token identifier 400 . First, at step 810, user account information (eg, PAN) is received. At step 820, the user payment currency is received, although in some other embodiments this may be determined by the tokenizer 300, eg, by the PAN. At step 830, a token identifier 400 is generated. The process used to generate tokens is illustrated, for example, in Figures 5A and 5B. Finally, at step 840 the token identifier is provided back to merchant 20 at, for example, POS terminal 70 .

FIG. 10 shows a process 900 performed by PSP 200 during settlement. At step 910, information associated with a user account is received. Such information may take the form of token identifier 400 or part of token identifier 400, for example. User currency is then received at step 920 . In some embodiments, the user currency can be determined by the PSP 200, for example, if the PSP 200 stores the user currency or can query the user currency information from another device. At step 930, a search is performed to obtain the user account. Searching may include, for example, using a lookup table to obtain user account information from a particular token identifier 400 . Finally, at step 940, a transaction is performed against the user account using the user currency. This step may include, for example, exchanging further messages to the acquirer 30 or card scheme administrator 50, as examples.

Thus, it has been shown that it is possible to provide users with the opportunity to enforce DCC using token identifiers rather than specific user account information. Therefore, it is possible to maintain convenience for the user while also maintaining the security of the user's financial information.

In this application, the term "configured to" is used to mean that an element of the device has a configuration that enables it to perform the defined action. In this context, "configuration" means the arrangement or manner of interconnection of hardware or software. For example, an apparatus may have dedicated hardware that provides defined operations, or a processor or other processing device may be programmed to perform that function. "Constituted to" does not imply that the elements of the device must be modified in any way to provide the defined behavior.

While illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, the invention is not limited to those exact embodiments, and the claims that follow. It should be understood that various changes, additions and modifications can be made in those embodiments by those skilled in the art without departing from the scope and spirit of the invention as defined by the scope of the present invention. For example, various combinations of the features of the dependent claims and the features of the independent claims can be made without departing from the scope of the invention.
[Item of Invention]
[Item 1]
A transaction terminal system,
a storage circuit for storing information indicating a terminal system currency of the transaction terminal system;
input circuitry for receiving a token identifier, said token identifier comprising:
information indicating the user currency; and
Information Associated with User Payment Account Information
an input circuit comprising
comparing said terminal system currency and said user currency, and if a difference exists, causing a currency selection offer to be provided and, in response to selecting said user currency, transacting with said user currency with respect to said user payment account; processing circuitry for sending messages to cause the
with
A transaction terminal system, wherein said message includes said information associated with said user payment account information.
[Item 2]
The transaction terminal system of item 1, wherein the message includes the token identifier.
[Item 3]
Transaction terminal system according to item 1 or 2, wherein the token identifier comprises a subset of the user payment account information.
[Item 4]
the user payment account information is a primary account number;
4. The transaction terminal system of item 3, wherein the subset of the user payment account information is the last x digits of the user's primary account number.
[Item 5]
5. The trading terminal system of any one of items 1-4, wherein the token identifier comprises a random or pseudo-random number.
[Item 6]
6. The transaction terminal system of any one of items 1-5, wherein the token identifier comprises a designator of an operator of the user payment account.
[Item 7]
7. The transaction terminal system of any one of items 1-6, wherein the token identifier comprises the result of applying a one-way hash to the user payment account information.
[Item 8]
the token identifier comprises at least one digit;
The transaction terminal system of any one of items 1-7, wherein said token identifier comprises a checksum value for said at least one digit.
[Item 9]
Transaction terminal system according to item 8, wherein the checksum value is generated using the Luhn algorithm.
[Item 10]
The transaction terminal system of any one of items 1-9, wherein the information indicative of a user currency comprises a billing currency code identifier, a currency code identifier, or a country code identifier.
[Item 11]
11. The transaction terminal system of any one of items 1-10, wherein the token identifier comprises one or more leading non-numeric characters.
[Item 12]
12. The transaction terminal system of any one of items 1-11, wherein the token identifier consists of 16 alphanumeric characters.
[Item 13]
13. The transaction terminal system of any one of items 1-12, wherein the input circuitry includes a keypad for entering the token identifier.
[Item 14]
A transaction terminal system according to any one of the preceding items, wherein said input circuitry comprises an interface for connecting to a processing device capable of receiving said token identifier.
[Item 15]
Transaction terminal system according to any one of the preceding items, wherein the amount of said transaction is determined as a result of entering information about the goods or services to be purchased.
[Item 16]
The processing circuit is
a sales mode of operation in which the transaction is for a sale; and
a refund mode of operation in which said transaction is for a refund
16. A transaction terminal system according to any one of items 1-15, configured to operate in at least one of:
[Item 17]
In response to determining that the terminal system currency and the user currency are different, the processing circuitry:
a current currency conversion value from said transaction currency to said user currency; and
Transaction amount converted using said current currency conversion value
at least one of
17. A transaction terminal system according to any one of the preceding items, arranged to be downloaded from a remote server to said transaction terminal system.
[Item 18]
The currency selection presentation is
the current currency conversion value; and
Amount of said transaction converted to said user currency using said current currency conversion value
Transaction terminal system according to item 17, comprising at least one of:
[Item 19]
the input circuitry is configured to receive the information associated with the user payment account information and data related to the user currency;
The processing circuitry, in response to receiving the information associated with the user payment account information and the data related to the user currency, encrypting at least the information associated with the user payment account information. generating encrypted information by and transmitting said encrypted information and said data relating to said user currency to a server;
said transaction terminal system comprising a receiving circuit for receiving said token identifier in response to said transmission of said encrypted information;
Transaction terminal system according to any one of the preceding items, wherein said transaction terminal system comprises an output circuit for outputting said token identifier.
[Item 20]
a method,
storing information indicative of the terminal system currency of the transaction terminal system;
receiving a token identifier, said token identifier comprising:
information indicating the user currency; and
Information Associated with User Payment Account Information
a receiving step comprising
comparing the terminal system currency and the user currency, causing a currency selection suggestion to be displayed if a difference exists;
responsive to selection of the user currency, sending a message to cause transactions to be conducted using the user currency with respect to the user payment account;
including
The method, wherein said message includes said information associated with said user payment account information.
[Item 21]
input circuitry for receiving user payment account information and information indicative of a user currency;
processing circuitry for generating a token identifier using the payment account information and the information indicative of the user currency, wherein the token identifier includes the information indicative of the user currency;
an output circuit for providing the token identifier;
A data processing device comprising:
[Item 22]
22. A data processing apparatus according to item 21, wherein said information indicative of said user currency is one of said user payment account information, currency code or issuer country code.
[Item 23]
22. A data processing apparatus according to item 21, wherein said input circuitry comprises magnetic stripe reading circuitry.
[Item 24]
24. A data processing apparatus according to any one of items 19 to 23, wherein said input circuit comprises an EMV circuit.
[Item 25]
25. A data processing apparatus according to any one of items 19 to 24, wherein said input circuitry comprises NFC communication circuitry.
[Item 26]
26. A data processing apparatus according to any one of items 19 to 25, wherein said input circuitry comprises a keypad.
[Item 27]
17. A data processing apparatus according to any one of items 19 to 16, wherein said input circuitry comprises communication circuitry for communicating with one or more further data processing devices via a network.
[Item 28]
28. A data processing apparatus according to any one of items 19 to 27, wherein said output circuitry comprises communication circuitry for communicating with one or more further data processing devices via a network.
[Item 29]
29. Data processing apparatus according to any one of items 19 to 28, wherein said output circuit is arranged to provide said token identifier to a sender of said user payment account information.
[Item 30]
30. Data processing apparatus according to any one of items 19 to 29, wherein said user payment account information is provided in encrypted form.
[Item 31]
a method,
receiving user payment account information and information indicative of a user currency;
generating a token identifier using the payment account information and the information indicative of the user currency, wherein the token identifier includes the information indicative of the user currency;
providing said token identifier;
A method, including
[Item 32]
a server,
An input circuit configured to receive a message to cause a transaction to be conducted in a user currency with respect to a user payment account, said message including information associated with said user payment account information. , an input circuit, and
a storage circuit containing a plurality of mappings from information to user payment account information;
a processing circuit configured, in response to receiving the message, to retrieve the user payment account information from the storage circuit and cause the transaction to be conducted;
A server.
[Item 33]
33. The server of item 32, wherein the message includes user currency.
[Item 34]
34. The server of items 32 or 33, wherein the message includes an indication that the user currency is a currency other than the currency associated with the sender of the message.
[Item 35]
if said message
Transaction amount and current currency conversion value, or
Amount of said transaction converted to said user currency using said current currency conversion value
The server according to any one of items 32-34, comprising:
[Item 36]
a method,
receiving a message to cause a transaction to be conducted in a user currency with respect to a user payment account, said message including information associated with said user payment account information;
storing in a storage circuit a plurality of mappings from information to user payment account information;
responsive to receiving the message, retrieving the user payment account information from the storage circuit so that the transaction is performed;
A method, including
[Item 37]
a system,
The transaction terminal system according to any one of items 1 to 19;
a data processing device according to any one of items 21 to 30;
A server according to any one of items 32 to 35 and
A system comprising:

Claims (21)

A transaction terminal system,
a storage circuit for storing information indicating a terminal system currency of the transaction terminal system;
input circuitry for receiving a token identifier, said token identifier comprising:
an input circuit including information indicative of the user currency and information to which the user's primary account number is unidirectionally mapped;
comparing said terminal system currency and said user currency, and if a difference exists, causing a currency selection offer to be provided ; processing circuitry for transmitting a message to a payment service provider to cause a transaction to be conducted using the user currency on the user's primary account number without being supplied;
A transaction terminal system, wherein said message includes said information to which said user's primary account number is mapped in one direction. the token identifier is
a subset of said user's primary account number;
the last x digits of the user's primary account number;
random or pseudo-random numbers,
an operator indicator of said user's payment account;
As a result of applying a one-way hash to said user's primary account number,
at least one digit and a checksum value for said at least one digit;
2. The transaction terminal system of claim 1, comprising any combination of: one or more leading non-numeric characters; and 16 alphanumeric characters. 3. The transaction terminal system of claim 1 or 2, wherein the information indicative of user currency comprises a billing currency code identifier, currency code identifier, or country code identifier. the input circuit,
A transaction as claimed in any preceding claim, comprising at least one of a keypad for entering the token identifier and an interface for connecting to a processing device capable of receiving the token identifier. terminal system. Transaction terminal system according to any one of claims 1 to 4, wherein the transaction amount is determined as a result of entering information about the goods or services to be purchased. The processing circuit is
6. A system according to any one of claims 1 to 5, configured to operate in at least one of a sales mode of operation in which said transaction relates to a sale, and a refund mode of operation in which said transaction relates to a refund. The trading terminal system described. In response to determining that the terminal system currency and the user currency are different, the processing circuitry:
at least one of a current currency conversion value from said terminal system currency to said user currency and a transaction amount converted using said current currency conversion value,
A transaction terminal system according to any one of the preceding claims, arranged to be downloaded from a remote server to said transaction terminal system. The currency selection presentation is
8. The transaction terminal system of claim 7, comprising at least one of: the current currency conversion value; and an amount of the transaction converted to the user currency using the current currency conversion value. the input circuitry is configured to receive the user's primary account number and data related to the user's currency;
The processing circuitry, in response to receiving the user's primary account number and the data relating to the user currency , generates encrypted information by encrypting the user's primary account number. , configured to transmit the encrypted information and the data related to the user currency to a server;
said transaction terminal system comprising a receiving circuit for receiving said token identifier in response to said transmission of said encrypted information;
The transaction terminal system according to any one of claims 1 to 8, wherein said transaction terminal system comprises an output circuit for outputting said token identifier. A method implemented by a trading terminal system, comprising:
storing information indicative of the terminal system currency of the transaction terminal system;
receiving a token identifier, said token identifier comprising:
receiving including information indicative of the user currency and information to which the user's primary account number is unidirectionally mapped;
comparing the terminal system currency and the user currency, causing a currency selection suggestion to be displayed if a difference exists;
In response to selection of said user currency, a payment service sends a message to cause transactions to be conducted using said user currency with respect to said user's primary account number without said user's primary account number being supplied. sending to a provider ;
The method wherein said message includes said information to which said user's primary account number is mapped in one direction. input circuitry for receiving information indicative of the user's primary account number and the user's currency;
processing circuitry for generating a token identifier using the user's primary account number and the information indicative of the user currency, wherein the token identifier is indicative of the user currency; processing circuitry containing information to which primary account numbers are unidirectionally mapped;
output circuitry for providing said token identifier, said token identifier for said user's primary account number in said user's currency at said trading terminal without said user's primary account number being supplied to said trading terminal; and an output circuit configured to allow a transaction to take place. 12. The data processing apparatus of claim 11, wherein said information indicative of said user currency is one of said user 's primary account number , currency code, or issuer country code. the input circuit is a magnetic stripe reading circuit;
EMV circuit,
12. A data processing device according to claim 11, comprising any combination of NFC communication circuitry and a keypad. Data according to any one of claims 11 to 13, wherein at least one of said input circuitry and said output circuitry comprises communication circuitry for communicating with one or more further data processing devices over a network. processing equipment. 15. A data processing apparatus as claimed in any one of claims 11 to 14, wherein the output circuit is arranged to provide the token identifier to the sender of the user's primary account number. A data processing apparatus as claimed in any one of claims 11 to 15, wherein the user's primary account number is provided in encrypted form. A method implemented by a data processing device, comprising:
receiving information indicative of the user's primary account number and the user's currency;
generating a token identifier using the user's primary account number and the information indicative of the user currency, wherein the token identifier is indicative of the user currency and the user's primary account number; includes information to which the is unidirectionally mapped;
providing said token identifier, said token identifier enabling transactions for said user's primary account number in said user's currency at said transaction terminal without said user's primary account number being provided to the transaction terminal; A method configured to enable it to be performed, comprising the steps of: a server,
An input circuit configured to receive a message to cause a transaction to be conducted in a user currency with respect to a user payment account, the message being a user primary account number in one direction. an input circuit including a token identifier including information to be mapped and information indicative of a user currency;
a storage circuit containing a plurality of mappings from a primary account number unidirectionally mapped information to the user's primary account number;
configured to retrieve the user's primary account number from the storage circuit in response to receiving the message, such that the transaction is conducted without retrieving the user's primary account number from a sender; A server, comprising: a processing circuit configured to: if said message is user currency,
an indication that the user currency is a currency other than the currency associated with the sender of the message;
transaction amount and current currency conversion value,
19. The server of claim 18, comprising at least one of the transaction amounts converted to the user currency using the current currency conversion value. A method implemented by a server, comprising:
receiving a message to cause a transaction to be conducted in a user currency with respect to a user payment account, said message including information in which the user 's primary account number is unidirectionally mapped; receiving a token identifier that includes information indicative of currency;
storing in a storage circuit a plurality of mappings from information with which the user's primary account number is unidirectionally associated to the user's primary account number;
and in response to receiving said message, retrieving said user's primary account number from said storage circuit to cause said transaction to be conducted. a system,
The transaction terminal system according to any one of claims 1 to 9,
A data processing device according to any one of claims 11 to 16;
A system comprising a server according to any one of claims 18-19.

Images