RU2792051C2 - Network token system - Google Patents

Abstract

FIELD: digital payments.

SUBSTANCE: methods, devices, computer-readable media, and systems for providing, along with a token, a token assurance level and the data used to generate the token assurance level. During token issuance, one or more Identification and Verification (ID&V) methods may be performed to ensure that the token replaces the Primary Account Number (PAN) that is legitimately used by the token requestor. The token guarantee level can be assigned to a given token depending on the type of ID&V being executed and the entity executing the ID&V. Different ID&Vs can lead to different token guarantee levels. An issuer may wish to know the guarantee level and data used to generate the guarantee level associated with a token before authorizing a payment transaction that uses the token.

EFFECT: increased security when making payments, thereby reducing the risk of fraud.

18 cl, 10 dwg, 13 tbl

Description

Cross-references to related applications

[0001] This application claims priority under USC 35 119(e) U.S. Provisional Application No. 61/890162, filed October 11, 2013, entitled "Network Token System" and U.S. Provisional Application No. 61/ 906377, filed November 19, 2013 and entitled "Network Token Standards", the disclosures of which are incorporated by reference herein in their entirety for all purposes.

State of the art

[0002] The payments industry is evolving to support payment form factors that provide increased protection against forgery, account abuse, and other forms of fraud. While smart cards can provide significant protection for cardholder present transactions, a similar need exists for additional protection for "cardholder away" and hybrid transaction environments to minimize unauthorized use of account holder data and prevent cross-channel fraud. . Tokenization systems show promise in meeting this need.

[0003] In a traditional electronic payment transaction, the customer's Primary Account Number (PAN) information is available to various entities involved during the life cycle of the transaction. The PAN is transmitted from the merchant terminal to the acquirer system, payment processing network, payment gateways, etc.

[0004] Because the PAN may be available at various points in the transaction life cycle, payment "tokens" have been developed to conduct payment transactions. Payment tokens serve as an additional layer of security to the PAN and actually become a PAN proxy/surrogate. Thus, the payment token can be used instead of PAN when initiating a payment or when sending transactions. Using payment tokens instead of PAN can reduce the risk of fraud since real PAN is not available.

[0004] While traditional efforts to use payment tokens have been helpful, a number of additional issues need to be addressed. For example, since the real PAN is not obvious from the corresponding token, it is difficult to identify the source of the token or the issuer of the token. On the one hand, the token is designed to hide information. On the other hand, it would be useful to identify from the payment token the source or issuer of the token, the level of trust that the user attempting to use the token is in fact the real cardholder, and the data used to determine the level of trust. Currently, there are no methods for identifying this information.

[0005] In addition, tokens have traditionally been limited to a particular payment processing network or system and have not been interoperable between payment networks. Accordingly, the acceptance and integration of tokens with various payment systems has been limited.

[0006] Embodiments of the present invention solve these and other problems, individually and collectively.

The essence of the invention

[0007] Embodiments of the present invention are directed to providing, along with the token, the guarantee level of the token and the data used to generate the guarantee level of the token. During token issuance, steps may be taken to ensure that the token replaces the PAN that is legitimately used by the token requester. This process is known as identification and verification (ID&V), and it can be performed every time a token is requested. A token guarantee level can be assigned to a given token depending on the type of ID&V being executed and the entity executing the ID&V. Different ID&Vs can lead to different token guarantee levels. An issuer may wish to know the guarantee level and the data used in generating the guarantee level associated with a token before authorizing a payment transaction that uses the token. The guarantee level that is assigned to a given token may change over time and may be recalibrated based on factors that affect its trust levels, such as any connection to fraudulent transactions associated with fraudulent chargebacks, etc.

[0008] In accordance with an exemplary embodiment, a method is provided. The method includes receiving, by means of a computer, an authorization request message from a requestor. The authorization request message contains a payment token representing the primary account number. The primary account number may be assigned by the issuer. The authorization request message is intended to conduct a payment transaction using the primary account number. The method also includes receiving, by computer, a token guarantee level associated with the token along with data used to generate the token guarantee level. The token assurance level may represent the level of trust in the association between the payment token and the primary account number represented by the payment token. The token guarantee level can be based on the identification and verification method used to generate the payment token. In some embodiments, the assurance level of the token is based on the entity performing the verification method and identification. In addition, the method includes modifying, by computer, the authorization request message to include the token guarantee level and the data used to generate the token guarantee level. The method further includes transmitting, by computer, the modified authorization request message to the issuer for approval.

[0009] According to various embodiments, the method further includes, prior to receiving an authorization request message, receiving, by computer, a token generation message to generate a payment token to represent a primary account number. The token generation message may include the requested token guarantee level associated with the payment token. The method may further include computer generating a payment token and a token guarantee level associated with the payment token and storing the payment token, the token guarantee level and a primary account number associated with the payment token in a repository.

[0010] In some embodiments, the method may also include interacting with a repository storing a one-to-one correspondence between one or more primary account numbers and one or more payment tokens generated for one or more primary account numbers.

[0011] Another embodiment describes devices, systems, and computer-readable media capable of performing the method described above.

[0012] Another exemplary embodiment describes a method including generating, by computer, a payment token and a token guarantee level associated with the payment token, a payment token representing a primary account number assigned by the issuer. The method also includes sending, using the computer, a payment token to the requestor and receiving, using the computer, an authorization request message from the requestor. The authorization request message may contain a payment token. The authorization request message is intended to conduct a payment transaction using the primary account number. The method may further include modifying, by computer, the authorization request message to include the token guarantee level and the data used to generate the token guarantee level, and transmitting, using the computer, the modified authorization request message to the issuer for approval.

[0013] These and other embodiments are described in more detail below.

Brief description of the drawings

[0014] FIG. 1 shows a system and flowchart providing an overview of the various interactions of entities in a tokenization ecosystem, in accordance with an exemplary embodiment of the present invention.

[0015] FIG. 2 shows a system and flowchart providing an overview of the various interactions of entities in a tokenization ecosystem where a payment network serves as a token service provider, in accordance with an exemplary embodiment of the present invention.

[0016] FIG. 3 shows a system and flowchart for a mobile device authorization flow in a transaction at a merchant terminal in accordance with an exemplary embodiment of the present invention.

[0017] FIG. 4 shows a system and flowchart for an authorization flow for an e-commerce transaction with a mobile/digital wallet in accordance with an exemplary embodiment of the present invention.

[0018] FIG. 5 shows a system and flowchart for an authorization flow for an e-commerce transaction with a card entry in accordance with an exemplary embodiment of the present invention.

[0019] FIG. 6 shows a system and flowchart for an authorization to scan in a transaction at a merchant terminal in accordance with an exemplary embodiment of the present invention.

[0020] FIG. 7 shows a system and flowchart for a capture and clearing process for a token transaction in accordance with an exemplary embodiment of the present invention.

[0021] FIG. 8 shows a system and flowchart for a chargeback request process for a token transaction in accordance with an exemplary embodiment of the present invention.

[0022] FIG. 9 shows a diagram providing an overview of the various roles involved in performing a token service, in accordance with an exemplary embodiment of the present invention.

[0023] FIG. 10 shows an exemplary computer system in accordance with embodiments of the present invention.

Detailed description

[0024] Embodiments of the invention describe methods, devices, computer-readable media, and systems for implementing and providing a network token system, including token service interoperability formats and functionality that allows generation, verification, validation, and use of tokens between payment processing networks.

[0025] Tokens include surrogate values that replace primary account numbers (PANs) in the payments ecosystem. Payment tokens can be used to initiate payment transactions.

[0026] In order for payment tokens to provide improved protection against malicious use, the token may be restricted to use in a specific domain, such as a specific merchant or channel. These basic usage controls are the benefit of tokens, and the embodiments presented describe methods for implementing them.

[0027] Additionally, steps may be taken during token issuance to ensure that the token replaces the PAN that was legitimately used by the token requestor. This process is known as identification and verification (ID&V), and it can be performed every time a token is requested. A token guarantee level can be assigned to a given token depending on the type of ID&V that is being executed. Different ID&Vs can lead to different token guarantee levels. For example, no or minimal ID&V performed by an untrusted entity may result in a low token assurance level, while a verbose ID&V performed by a trusted entity is likely to result in a high token assurance level. Accordingly, the guarantee level associated with a token depends on the ID&V method performed when the token was generated and the entity that performed the ID&V method. An issuer may wish to know the guarantee level and the data used in generating the guarantee level associated with a token before authorizing a payment transaction that uses the token.

[0028] There are benefits to all stakeholders in the payments ecosystem that can help drive token adoption. First, issuers and cardholders can benefit from new and more secure payment methods, improved confirmation levels, and a reduced risk of subsequent fraud in the event of a data breach. In addition, acquirers and merchants may be less threatened by online attacks and data breaches, as token databases may be less attractive targets given their domain-specific limitation. Acquirers and merchants can also benefit from the higher levels of trust in high value transactions that tokens have to offer. Additionally, payment processing networks can implement an open format that ensures interoperability and help reduce data protection processes for the network and its members. In addition, issuers can determine whether a transaction request involving a token should be approved based on the guarantee level of the token and the data used in generating the guarantee level of the token associated with the token.

[0029] Embodiments of the present invention may describe a tokenization ecosystem (tokenization environment), define object roles necessary to support tokenization, identify impacts of embodiments of the invention, specify data fields associated with token requests, token issuance and grant, transaction processing, and identify required application programming interfaces (APIs). Embodiments of the present invention are intended to maintain interoperability in the payments industry. Further, embodiments are intended to provide a token guarantee level associated with the token along with the data used to generate the token guarantee level in an authorization request message sent to, for example, an issuer.

[0030] Embodiments of the present invention are also intended to provide a detailed description of the tokenization ecosystem, definitions of terminology, responsibilities, and controls related to entities within the ecosystem. Exemplary use cases, corresponding transaction flows, and specific fields in these transaction flows in traditional payment functions such as authorization, capture, clearing, and exception handling are discussed below.

[0031] Before discussing specific embodiments and examples, the following are some descriptions of the terms used herein.

[0032] The "token" may include an identifier for a payment account that is a replacement for an account identifier such as a primary account number (PAN). For example, the token may include a series of numbers and/or alphanumeric characters that may be used in place of the original account identifier. For example, the token "4900 0000 0000 0001" could be used instead of the PAN "4147 0900 0000 1234". In some embodiments, the token may be "preserving format" and may be in a numeric format that matches account identifiers used in existing payment processing networks (eg, the ISO 8583 financial transaction message format). In some embodiments, a token may be used in place of a PAN to initiate, authorize, conduct, or authorize a payment transaction, or present initial credentials in other systems where initial credentials have typically been provided. In some embodiments, a token value may be generated such that recovery of the original PAN or other account identifier from the token value cannot be computed. In addition, in some embodiments, the format of the token may be configured to allow the entity receiving the token to identify it as a token and to recognize the entity that issued the token.

[0033] A "Bank Identification Number (BIN)" may be assigned by the payment network to the issuer of the payment account. BINs may conform to industry account and issuer identification specifications (eg, ISO 7812), so that a payment network that assigns a BIN can be identified based on the BIN and associated account ranges.

[0034] In some embodiments, the token format may allow entities in the payment system to identify the issuer associated with the token. For example, the token format may include a token issuer identifier that allows the entity to identify the issuer. For example, the token issuer ID may be associated with the underlying PAN's issuer BIN to support an existing payment flow. The token issuer ID can be a number different from the issuer's BIN, and it can be fixed. For example, if the issuer BIN of an issuer is 412345, the token issuer ID could be a token BIN of 428325, and this number could be fixed for all tokens issued by or for that issuer. In some embodiments, a token issuer identifier range (e.g., issuer token BIN range) may have the same attributes as the corresponding issuer card range and may be included in an issuer identifier routing table (e.g., BIN routing table). The issuer identifier routing table may be provided to the relevant entities in the payment system (eg, merchants and acquirers).

[0035] A "token BIN" may refer to a specific BIN that has been assigned only for the purpose of issuing tokens and that may be marked accordingly in BIN tables. Token BINs cannot be dual-purpose and cannot be used to issue both Primary Account Numbers (PANs) and tokens.

[0036] A “token issuer ID range (Issuer BIN range)” may refer to a unique identifier (e.g., 6-12 digits long) arising from a plurality of pre-allocated token issuer IDs (e.g., a 6-digit token BIN). For example, in some embodiments, one or more token BIN ranges may be allocated to each issuer BIN range that is associated with the issuer. In some embodiments, token BIN ranges may be used to generate a payment token and may not be used to generate a non-payment token. In some embodiments, the token may convey basic account number validation rules, including, for example, LUHN validation or checksum validation, which may be set by various entities within the payment system. In some embodiments, the payment identifier of the issuer of the token can be mapped to a real issuer identifier (eg, BIN) for the issuer. For example, the token issuer's payment identifier may include a six-digit numeric value that may be associated with the issuer. For example, any token that includes the payment identifier of the token issuer may be associated with a particular issuer. Thus, an issuer can be identified using the appropriate range of the issuer ID associated with the token issuer ID. For example, the payment identifier "540000" of the token issuer corresponding to the payment token "5400 0000 0000 0001" can be mapped to the issuer identifier "553141" corresponding to the payment account identifier "553141 0900 0000 1234". In some embodiments, the payment identifier of the issuer of the token is fixed for the issuer. For example, a token issuer payment ID (e.g., "540000") may correspond to the first issuer, and another token issuer payment identifier (e.g., "550000") can correspond to a second issuer, and the first and second token issuer payment identifiers cannot be changed or modified. without informing all entities within the network token processing system. In some embodiments, the payment range of the token issuer identifier may correspond to the issuer identifier. For example, payment tokens including token issuer payment identifiers "490000" through "490002" may correspond to the first issuer (e.g., mapped issuer identifier "414709"), and payment tokens including token issuer payment identifiers "520000 "-520002" may correspond to a second issuer (for example, mapped to the real issuer ID "517548"). Token BIN ranges and assignment of tokens from those BIN ranges can be made available to transaction approvers for routing decisions.

[0037] A “token service system” is a system that provides for the request, generation and issuance of tokens, as well as maintaining the established correspondence of tokens to primary account numbers (PANs) in a repository (for example, a token store). The token service system can set the token assurance level for a given token to indicate the level of trust in the token's binding to the PAN. The token service system may support the processing of payment transaction tokens represented using tokens by detokenizing the token to obtain the actual PAN. In various embodiments, the token service system may include a token requester and a token service provider that interacts with the token requestor.

[0038] A "token service provider" may refer to an entity including one or more server computers in a token service system that generates, processes, and maintains tokens. The token service provider may include or communicate with a token store where generated tokens are stored. In particular, the token store may maintain a one-to-one correspondence between the token and the primary account number (PAN) represented by the token. The token service provider may be able to discount licensed BINs as token BINs in order to issue tokens for PANs that can be presented to the token service provider. Various entities in the tokenization ecosystem can take on the roles of a token service provider. For example, payment networks and issuers or their agents can become a token service provider by implementing token services in accordance with embodiments of the present invention. The token service provider may provide reports or output to reporting tools regarding approved, pending, or denied token requests, including any assigned token requestor IDs. The token service provider may provide output related to token-based transactions, reporting tools and applications and provide the token and/or PAN, as the case may be, in the report.

[0039] A "token store" may refer to a repository that maintains established token-PAN mappings. According to various embodiments, the token store may also support other attributes of the token requester, which may be determined during registration, and which may be used by the token service provider to enforce domain restrictions or other controls during transaction processing. A token store may be part of a token service system. In some embodiments, the token store may be provided as part of the token service provider. Alternatively, the token store may be a remote repository accessible to the token service provider. Token vaults, due to the sensitive nature of the correspondences of the data stored and managed within them, can be secured with strong underlying physical and logical security.

[0040] An "Identification and Verification Method (ID&V)" may be used to ensure that a payment token replaces a PAN that is legitimately used by a token requester. Examples of ID&V methods may include, but are not limited to, an account verification message, a risk score based on a Primary Account Number (PAN) assessment, and the use of a one-time password by the issuer or its agent to verify the account holder. Exemplary ID&V methods may be performed using information such as a user's signature, password, offline or online personal identification number (PIN), offline or online encrypted PIN, offline PIN and signature combination, offline encrypted PIN and signature combination, user biometrics (e.g., voice recognition, fingerprint matching, etc.), pattern, glyph, knowledge-based challenge-response, hardware tokens (multiple solutions), one-time passwords (OTP) with limited use, software tokens, dual-channel authentication processes (e.g., via telephone), etc. Using ID&V, a level of trust can be established regarding the binding of a token to a PAN.

[0041] A "token guarantee level" may be an indicator or value that allows the token service provider to indicate the level of trust in the token's binding to the PAN. The token assurance level may be determined by the token service provider based on the type of identification and verification (ID&V) performed and the entity that performed the ID&V. The token guarantee level can be set when issuing the token. The guarantee level of the token can be updated if an additional ID&V is performed.

[0042] A "Requested Token Guarantee Level" may refer to a token guarantee level requested from a token service provider by a token requester. The requested token assurance level may be included in a field of the token request message sent by the requester to the token service provider to generate/grant the token.

[0043] An "Assigned Token Guarantee Level" may refer to the actual (i.e., generated) value assigned by a token service provider to a token as a result of an identification and verification (ID&V) process performed by an entity in the tokenization ecosystem. The assigned token guarantee level may be provided back to the token requester in response to the token request message. The assigned token guarantee level may differ from the requested token guarantee level contained in the token request message.

[0044] "Token attributes" may include any feature or information about the token. For example, token attributes may include information that may define how the token may be used, delivered, issued, or otherwise manipulated in a transaction system. For example, attributes of a token may include the type of token, frequency of use, expiration date and/or expiration time of the token, number of associated tokens, transaction lifecycle expiration date, and any additional information that may apply to any entity in the ecosystem. tokenization. For example, attributes of a token may include a wallet ID associated with the token, an optional account alias or other user account identifier (e.g., email address, username, etc.), device ID, invoice number, etc. . In some embodiments, a token requester may provide token attributes during a token generation request. In some embodiments, a network token system, a payment network associated with a network token system, an issuer, or any other entity associated with a token, may define and/or provide token attributes associated with a particular token.

[0045] Token attributes can identify a token type indicating how the token can be used. The payment token may include a high value token that may be used in place of a real account identifier (eg, PAN) to generate initial and/or subsequent transactions for a consumer account and/or card. The other token type can be the "static" or "dynamic" token type for static and dynamic tokens, respectively.

[0046] "Token Presentation Mode" may indicate the manner in which the token is presented for a transaction. Some non-limiting examples of a token presenting mode may include machine-readable codes (e.g., quick response code (QRC), barcode, etc.), mobile contactless modes (e.g., near field communication (NFC)), remote e-commerce modes, e-commerce proximity modes and any other suitable modes in which the token can be presented. Tokens can be secured using any number of different methods. For example, in one implementation, the token may be embedded in a machine-readable code that may be generated by the wallet provider, mobile application, or other application on the mobile device and displayed on the display of the mobile device. The machine-readable code can be scanned at the POS, whereby the token is transferred to the merchant. The mobile contactless mode may include the transfer of a token via NFC in a contactless message. The remote e-commerce mode may include the presentation of a token by a consumer or wallet provider through an online transaction or as an e-commerce transaction using a merchant application or other mobile application. The e-commerce proximity mode may include the presentation of a token by a consumer from a wallet application on a mobile device at the location of the merchant.

[0047] "Tokenization" is a process in which data is replaced with replacement data. For example, a billing account identifier (eg, a primary account number (PAN)) may be tokenized by replacing the primary account identifier with a replacement number (eg, token) that may be associated with the billing account identifier. In addition, tokenization can be applied to any other information that can be replaced by a replacement value (i.e., a token). Tokenization can be used to increase the efficiency of a transaction, improve the security of a transaction, increase the transparency of a service, or provide a way for third-party implementation of capabilities.

[0048] "Token exchange" or "detokenization" is the process of recovering data that was substituted during tokenization. For example, the token exchange may include replacing the payment token with the corresponding primary account number (PAN) that was associated with the payment token at the time of PAN tokenization. Thus, detokenization may refer to the process of exchanging a token for a corresponding PAN value based on a stored token-PAN mapping, for example, in a token store. The ability to obtain a PAN in exchange for a corresponding token may be limited to specifically authorized entities, people, applications, or systems. In addition, detokenization or token exchange can be applied to any other information. In some embodiments, the token exchange may be achieved via a transactional message, such as an ISO message, an application programming interface (API), or another type of web interface (eg, a web request).

[0049] A "token requestor" may refer to an entity that wishes to perform tokenization in accordance with embodiments of the present invention. A token requester may initiate a Primary Account Number (PAN) tokenization request by submitting a token request message to the token service provider. In accordance with various embodiments discussed herein, a token requester may no longer need to store a PAN associated with a token after the requester has accepted the token in response to a token request message. The requester may be an application, device, process, or system that is configured to perform actions associated with tokens. For example, the requester may request registration of network tokens in the system, request generation of a token, activation of a token, deactivation of a token, exchange of a token, other processes related to the management of the life cycle of a token, and/or any other processes related to a token. The requestor may interact with the network token system over any suitable networks and/or communication protocols (eg, using HTTPS, SOAP, and/or an XML interface, among others). Some non-limiting examples of token requesters may include, for example, "card record" merchants, acquirers, acquirer processing centers, and payment gateways acting on behalf of merchants, payment intermediaries (e.g. OEMs, mobile operators, etc.), digital wallet providers, issuers, third party wallet providers and/or payment processing networks. In some embodiments, a token requester may request tokens for multiple domains and/or channels. A token requester can be registered and uniquely identified by a token service provider within the tokenization ecosystem. During registration of the token requester, the token service provider may formally process the token requester's application to participate in the token service system. The token service provider may collect information pertaining to the nature of the requester and the appropriate use of the tokens in order to validate and formally approve the token requester and establish appropriate domain constraint controls. Successfully registered token requesters may be assigned a token requestor ID, which may also be placed and stored in the token store. Token requesters may be revoked or assigned new token requester IDs. This information may be subject to reporting and auditing by the token service provider.

[0050] The "Token Requestor Identifier (ID)" may include any characters, numbers, or other identifiers associated with an entity associated with the network token system. In some embodiments, a unique token requester ID may be assigned for each token request domain associated with the same token requester. For example, the token requester ID may identify the pairing of the token requester (eg, mobile device, mobile wallet provider, etc.) with the token domain (eg, e-commerce, contactless, etc.). The token requester ID may include any format or type of information. For example, in one embodiment, the token requestor ID may include an alphanumeric value, such as a set of ten or eleven letters and/or numbers (eg, 4678012345). In some embodiments, the token requester ID may include a code for a token service provider (e.g., the first 3 digits) such as a network token system, and the remaining digits may be assigned by the token service provider for each requesting entity (e.g., mobile wallet provider) and the domain of the token (e.g. contactless, e-commerce, etc.).

[0051] A "token request indicator" may refer to an indicator used to indicate that a message containing the indicator is related to a token request. The token request indicator may optionally be passed to the issuer as part of the Identification and Verification (ID&V) method to tell the issuer the reasons why the account status is being checked.

[0052] The "Token Domain" may indicate factors that may be set at the time of token issuance to allow the appropriate use of the token for payment transactions. Examples of a token domain may include, but are not limited to, POS input mode and merchant identifiers to uniquely identify where the token can be used. A set of parameters (ie, token domain restriction controls) may be set as part of the issuance of the token by the token service provider, which may allow the appropriate use of the token in payment transactions to be enforced. For example, token domain restriction controls may restrict the use of the token to specific presentation modes, such as contactless or e-commerce presentation modes. In some embodiments, the token domain restriction controls may restrict the use of the token by a particular merchant, which may be uniquely determined. Some exemplary token domain constraint controls may require verification of the presence of a token cryptogram that is unique to a given transaction.

[0053] A "token expiration date" may refer to a token expiration date/time that is generated by the token service provider and stored in the token store. The token expiration date can be passed between tokenization ecosystem entities during transaction processing to ensure interoperability and minimize the impact of tokenization implementation. The token expiration date can be a numeric value (for example, a 4-digit numeric value) that is consistent with industry standards.

[0054] "Token interoperability" may refer to a process that ensures that the processing and exchange of transactions between parties through existing interoperability is preserved when using tokens with new data fields and data field values that are defined in embodiments of the present invention.

[0055] "Token processing" may refer to transaction processing in which a token is present in place of a Primary Account Number (PAN). The token is processed from the point of interaction and further throughout the network. Processing the token further includes using the token store to detokenize the token in order to complete the transaction. Token processing may cover payment processes, which include authorization, capture, clearing, and exception handling.

[0056] A "consumer" may be a person or user who may be associated with one or more personal accounts and/or consumer devices. A consumer may also be referred to as a cardholder, account holder, or user.

[0057] A "Primary Account Number (PAN)" may be a variable length (eg, 13-19 bit) industry standard compliant account number that is generated within account ranges associated with an issuer's BIN.

[0058] A "card record (COF)" merchant can be any entity that stores account details (eg, card details, billing account IDs, PANs, etc.) for use in transactions. For example, a COF entity may store billing information in records for various types of recurring payments, such as monthly utility bills, recurring purchase transactions, or any other recurring or future transaction. Because the payment credentials and/or associated tokens are stored in the entity for a future transaction, transactions initiated by the COF entity include card in physical absence (CNP) transactions. Another type of card out of place (CNP) transaction includes e-commerce transactions that are initiated between remote parties (eg, a consumer device and a merchant's web server computer).

[0059] An "Authorization Request Message" may be an electronic message that is sent to payment processing networks and/or a payment account issuer to request authorization for a payment transaction. The authorization request message, in accordance with some embodiments, may comply with the requirements of ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a consumer using a payment device or payment account. In some embodiments, the authorization request message may include the payment token, expiration date, token present mode, token requestor ID, token cryptogram, token guarantee level, and data used to generate the token guarantee level. The payment token may include a payment token issuer ID, which may be a substitute for the real issuer ID for the issuer. The authorization request message may also contain additional data elements corresponding to the "identity information", including, for example, a service code, CVV or CVC (card authentication parameter or code), dCVV or dCVC (dynamic parameter or card authentication code), token cryptogram, expiration date, etc. The authorization request message may also contain "transaction information", for example, any information related to the current transaction (for example, transaction amount, merchant ID, merchant location, etc.), as well as any other information that can be used in determining whether to identify and/or authorize a payment transaction.

[0060] The "Authorization Request Response Message" may be an Authorization Request Message Response Message generated by an issuing financial institution (ie, an issuer) or a payment processing network. The authorization response message may include an authorization code, which may be a code that the billing bank returns in response to the authorization request message in an electronic message (directly or via a payment processing network) to the merchant access device (e.g., POS terminal), which indicates the approval of the transaction. The code can serve as proof of authorization. As noted above, in some embodiments, the payment processing network may generate and/or forward an authorization response message to the merchant.

[0061] A "server computer" can generally be a powerful computer or a cluster of computers. For example, a server computer may be a large mainframe, a cluster of minicomputers, or a group of servers that function as a single unit. The server computer may be associated with an entity such as a payment processing network, wallet provider, merchant, authentication cloud, acquirer, or issuer.

[0062] "Issuer" may include the issuer of the payment account. A payment account (which may be associated with one or more payment devices) may refer to any suitable payment account, including a credit card account, checking account, savings account, merchant account assigned to a consumer, or prepaid account.

[0063] An "Agent" may be an entity designated by an issuer to perform specific functions on behalf of the issuer. Example functions may include card processing, cardholder verification using the 3-D Secure protocol, and a token service. For example, an access control server (ACS) may be an issuer agent that provides a 3D-Secure Identification and Verification (ID&V) service.

[0064] A "payment network" may refer to an electronic payment system used to approve, transmit, or process transactions made using payment devices for money, goods, or services. The payment network can transfer information and funds between issuers, acquirers, merchants and users of payment devices.

I. Ecosystem of tokenization

[0065] The implementation of token solutions, as shown in embodiments of the present invention and in accordance with embodiments of the present invention itself, includes a number of entities within the tokenization ecosystem depicted in FIG. 1.

[0066] FIG. 1 shows a system and flowchart providing an overview of the various interactions of entities in a tokenization ecosystem 100 in accordance with an exemplary embodiment of the present invention. The tokenization ecosystem 100 may include an account holder 102, a merchant 106, an acquirer 108, a payment network 110, and an issuer 104. A token requester 114 and a token service provider 116 may form a token service system 112 that is also part of the tokenization ecosystem 100. The token service provider 116 may include a token store 118 and a server computer 120 (such as the server computer depicted in more detail in FIG. 10). As will be discussed below, various objects of the tokenization ecosystem 100 may take on the role of token requestor 114 . Likewise, various entities of the tokenization ecosystem 100 may take on the role(s) of the token service provider 116 . The roles for each of these objects will be described in more detail below.

[0067] Issuer 104 may be a business entity issuer processing center (eg, a bank) that could issue an account (eg, credit account, debit account, etc.) for payment transactions. In some implementations, the business entity (bank) associated with issuer 104 may also function as acquirer 108. Issuer 104 may issue an invoice represented by a primary account number (PAN) to account holder 102 at the request of account holder 102. The account holder 102 may use the account to conduct payment transactions. The issuer 104 may be responsible for authorization and ongoing risk management in the tokenization ecosystem 100 . The issuer 104 must process any data fields provided in messages that are transmitted to and from the issuer, as defined in embodiments of the present invention, in order to properly process payment transaction requests.

[0068] The account holder 102 may wish to conduct a payment transaction with the merchant 106 using an account (represented by a PAN) issued by the issuer 104. For security purposes, as discussed herein, the account holder 102 may not wish to share the PAN with merchant 106. Accordingly, a token representing the PAN may be generated by the token service system 112 and transmitted to the merchant server 106 (eg, merchant server or computer).

[0069] In some embodiments, the token may be transferred via near field communication (NFC) (eg, point of sale use case). In other embodiments, the merchant 106 may already know the PAN of the account holder 102 (eg, "with card entry" use case). For example, a "card record" merchant may store account information of the account holder 102 in records (e.g., in the merchant's database) for future payments, such as various types of recurring payments (e.g., monthly utility bills) . In some implementations, the account holder 102 may register with one or more merchants 106 for card entry services. If the merchant 106 is a "card entry" merchant, then the merchant 106 may be the token requestor 114 . When a merchant 106 is a token requester 114, the merchant 106 may need to provide an implementation of the token service API, which may be referred to in embodiments of the present invention. The various use cases will be discussed in more detail below.

[0070] In accordance with various embodiments, card record merchants, acquirers, acquirer processing centers, payment gateways on behalf of merchants, payment brokers (e.g., device manufacturers, original equipment manufacturers ( OEM)), digital wallet providers or issuers can take on the role(s) of token requestor 114 . The token requestor 114 may register with the token service provider 116 (ie, the server computer 120 of the service provider 116). Upon successful registration with the token service provider 116, the token requestor 114 may be assigned a token requestor ID. The token requestor 114 may implement the specified token API after registering with the token service provider 116 . Various APIs that may be used in connection with embodiments of the present invention are discussed below with respect to FIGS. 9. The token requester 114 may be able to initiate a token request from the token service provider 116 in accordance with the processes and technologies specified in the API. The token request may be initiated by sending a token request message to the token service provider 116 . The token request message may include information about the token requester or the token requester ID, the token domain constraint controls, the PAN to be represented (eg, replaced) by the token, and optionally the requested token assurance level.

[0071] When the token service provider 116 processes the token request message sent by the token requester 114, the token service provider 116 may issue a token. The issued token may be stored in the token store 118 and provided to the token requestor 114 . During token generation, token service provider 116 may identify and store the token-PAN match in token store 118 for use in subsequent transaction processing. The token store 118 may also permanently associate each generated token with the token requestor 114 that submitted the request by capturing and storing the token requester ID.

[0072] In some embodiments, the tokens that are generated by the token service provider 116 may have a corresponding token expiration date. The expiration date of the token may follow the format of the PAN expiration date and may be the same date or a different date from the date of the actual PAN. In various embodiments, tokens that are generated in response to a token request from token requestor 114 are only valid for transactions within the token domain for which the token was issued.

[0073] Accordingly, the token service provider 116 may be an entity within the tokenization ecosystem 100 that may be allowed to generate and/or provide tokens to the token requestor 114 . In some embodiments, the token requestor 114 may be registered with the token service provider 116 . In accordance with exemplary embodiments of the present invention, payment network 110, issuer 104, or issuer's agent 104 may act as token service provider 116.

[0074] The token service provider 116 may be responsible for a number of separate functions as an authorized party to issue tokens. One or more functions of the token service provider 116 may be performed by the server computer 120. The token service provider 116 may be responsible for the ongoing operation and maintenance of the token store 118 storing the generated tokens and the correspondence between the tokens and the PAN represented by the tokens. The token service provider 116 may be responsible for generating and issuing tokens, as well as applying security and controls to generated tokens. The token service provider 116 may register the token requestor 114 and provide the generated token to the requestor's devices.

[0075] Token service provider 116 may be responsible for creating and/or managing its own proprietary application programming interface (API) for token requester 114, token store 118, token grant platform, and token registry. The token service provider 116 can ensure that token BINs can be managed separately from traditional BINs, in particular to avoid any accidental match between PANs and tokens. The token service provider 116 may generate a token using the token BIN in such a way as to ensure that the product and other attributes of the PAN are preserved during all existing transaction processes.

[0076] In accordance with various embodiments, when the token service provider 116 issues a token for a PAN associated with an account, the account owner 102 may not know that a token has been issued to represent the account. In some embodiments, account holder 102 may be asked to participate in an identification and verification (ID&V) process during token generation. For example, the account holder 102 may be asked to provide identification information to ensure that the token is being generated for an account that is legally owned by the account holder 102.

[0077] Based on the type of ID&V being executed, the token service provider 116 may also generate a token guarantee level associated with the generated token during token issuance. The token guarantee level may represent a level of trust in the association between the payment token and the PAN represented by the payment token. For example, a high token assurance level is a secure token association with a PAN from an authorized account holder that can support secure and secure payment transactions initiated at checkout. The generated token assurance level may be different from the requested token assurance level, which may optionally be provided to the token service provider 116 by the requestor 114 in the token request message. In some embodiments, based on the type of ID&V executing or the ID&V executing entity, the generated token guarantee level may be the same as the requested token guarantee level. Token guarantee levels may change after they have been assigned and may be recalculated based on factors that may affect trust levels such as reporting fraud or fraud-related chargebacks, etc.

[0078] The token assurance level generated by the token service provider 116 may be based on the ID&V that was running and the entity that is running the ID&V. The ID&V methods can be used singly or in combination to provide a particular level of token guarantee. The token service provider 116 may implement one or more ID&V methods. Additionally, the token service provider 116 can ensure that the ID&V method(s) appropriate for the requested token assurance level are always executed when the token is issued.

[0079] The ID&V steps may be performed by the token service provider 116, the token requestor 114, or a third party. In cases where the ID&V steps are performed by an entity other than the token service provider 116, verifiable evidence can be provided to prove that the steps were performed and that the ensuing results were provided. Verifiable evidence may consist of any value provided to the token service provider 116 by the ID&V processing entity that the token service provider 116 can validate. Examples of verifiable evidence may include a cryptogram or an authorization code. They can be applied to all ID&V methods, except in cases where ID&V is not executed. The token service provider 116 may set the token guarantee level to the appropriate value(s) based on the ID&V being executed and the token storage and usage information provided by the token requester 114 during registration of the token requester.

[0080] In accordance with various embodiments of the present invention, token guarantee levels can range from no guarantee to a high guarantee level depending on the ID&V methodology being executed, the ID&V executing entity, and the token service provider 116 that validates the evaluation result. Exemplary ID&V methods may include, but are not limited to, (1) ID&V not performed, (2) account verification, (3) token service provider risk score, (4) token service provider risk score with token requester data, and ( 5) authentication of the issuer of the account holder. One skilled in the art will appreciate that the prior ID&V methods are provided for purposes of illustration only, and that additional ID&V methods may be defined and performed in accordance with embodiments of the present invention.

(1) ID&V is not running

[0081] When the token is issued without performing any ID&V method during the issuance of the token, the guarantee level of the token may indicate (eg, the value of the guarantee level of the token may be set to) "No guarantee". In some embodiments, the absence of an ID&V does not result in the lowest token guarantee level assigned to the issued token. Depending on the use case of the token and the rules of the token service provider, the token may still be used to initiate payment transactions, but may not carry any token guarantee, or may carry a low token guarantee. Additional restrictions on the use of tokens with no guarantee level may be implemented in accordance with embodiments of the present invention.

(2) Account verification

[0082] Account verification may be an ID&V assurance method that provides a basic account verification check to validate that the PAN is active and valid. In various embodiments, account verification may include: $0 authorization, card verification number validation, and zip code and address verification. The account verification method may be performed, for example, by the token requester 114 and communicated to the token service provider 116 via the token service API. The account verification method may also be performed by the token service provider 116 at the time the token is issued. When a token is issued by performing account verification at the time of token issuance, the token guarantee level may indicate (eg, the value of the token guarantee level may be set to) "Verification by token requester completed" or "Guaranteed by token requestor".

(3) Token Service Provider Guarantee

[0083] Token service provider assurance is a type of ID&V assurance method that includes token service provider 116 performing a risk-based assessment of the likelihood that a request to tokenize a PAN is guaranteed with a sufficient level of confidence. The token service provider 116 may perform a risk-based assessment using the risk and authentication data stored by the token service provider 116 . When the token is issued guaranteed by the token service provider, the token guarantee level may indicate (eg, the value of the token guarantee level may be set to) "guaranteed by the token service provider". In some embodiments, a token service provider's guarantee may result in an average token guarantee level being assigned to the issued token.

(4) Service Provider Guarantee of Tokens with Requestor Data

[0084] Service provider guaranteeing tokens with requestor data is an ID&V guarantee method that includes using data elements provided by token requestor 114 that can predict fraud. For example, token requestor 114 may provide, among other information, account age and history, billing/delivery address and contact information, IP address, device ID and device information, geographic location, and transaction speed. The token service provider 116 may have appropriate evaluation techniques and tools for implementing this ID&V method, and may combine the resulting ID&V data with the PAN-related token service provider risk and authentication data to determine the assigned token assurance level. When a token is issued token service provider-guaranteed with requestor data, the token guarantee level may indicate (eg, the token guarantee level value can be set to) "guaranteed by the token service provider with requestor data". In some embodiments, a token service provider's guarantee may result in an average token guarantee level being assigned to the issued token.

(5) Verification by the issuer of the account holder

[0085] Issuer verification of the account holder is an ID&V method that includes interacting with the issuer 104 or the issuer's agent(s) to perform account holder verification to provide the assurance necessary to complete the binding of the token to the PAN. The methods used for verification may be implemented to provide an acceptable user interface based on the type of device (eg, mobile phone, computer, etc.) that the account holder may be using during the authentication process. In some embodiments, device instructions may be created to be followed to ensure a consistent user experience. Issuer authentication may use input and metrics from the token requestor 114 so that the issuer 104 can provide the most intelligent interface to the account holder 102 . Using this data can allow the issuer 104 to be confident that a genuine and authorized account holder 102 is actually requesting a token (or a token is requested for a genuine and authorized account holder 102) without having to add additional steps to the process. The input requested/received from the account holder 102 may include, but is not limited to, geographic location, device information, IP address, consumer information (e.g., email address, mobile phone number, landline phone number, verified address shipments, consumer ID&V, and customer relationship duration) and account information (e.g., length of time in wallet and/or account activity, such as missing, recent, or old). When a token is issued with account holder issuer verification, the token guarantee level may indicate (for example, the value of the token guarantee level can be set to) "Issuer Guaranteed". In some embodiments, the issuer's verification of the account holder may result in a high level or the highest level of token guarantee assigned to the issued token.

[0086] According to various embodiments, account holder issuer verification can be performed via 3-D Secure Access Control Server (ACS), mobile banking account holder verification with an authentication code, federated login systems, API functionality capable of generating, delivering and verifying the data from the token requestor and shared secrets, one-time password (OTP), activation code, or other shared secret between the issuer 104 and the account owner 102. If the issuer 104 determines that there is a need to verify the account holder 102 requesting the token through explicit verification (eg, using an OTP or an activation code), the shared secret may be delivered to the account holder 102 via an out-of-band channel.

[0087] The issuer 104 may use a variety of methods to authenticate the account holder. According to some embodiments, static passwords and logging into an authentication service during account holder authentication may not be allowed for ID&V methods. In contrast, as noted above, one-time passwords may be used to authenticate the account holder by the issuer 104. When OTP is used, the issuer 104 may require that the OTP be at least 6 digits long and no more than 8 digits, the OTP is generated using a uniform methodology , and the preferred method for delivery is a secure channel from the issuer 104 to the consumer device of the account holder 102 (eg, a mobile banking application installed on the consumer device).

[0088] Returning to FIG. 1, when a token and a corresponding token assurance level are generated, the token service provider 116 may store the generated token, the PAN represented by the token, the token assurance level associated with the token, and data (e.g., type of ID&V executed, data used in the execution of the ID&V, object executing ID&V, etc.) used to generate a token guarantee level in a repository such as token store 118.

[0089] The token store 118 can provide the ability to generate and issue tokens, establish and maintain a token-PAN match, and provide basic security and associated processing controls such as domain restrictions during transaction processing. The token store 118 may provide a mechanism for matching the token-PAN to be available during transaction processing such as authorization, clearing, and exception handling. The token store 118 may need to store all associated tokens corresponding to a given PAN throughout its life cycle.

[0090] The token generated by the token service provider 116 may be provided to the token requestor 114 in response to the token requestor 114 token request. As indicated above, the token requester 114 may be registered with the token service provider 116 . Token service provider 116 may provide the generated token to token requester 114 when token service provider 116 recognizes the token requestor ID assigned to token requestor 114 during registration. Issuing the token may also include providing the token to the token requestor 114 . The provision of the token may occur after the token has been generated and the guarantee steps have completed. The token grant may be performed over an interface between the token requestor 114 and the token service provider 116 .

[0091] If the token requester 114 is the account holder 102, upon receipt of the token, the account holder 102 may present the token to the merchant 106 in a payment authorization request message. Alternatively, if the token requestor 114 is a merchant 106, the token may be directly provided to the merchant 106 by the token service provider 116 . Merchant 106 may generate a payment authorization request message. The payment authorization request message may be to conduct a payment transaction using the primary account number represented by the token contained in the payment authorization request message. The merchant 106 may send a payment authorization request message including the token to the acquirer 108 for further processing.

[0092] Acquirer 108 may be a system (acquirer computer or server) for an entity (eg, a bank) that has a business relationship with merchant 106. Acquirer 108 may issue and manage a financial account for merchant 106. In in general, the acquirer 108 may be responsible for authorizing, capturing, clearing, and handling exceptions in the tokenization ecosystem 100. The acquirer 108 may be communicatively connected to the merchant 106 and the payment processing network 110 . The acquirer computer 108 may be configured to route an authorization request message including the token to the issuer computer 104 via the payment processing network computer 110 . The acquirer computer 108 may also route the authorization response message received from the issuer computer 104 through the payment processing network computer 110 to the merchant computer 106 .

[0093] Payment network 110 (also referred to as a payment processing network) may be communicatively coupled to issuer 104 and acquirer 108. Payment network 110 may be configured to provide authorization and clearing services for payment transactions. Payment network 110 may include data processing subsystems, wired or wireless networks, including but not limited to the Internet. Payment network 110 may include a server computer. In some implementations, payment network 110 may transmit an authorization request message received from acquirer 108 to issuer 104 over a communication channel. The authorization request message received from the acquirer 108 may include a token.

[0094] The payment network 110 may communicate with the token service provider 116 to obtain a token guarantee level associated with the token. The assurance level of the token may represent the level of trust in the association between the payment token and the PAN represented by the payment token. The token guarantee level may be generated by the token service provider 116 and, when the token is generated, stored in the token store 118 along with the payment token. The payment network 110 may modify the authorization request message received from the acquirer 108 to include the guarantee level of the token and data (eg, the type of ID&V executed, the data used in the execution of the ID&V, the entity that executed the ID&V, etc.) used to generating a token guarantee level. The payment network 110 may also modify the authorization request message to include the PAN represented by the token contained in the authorization request message. Payment network 110 may then send a modified authorization request message to issuer 104. Payment network 110 may receive an authorization response message from issuer computer 170 and forward the received authorization request response message to acquirer 108. In some embodiments, payment network 110 may modify the authorization response message to an authorization request received from the issuer 104 before forwarding the authorization response message to the acquirer 108. For example, the payment network 110 may modify the authorization response message to remove the PAN (eg, replace the PAN with a token) if the PAN was included in the request response message authorization, and may include the last 4 digits of the PAN in the authorization response message.

[0095] In accordance with various embodiments of the present invention, the payment network 110 may serve as a token service provider 116. An exemplary embodiment in which payment network 110 serves as token service provider 116 is discussed in more detail below with respect to FIG. 2. Payment network 110 acting as token service provider 116 may be responsible for creating and/or managing their own proprietary token requester API, token store, token grant platform, and token registry. A payment network 110 that is not a token service provider 116 may support the implementation of processing functions that allow messages to be exchanged with the token service provider 116 for detokenization purposes to ensure token interoperability.

[0096] FIG. 2 shows a system and flowchart providing an overview of the various interactions of entities in a tokenization ecosystem 200, where a payment network 210 serves as a token service provider 216, in accordance with an exemplary embodiment of the present invention. Some of the objects depicted in Fig. 2 are the same or similar to those shown in FIG. 1. A detailed description of these objects is provided above with respect to FIG. 1 and as such will be omitted below.

[0097] As shown in FIG. 2, account holder 102 may wish to conduct a payment transaction with merchant 106. Account holder 102 may be able to initiate a transaction using a payment account identifier (eg, primary account number (PAN)). In addition, the account holder 102 may be able to use the consumer device to initiate a transaction using any suitable transaction channel, for example, by scanning a mobile device (for example, using a QR™ code or a barcode), touching the mobile device with a merchant access device. enterprise (for example, a Near Field Communication (NFC) transaction or other contactless/proximity transaction), clicking on a computer or other mobile device to initiate an e-commerce transaction (for example, an online transaction) or through any other channel in which a transaction can be initiated and the token can be transferred to the merchant's computer. For example, in some embodiments, a mobile device may be used to initiate a remote transaction with a token provided on a secure element, other secure memory of the mobile device, or in the cloud, such as emulating a primary card.

[0098] If the account holder 102 possesses a payment device that includes a token representing an account number, the account holder 102 may present the token to the merchant 106 by scanning or touching the payment device of the merchant 106 with the payment device. If the holder 102 account does not hold the token, the account holder 102 (eg, account holder 102's payment device) may contact the token requester 114 to request the token. Alternatively, the merchant 106 may contact (or become) the token requester 114 to obtain a token for a transaction initiated or requested by the account holder 102.

[0099] The token requestor 114 may register with the token service provider 216 (ie, the payment network 210 in FIG. 2) and may receive the token requester ID provided by the token service provider 216 . The token service provider 216 may set up a process for registering objects that request to be designated as token requestor 114 . In some embodiments, entities that wish to be considered token requester 114 for multiple token service providers may register separately with each token service provider in accordance with proprietary processes established by each token service provider. The token service provider 216 may define information that must be collected from the token requestor 114 before the token requestor 114 is registered. The token service provider 216 may also establish its own proprietary processes for collecting, reviewing, and approving received information. Illustrative information collected from token requester 114 may include, but is not limited to, know-your-customer (KYC) information, as well as token use cases that a registering token requester may support, including any appropriate domain restrictions. and other transaction controls that may be implemented in the token store 218. The result of the registration function is a decision to approve or reject the application for registration of the prospective requester 114 of the token. If the token requester 114 is approved by the token service provider 216, the token requestor 114 is assigned a unique token requestor ID.

[0100] Token requester registration is a function that can ensure the integrity of the token service system 216 by filing, approving, and registering an object as a token requester 114 . Token service provider 216 (ie, payment network 210 in FIG. 2) may assign at least one unique token requester ID to token requester 114, and may be responsible for managing the lifecycle of token requester 114 and the corresponding token requestor ID. As part of the registration, the payment network 210 may also capture the requested token guarantee level and token domain restriction controls associated with the token requestor 114. The payment network 210 can ensure that the domain restrictions are available to the token store 218 for applying the restrictions during the processing of token transactions.

[0101] The token challenger ID assigned by the payment network 210 acting as the token service provider 216 may be unique and not conflict with other assigned token challenger IDs from the same payment network 210 or another token service provider. The token requester ID may include an 11-digit numeric value assigned by payment network 210 with the following illustrative rule: positions 1-3 may contain a token service provider code unique to each token service provider; and positions 4-11 can be assigned by the token service provider for each requestor and token domain. A token service provider code may be assigned to each token service provider and stored by the service provider or set of service providers that manage, develop, and maintain embodiments of the present invention. The token requestor ID is a basic element of control information that may be present in the transactions discussed in this document.

[0102] The token requestor 114 may indicate configuration preferences or token attributes associated with the requested token. Token configuration preferences or attributes may include, for example, the type of token (e.g., static or dynamic), supported presentation modes of the token (e.g., scan, contactless, e-commerce, etc.), and any other relevant token configuration information in token request message. The token requester 114 may send a token request message to the token service provider 216 . Accordingly, the token request message may include the token requester ID, token attributes, token domain constraint controls, the PAN to be represented by (eg, replaced by) the token, and optionally the requested token assurance level.

[0103] The payment network 210, as the token service provider 216, is responsible for determining the expected guarantee level associated with each approved token requestor 114. The actual guarantee level of the token can be determined at token generation time based on the type and outcome of the ID&V process. The actual guarantee level of the token may differ from the requested guarantee level of the token.

[0104] To ensure that the tokens are used by the token requestor 114 as intended, additional controls may be needed to control and validate the underlying usage of the tokens. Controls may be defined and implemented by payment network 210 as token service provider 216 based on conditions including use cases and token domains such as merchant IDs and token present modes that are identified during the token requestor registration process. Token domain controls can be designed to ensure that token data leakage does not lead to significant levels of subsequent fraud. The allowed token domain controls for a given token requestor 114 are partly controlled by the token use cases specified during token requester registration and approved by payment network 210 as token service provider 216 . Domain restriction controls may be stored in the token store 218 .

[0105] Other controls that are intended to restrict transactions associated with token requester 114 may include using the token present mode value found in the POS Entry Mode data field of the payment authorization request message. Token present mode values can restrict the use of tokens to only those token present modes that were negotiated at the time of registration of the token requester. For example, if the token requestor 114 has registered for the "card record" use case, the payment network 210 may issue limited-use tokens with the token requester ID and token present mode values that indicate e-commerce, so that only payment processing will be allowed. network 210 only e-commerce transactions. In other embodiments, when the token present mode is an NFC point of sale present mode, the use of the token may be limited to only the contactless chip POS input modes.

[0106] In embodiments where merchant 106 is the token requestor 114, merchant-related data elements, such as the card acceptor ID, in combination with the acquirer-identifying data elements and the token cryptogram, may be used to restrict the use of the token. by checking or comparing these fields in the transaction processing messages with the controls set in the token store 218 for the information found out during registration of the token requester. An exemplary embodiment may include the tokenization of PANs held at "card record" merchants.

[0107] Upon receipt of the token request message from the token requester 114, the payment network 210 may generate a token for the PAN provided in the token request message. The payment network 210 may query the type of ID&V being performed to confirm whether the person conducting the transaction is the legal owner of the account. Based on the type of ID&V being executed and information about the entity running the ID&V, payment network 210 may also generate a token guarantee level associated with the generated token. The token guarantee level may represent the level of trust in the association between the generated payment token and the PAN represented by the payment token. The payment network 210 may store the association between the PAN and the generated token, along with the token guarantee level and the data used to generate the token guarantee level, in storage 218. The payment network 210 may provide the token to the token requestor 114 in a token request response message.

[0108] The token requester 114 may present the token to the merchant 106, which may generate a payment authorization request message including the token. Merchant 106 may send a payment authorization request message to acquirer 108, which may then send a payment authorization request message to payment network 210. If the token requestor ID is also passed to merchant 106, the transaction may not be allowed to be processed successfully if the token requestor ID present in the payment authorization request message does not match the token requestor ID associated with the token in the token store 218, or if the token cryptogram fails validation.

[0109] Upon receipt of the payment authorization request message, the payment network 210 may interact with the token store 218 and/or other network server(s) 220 to detokenize the token provided in the payment authorization request message. In particular, the payment network 210 may obtain the PAN represented by the token as a result of the detokenization process. The payment network 210 may then modify the payment authorization request message to include the PAN along with (or in place of) the token, as well as the guarantee level of the token and the data used to generate the guarantee level of the token. Payment network 210 may send a modified payment authorization request message to issuer 104.

[0110] The issuer 104, after receiving the PAN, the token representing the PAN, the token guarantee level, and the data used to generate the token guarantee level, in the payment authorization request message, can perform account level validation and authorization verification. The issuer 104 may send a payment authorization response message to the payment network 210 approving or rejecting the payment transaction. The payment authorization response message may include the PAN, the token, token requester information or token requester ID, token domain constraint controls, token guarantee level, and the data used to generate the token guarantee level, among other data. The payment network 210 may modify the payment authorization response message to replace the PAN with the token. In some embodiments, the payment network 210 may include the token guarantee level in the payment authorization response message, but may delete the data used in generating the token guarantee level. The contents of the Payment Authorization Request message and the Payment Authorization Request Response message are discussed in more detail below with respect to exemplary use cases. Payment network 210 may send a modified payment authorization response message to merchant 106 via acquirer 108. Based on the authorization response message, merchant 106 may complete the transaction with account holder 102.

II. Illustrative use cases

[0111] This section provides descriptions and flow diagrams for token transactions for the exemplary use cases shown in FIG. 3-8. Exemplary use cases defined in embodiments of the present invention include near field communication (NFC) mobile communications at the point of sale (FIG. 3), e-commerce with a mobile/digital wallet (FIG. 4), e-commerce with a record of card (FIG. 5), point of sale scanning (FIG. 6), clearing and capturing processing (FIG. 7), and exception handling (FIG. 8). Accordingly, FIG. 3-8 identify some of the data elements that may be present in transactions with authorization, capture, clearing, and exception handling, depending on the use case and data element.

[0112] Implementing a token service based on embodiments of the present invention may include passing token-related data in message data fields as indicated in FIG. 3-8. In the exemplary embodiments depicted in FIGS. 3-8, the payment network acts as a token service provider. However, the present invention is not limited to the exemplary embodiments depicted in FIGS. 3-8. For example, as noted above, other tokenization ecosystem entities may act as a token service provider. Embodiments ensure that when a payment network is acting as a token service provider, the payment network can recognize token transactions to match PAN tokens during transaction processing.

Use case 1: Mobile NFC at the point of sale

[0113] Referring now to FIG. 3, point of sale mobile NFC use case 300 refers to using an NFC-enabled mobile device 302 to initiate contactless payment at a merchant terminal 302. The mobile device 302 may be provided with a token that is stored in a secure memory, such as a secure element, of the mobile device 302. In accordance with various embodiments, the provision of the token may be performed by the interaction of the token requester with the token service provider, as discussed above.

[0114] When a transaction is initiated, the mobile device 302 may generate a contactless transaction 306 including the token, the expiration date of the token, the cryptogram of the token, and other chip data elements. These data elements may be included in the contactless transaction 306 in special data fields, as depicted in FIG. 3. According to various embodiments, the mobile device 302 may transmit the token data elements to the merchant terminal 304 as follows: the token may be transmitted in the PAN data field F2; the expiration date of the token can be passed in the F14 field of the PAN expiration date data; the cryptogram of the token may be generated based on the data elements of the token, and may be transmitted in the data field F55 of the cryptogram of the chip; the token presentation mode can be set to the POS input mode for contactless transactions in the data field F22; and all other contactless data items can be created and transmitted following a typical contactless communication. The token cryptogram generated by the mobile device 302 may serve as a domain constraint control field that may be used by the token service provider to validate the good faith of a transaction using the token.

[0115] The mobile device 302 may transmit the contactless transaction 306 including the above data fields to the point of sale terminal 304 via the NFC interface. The merchant terminal 304 may send an authorization request message 310 to the acquirer 308. The authorization request message 310 sent by the merchant terminal 304 to the acquirer 308 may include the same data elements as the contactless transaction 306 sent by the mobile device 302 terminal 304 trade and service company.

[0116] Upon receipt of the authorization request message 310, the acquirer 308 may perform checks and transmit the token data fields and contactless data of the payment network 312 acting as the token service provider. Authorization request message 314 sent by acquirer 308 to payment network 312 may include the same data elements as authorization request message 310 and contactless transaction 306.

[0117] A payment network 312 acting as a token service provider may process a token transaction. The processing may include interacting with the token store 313 to obtain the PAN represented by the received token. The payment network 312 may verify the token-PAN matching state in the token store 313 to ensure that the token is in an active state. The payment network 312 may validate the token cryptogram received in the authorization request message 314 . The payment network 312 may also validate the domain restriction controls stored in the token store 313 for the accepted token. The payment network 312 may also retrieve from the token store 313 the token guarantee level and the data used in generating the token guarantee level associated with the received token. The payment network 312 may then modify the authorization request message 314 to generate a modified authorization request message 318 . In the modified authorization message, the token may be replaced by PAN in the data field F2; the token expiration date can be replaced by the PAN expiration date in data field F14; the POS input mode can be transmitted in the data field F22; an indicator may be included in the data field F60.6 to convey to the issuer that validation of the token "on behalf of" has been completed by the token service provider; The product ID may be passed in data field F62.23; and various token-related fields can be included. For example, token-related fields may include the token passed in the F123 - DSI 68 Tag1 field of the data, the expiration date of the token, the guarantee level of the token passed in the F123 - DSI 68 Tag2 data field, the token guarantee data, and the token requestor ID, transmitted in field F123 - DSI 68 Tag3 data. After generating the modified authorization request message 318, the payment network 312 may send the modified authorization request message 318 to the issuer 316.

[0118] The data fields depicted herein are provided for illustrative purposes only and should not be construed as limiting. The same or similar information may be conveyed in other data fields. For example, the ID of the token requester may be transmitted in subfield 6 of sub-element 33 of data element 48, the product code may be transmitted in subfield 4 of sub-element 33 of data element 48, and the guarantee level of the token in subfield 5 of sub-element 33 of data element 48. These and any other data fields used to convey the information discussed herein are within the scope of the present invention.

[0119] The issuer 316 can complete the account-level validation and authorization check using the information provided in the modified authorization request message 318. The issuer may send an authorization response message 319 to the payment network 312. For example, the issuer 316 may send the token information of the payment network 312 in predefined data fields of the authorization response message 319. The issuer 316 may send a PAN in data field F2, a product ID in data field F62.23, and a token in data field F123 - DSI 68 Tag1.

[0120] After receiving the authorization response message 319 from the issuer 316, the payment network 312 may modify the authorization response message 319 by replacing the PAN with the token based on the match. Payment network 312 may generate a modified authorization response message 320 including data elements such as one or more tokens in data field F2, token guarantee level in data field F123 - DSI 68 Tag2 data, the last 4 digits of PAN in field F44. 15 data and PAN product ID in data field 62.23. Payment network 312 may send a modified authorization response message 320 to acquirer 308. Acquirer 308 may then transmit authorization response message 322 to merchant terminal 304. The authorization response message 322 may include the same data fields as the modified authorization response message 320.

[0121] The authorization response message 319 and the modified authorization response messages 320 and 322 may indicate whether the issuer 316 approved the transaction initiated by the account holder using the mobile device 302. After the authentication response message 322 is provided to the terminal 304 merchant, the account holder may be notified of the success or failure of the transaction.

Use Case 2: Ecommerce with Mobile/Digital Wallet

[0122] Referring now to FIG. 4, in the mobile/digital wallet e-commerce use case 400, the account owner 402 initiates a payment transaction to the e-commerce site using the mobile/digital wallet to communicate payment and other order information to the merchant e-commerce site owner 404. The mobile/digital wallet may be operated by the issuer 416, payment network 412, or other third parties. According to various embodiments, a digital wallet operator may be a token requestor.

[0123] In FIG. 4, it is possible that the wallet operator has already provided for tokenization in order to no longer store the PAN in the wallet platform for security or other reasons. When an account holder 402 initiates a payment transaction at an e-commerce merchant 404 that works with the wallet in use, the wallet may send a payment transaction request message 406 including a token instead of a PAN and other order information (e.g., shipping address) to the merchant. service enterprise 404 through the wallet API.

[0124] When a transaction is initiated, the merchant/digital wallet application on the mobile device of the account holder 402 may interact with the payment application to send data items to the merchant 404 in the payment transaction request message 406. The payment transaction request message 406 may pass the token in the PAN field of the message, the expiration date of the token in the data field of the expiration date of the PAN message, the token cryptogram may optionally be generated based on the data elements of the token and transmitted in the token cryptogram field of the message, and the presentation mode token in the POS (as e-commerce transaction) input mode field of the message. The payment transaction request message 406 may also include the ID of the token requester in an optional message field, as well as other data elements. In some embodiments, the payment transaction request message 406 may include the same data fields as the contactless transaction 306 shown in FIG. 3.

[0125] The merchant terminal 404 may generate and send an authorization request message 410 to the acquirer 408 carrying the token data fields. The authorization request message 410 sent by the merchant terminal 404 to the acquirer 408 may include the same data elements as the payment transaction request message 406. In particular, the authorization request message 410 may include a token in the PAN field; the token expiration date in the PAN expiration date data field; cryptogram of the token in the cryptogram field of the chip; ID of the token requester in the optional data field; and the token present mode can be set to the POS input mode for the e-commerce transaction.

[0126] Upon receipt of the authorization request message 410, the acquirer 408 may perform checks and pass the token data fields to the payment network 412 acting as the token service provider. The authorization request message 414 sent by the acquirer 408 to the payment network 412 may include the same data elements as the authorization request message 410.

[0127] A payment network 412 acting as a token service provider may process the transaction. The processing may include interacting with the token store 413 to retrieve the PAN represented by the received token. The payment network 412 may verify the token-PAN matching state in the token store 413 to ensure that the token is in an active state. The payment network 412 may validate token cryptograms when the cryptogram is received in an authorization request message 414 . The payment network 412 may also validate the domain constraint controls stored in the token store 413 for the accepted token. The payment network 412 may also retrieve from the token store 413 the token guarantee level and the data used in generating the token guarantee level associated with the received token. The payment network 412 may then modify the authorization request message 414 to generate a modified authorization request message 418. In the modified authorization message, the token may be replaced with a PAN; the expiration date of the token can be replaced by the expiration date of the PAN; An indicator can be added to convey to the issuer that validation of the token “on behalf of” has been completed by the token service provider; and token-related fields may be passed in an authorization request message. Token-related fields may include the token, token expiration date, token guarantee level, token guarantee data, and token requestor ID. After generating the modified authorization request message 418, the payment network 412 may send the modified authorization request message 418 to the issuer 416.

[0128] The issuer 416 may complete the account-level validation and authorization check using the information provided in the modified authorization request message 418. The issuer may send an authorization response message 419 to the payment network 412. After receiving the authorization response message 419 from the issuer 416, the payment network 412 may modify the authorization response message 419 by replacing the PAN with a matching token. The payment network 412 may generate a modified authorization response message 420 including data elements such as one or more tokens, the token guarantee level, the last 4 digits of the PAN, and the PAN product ID. The payment network 412 may send the modified authorization response message 420 to the acquirer 408. The acquirer may then send the authorization response message 422 to the merchant terminal 404. The authorization response message 422 may include the same data fields as the modified authorization response message 420.

[0129] The authorization response message 419 and modified authorization response messages 420 and 422 may indicate whether the issuer 416 approved the transaction initiated by the account owner 402. After the authentication response message 422 is provided to the merchant terminal 404, the account holder may be notified of the success or failure of the transaction.

Use case 3: E-commerce "with card record"

[0130] Referring now to FIG. 5, a "card record" e-commerce use case 500 is depicted. In FIG. 5, an e-commerce merchant 504 that has payment account details (e.g., PAN and PAN expiration date) already stored in a database entry may seek to eliminate the underlying storage security threat by replacing the PAN with a token. Accordingly, in embodiments relating to "card entry" e-commerce transactions, merchant 504 may be a token requestor. After the token is returned to the merchant 504 "with card record", all subsequent e-commerce transactions that are processed may include the token and token expiration date (transmitted in the PAN data and PAN expiration date fields) in messages transactions transmitted in the tokenization ecosystem.

[0131] To initiate a payment transaction, the account holder 502 can log in to the merchant 504 "with card record" and initiate an e-commerce purchase on the merchant's website. The merchant website may pass token data elements to the merchant platform (eg, merchant server 504) in special fields of the payment transaction request message. According to various embodiments, the merchant website may send the data elements of the token to the merchant server 504 as follows: the token may be passed in the PAN field of the payment transaction request message, the expiration date of the token may be passed in the date field expiration of the PAN message, the merchant ID may be passed in the data field, the token present mode may be set to the POS input mode for e-commerce transactions, the token requestor ID may be passed in the optional message field, the token cryptogram may be an optional element data that can be generated based on the data fields of the token and transmitted in the optional data field of the message. All other merchant identifiers may be created and posted in the payment transaction request message. According to various embodiments, the token requestor ID and the corresponding merchant identifiers may serve as domain constraint control fields that may be used to validate the good faith of a transaction.

[0132] The merchant server 504 may generate and send an authorization request message 510 to the acquirer 508 containing the token data fields. Accordingly, the authorization request message 510 sent by the merchant terminal 504 to the acquirer 508 may include the same data elements as the payment transaction request message sent by the merchant website to the merchant server 504.

[0133] Upon receipt of the authorization request message 510, the acquirer 508 may perform checks and pass the token data fields to the payment network 512 acting as the token service provider. The authorization request message 514 sent by the acquirer 508 to the payment network 512 may include the same data elements as the authorization request message 510.

[0134] The payment network 512 acting as the token service provider may process the token transaction. The processing may include interacting with the token store 513 to retrieve the PAN represented by the received token. The payment network 512 may verify the token-PAN matching state in the token store 513 to ensure that the token is in an active state. The payment network 512 may validate the token cryptogram received in the authorization request message 514. The payment network 512 may also validate the domain restriction controls stored in the token store 513 for the accepted token. The payment network 512 may also retrieve the token guarantee level and the data used to generate the token guarantee level associated with the accepted token from the token store 513 . The payment network 512 may then modify the authorization request message 514 to generate a modified authorization request message 518. In the modified authorization message, the token may be replaced with a PAN; the expiration date of the token can be replaced by the expiration date of the PAN; An indicator can be added to convey to the issuer that validation of the token “on behalf of” has been completed by the token service provider; and token-related fields may be passed in an authorization request message. Token-related fields may include the token, token expiration date, token guarantee level, token guarantee data, and token requestor ID. After generating the modified authorization request message 518, the payment network 512 may send the modified authorization request message 518 to the issuer 516.

[0135] The issuer 516 may complete the account-level validation and authorization check using the information provided in the modified authorization request message 518. The issuer may send an authorization response message 519 to the payment network 512. After receiving the authorization response message 519 from the issuer 516, the payment network 512 may modify the authorization response message 519 by replacing the PAN with the token based on the match. The payment network 512 may generate a modified authorization response message 520 including data elements such as one or more tokens, the token guarantee level, the last 4 digits of the PAN, and the PAN product ID. The payment network 512 may send the modified authorization response message 520 to the acquirer 508. The acquirer may then send the authorization response message 522 to the merchant terminal 504. The authorization response message 522 may include the same data fields as the modified authorization response message 520.

[0136] The authorization response message 519 and the modified authorization response messages 520 and 522 may indicate whether the issuer 516 approved the transaction initiated by the account holder using the mobile device 502. After the authentication response message 522 is provided to the terminal 504 merchant, the account holder may be notified of the success or failure of the transaction.

Use Case 4: Scanning at the Point of Sale

[0137] Referring now to FIG. 6 depicts a mobile quick code (QRC) in a point of sale use case. In FIG. 6, mobile device 602 may initiate a QRC-based payment at a merchant location using a QRC reader 604. In some embodiments, the application on mobile device 602 may generate a dynamic QRC each time a payment is initiated in a secure manner. When a transaction is initiated, the mobile device 602 may generate a transaction request message 606 including the token, token expiration date, token cryptogram elements, and any other data from the QRC, and transmit the transaction request message 606 to the merchant terminal 604.

[0138] When a transaction is initiated, the mobile device 602 may interact with the merchant terminal 604, which can read the QRC, and transmit data elements to the merchant terminal 604 in a payment transaction request message 606. The payment transaction request message 606 may pass the token in the PAN field of the message, the expiration date of the token in the data field of the expiration date of the PAN message, the QRC data in the data field of the message, the cryptogram of the token may optionally be generated based on the data elements of the token and transmitted in the data field cryptograms of the message token, and the mode of presenting the token in the data field is the mode of entering the POS (as a QRC-based transaction) of the message. The payment transaction request message 606 may also include the ID of the token requester in an optional message field, as well as other data elements. The token cryptogram may optionally be generated by the mobile device 602 and may serve as a domain constraint control field that may be used by the token service provider to validate the good faith of a transaction using the token.

[0139] The merchant terminal 604 may generate and send an authorization request message 610 to the acquirer 608 containing the token data fields. The authorization request message 610 sent by the merchant terminal 604 to the acquirer 608 may include the same data elements as the payment transaction request message 606. In particular, the authorization request message 610 may include a token in the PAN field; expiration date of the token in the PAN expiration date field; cryptogram of the token in the cryptogram field of the chip; ID of the token requester in the optional data field; the token present mode can be set to the POS input mode for the QRC based transaction and the QRC data.

[0140] Upon receipt of the authorization request message 610, the acquirer 608 may perform checks and pass the token data fields to the payment network 612 acting as the token service provider. The authorization request message 614 sent by the acquirer 608 to the payment network 612 may include the same data elements as the authorization request message 610.

[0141] A payment network 612 acting as a token service provider may process a token transaction. The processing may include interacting with the token store 613 to retrieve the PAN represented by the received token. The payment network 612 may verify the token-PAN matching state in the token store 613 to ensure that the token is in an active state. The payment network 612 may validate the cryptogram of the token if the cryptogram is received in the authorization request message 614. The payment network 612 may also validate the domain constraint controls stored in the token store 613 for the accepted token. The payment network 612 may also retrieve the token guarantee level and the data used to generate the token guarantee level associated with the accepted token from the token store 613 . The payment network 612 may then modify the authorization request message 614 to generate a modified authorization request message 618. In the modified authorization message 618, the token may be replaced with a PAN; the expiration date of the token can be replaced by the expiration date of the PAN; An indicator can be added to convey to the issuer that validation of the token “on behalf of” has been completed by the token service provider; and token-related fields may be passed in an authorization request message. Token-related fields may include the token, token expiration date, token guarantee level, token guarantee data, and token requestor ID. After generating the modified authorization request message 618, the payment network 612 may send the modified authorization request message 618 to the issuer 616.

[0142] The issuer 616 may complete the account-level validation and authorization check using the information provided in the modified authorization request message 618. The issuer may send an authorization response message 619 to the payment network 612. After receiving the authorization response message 619 from the issuer 616, the payment network 612 may modify the authorization response message 619 by replacing the PAN with the token based on the match. The payment network 612 may generate a modified 620 authorization response message including data elements such as one or more tokens, the token guarantee level, the last 4 digits of the PAN, and the PAN product ID. The payment network 612 may send a modified authorization response message 620 to the acquirer 608. The acquirer may then send an authorization response message 622 to the merchant terminal 604. The authorization response message 622 may include the same data fields as the modified authorization response message 620.

[0143] The authorization response message 619 and the modified authorization response message 620 (and 622) may indicate whether the issuer 616 approved the transaction initiated by the account holder 602. After the authentication response message 622 is provided to the merchant terminal 604, the account holder may be notified of the success or failure of the transaction.

Sequence of capture and clearing operations

[0144] Capture processing may refer to the transfer of funds from the account holder to the merchant. Clearing can be called the process of transferring, agreeing and confirming funds resulting from payment transactions. During the clearing process, clearing messages may be transmitted from the payment network acquirer and from the payment network to the issuer. The clearing process defined in the embodiments of the present invention may be implemented using a clearing system managed by, for example, a payment network.

[0145] FIG. 7 depicts exemplary capture and clearing processes for a token transaction. In accordance with various embodiments, the merchant 702 may generate a capture file 706 based on information provided by the consumer (eg, account holder) at the time the transaction was initiated. The capture file 706 may include a token in the PAN data field F2 and an expiration date of the token in the PAN expiration date data field F14. The merchant 702 may send the capture file 706 to the acquirer 704.

[0146] The acquirer 704 may check the data elements of the capture file 406 . The acquirer 704 may create a clearing file 710 to be sent to the payment network 708 acting as the token service provider. The clearing file 710 may include the token in the TCR0 PAN field, the expiration date of the token in the data field of the PAN expiration date, the token present mode set to the POS input mode of the channel dependent transaction in the data field TCR0, and the guarantee level of the token. in a new data field TCR1 that can be added for token transactions. In some embodiments, the clearing file 710 may also include a cryptogram in the TCR7 field of the record data.

[0147] When the payment network 708 receives the clearing file 710, the payment network 708 may interact with the token store 713 to retrieve the PAN corresponding to the received token. The payment network 708 may verify the token-PAN matching state in the token store 713 to ensure that the token is in an active state. If the cryptogram is included in the clearing file 710, the payment network 708 may validate the cryptogram. The payment network 708 may also validate the domain restriction controls stored in the token store 713 for the accepted token.

[0148] The payment network 708 may then modify the clearing file 710 to generate the modified clearing file 714. In the modified clearing file 714, the token may be replaced by PAN in the data field TCR0; An indicator can be added to convey to the issuer that validation of the token “on behalf of” has been completed by the token service provider; and token-related fields may be passed in an authorization request message. The token-related fields may include the token in the data field TCR5 and the token guarantee level in the data field TCR1. In some embodiments, the cryptogram may be included in the TCR7 data field of the modified clearing file 714. After generating the modified clearing file 714, the payment network 708 may send the modified clearing file 714 to the issuer 712.

[0149] The issuer 712 may complete the account level validation using the information provided in the modified clearing file 714 and complete the clearing process.

Sequence of Exception Operations

[0150] Exception handling may refer to messages transmitted in the tokenization ecosystem related to chargeback requests and/or payments that were not processed due to, for example, lack of funds or lack of consumer/payment/transaction information. In some embodiments, where exception handling refers to chargeback processing, chargeback messages may be sent from the payment network issuer and from the payment network to the acquirer.

[0151] FIG. 8 depicts an exemplary chargeback request token processing flow and chargeback data elements. In accordance with various embodiments, the issuer 802 may apply for a chargeback after validating that the original transaction is a valid chargeback request and that the issuer 802 has the appropriate chargeback rights. The chargeback record file 806 may be generated by the issuer 802 and sent to the payment network 804. The chargeback record file 806 may include, among other data elements, the PAN (which was used in the original purchase transaction) in the TCR0 data field, the token corresponding to PAN, in the data field TCR5, the guarantee level of the token obtained from the token store 813 in the data field, and the ID of the token requester may be transmitted in the optional field in the chargeback record file 806 .

[0152] When the payment network 804 receives the chargeback record file 806, the payment network 804 may verify the token-PAN matching state in the token store 813 to ensure that the token is in an active state. If the token is not included in the chargeback record file 803 sent by the issuer 802, the payment network 804 may retrieve the token for the disputed transaction from the token store 813. The payment network 804 may then generate a modified chargeback record file 810 to be sent to the acquirer 808. Modifications implemented by the payment network 804 to generate the modified chargeback record file 810 may include replacing the PAN with the appropriate token and optionally including one or several token-related fields in the modified chargeback record file 810, such as token requestor ID and token guarantee level.

[0153] Upon receipt of the modified chargeback record file 810, the acquirer 808 may validate the modified chargeback record file 810 and, based on the case study, may move to another phase of dispute processing or alternatively may resolve the chargeback.

III. Token Service Provider Application Programming Interfaces (APIs)

[0154] FIG. 9 depicts the use of application programming interfaces (APIs) by a token service provider to provide the issuance and processing of tokens (eg, to provide a token service).

[0155] Embodiments of the present invention describe the interaction between the token service provider 904 and other entities in the tokenization ecosystem 900 through the use of one or more APIs and/or messaging interface(s) to provide token requests, token issuance, ID&V execution, detokenization, routing tokens and token lifecycle management. Accordingly, embodiments of the present invention establish common data elements for interfaces that the token service provider 904 can support. In accordance with some embodiments, the interfaces discussed herein may be implemented and made available by the token service provider 904 for use by all participating entities that interact with the token service provider 904.

[0156] The token service provider 904 may provide the ability to install and use interfaces or APIs with objects that are authenticated through a secure way of interacting with the token service provider 904 . For example, interactions may occur through authenticated methods including, but not limited to, web services, ISO 8583 messaging over an existing payment network interface, and file/packet. One or more entities in the tokenization ecosystem 900 such as token requester 902, ID&V executor 906, other networks 908, payment network 910 may use token service interfaces.

[0157] Interfaces can be classified as token request and issue interface(s) 912, token guarantee interface(s) 914 (e.g., ID&V), detokenization interface(s) 916, token routing interface(s) 918, and interface(s) token lifecycle management. One or more defined interfaces may allow message passing to perform specific token-related operations.

Interface(s) for requesting and issuing tokens

[0158] As discussed above, the token service provider 904 may provide an interface 912 that the registered token requester 902 may use to submit a token request message including the original payment credentials and receive a token request response message including the token from token service provider 904 . The token request message and the token request response message may be passed between the token requester 902 and the token service provider 904 via the token request and issue interface 912 .

[0159] The token request and issue interface 912 may support real-time token issuance requests for the requested PAN, or bulk requests through a secure interface file in which tokens are generated and issued in large quantities and returned to the token requestor 902. The token service provider 904 may implement appropriate controls and processes to generate a token based on the input PAN. In some embodiments, the assurance steps may be performed based on a request.

[0160] The input elements in the token request message may contain one or more token requestor IDs, PAN, PAN expiration date, and requested guarantee level. The optional data elements may include account holder data such as a billing/delivery address and postal code to perform the ID&V method of guaranteeing the token. The input elements for the token request message passed through the exemplary token request and issue interface 912 are shown in Table 1.

Field name Length Format Description Token Requester ID eleven Numerical Unique ID assigned to the requester PAN length 1 Binary PAN field length PAN Variable (13 to 19 digits) Numerical PAN for which the token is being requested PAN expiration date 4 Numerical The expiration date of the PAN for which the token is being requested Requested guarantee level 2 Numerical Present if a guarantee level is requested. Token Guarantee Level 2 Numerical Present if the token requester performed ID&V. Length of cardholder data 2 Binary Length of cardholder data, may contain zero (0) if missing Cardholder details Variable Alphanumeric Data required to support the requested assurance level. Examples are billing address, shipping address, zip code, and CVV2.

Table 1

Input data elements passed through the interface of requesting and issuing tokens

[0161] In response to the token request message, the request and issue token interface 912 may send a response message that contains one or more data elements, including, but not limited to, the status of the request (for example, whether the request succeeded or failed) and , if the request fails, a reason code indicating the type of failure. For successful requests, additional data elements such as the token and the expiration date of the token may be returned in the token request response message. If a token guarantee method was performed at the time of token issuance, the token request and issue interface 912 may optionally provide the assigned token guarantee level to the token requestor 902. The output elements for the token request response message passed through the exemplary token request and issue interface 912 are depicted in Table 2.

Field name Length Format Description Request Status 1 Numerical Indicates the success or failure of a request Reason code Variable Binary Present if the status of the request is unsuccessful Token Variable (13 to 19 digits) Numerical Present, if the status of the request is successful, the token is generated by the token service provider. Token expiration date 4 Numerical Present, if the status of the request is successful, the expiration date of the token is generated by the token service provider. Token Guarantee Level 2 Numerical Present if the status of the request is successful and has been requested by ID&V.

table 2

Output data elements passed through the request and issue token interface

Guarantee interface(s) (ID&V) of tokens

[0162] Token guaranteeing (ID&V) interface 914 may send a request to perform ID&V when issuing a token to verify account holder and PAN information. A token guarantee interface 914 may be provided between the token service provider 904 and the entity executing ID&V 906. In some embodiments, the token service provider may perform ID&V. If the token service provider 904 provides support for ID&V, the token service provider 904 may implement one or more interfaces to support the ID&V methods. Additionally, the token service provider 904 can ensure that the ID&V method(s) appropriate for the requested token assurance level are performed when the token is issued. The input elements for the ID&V request message passed through an exemplary token guarantee (ID&V) interface are shown in Table 3.

Field name Length Format Field Description Transaction type 2 Numerical • NN - Purchase
• NN - Issuance of a token
• NN - Token Revalidation cardholder's PAN Variable (13 to 19 digits) Numerical Primary account number; a financial PAN that can be associated with a token Card Expiry Date 4 Numerical Financial PAN expiration date Token Requester ID eleven Numerical A unique value assigned to the registered entity that is requesting the token Requested guarantee level 2 Numerical Indicates the level of validation that the token requester would like to be performed, such as no guarantee, verified by the token requester, guaranteed by the token requester, guaranteed by the token service provider, guaranteed by the token service provider with the requester data, or guaranteed by the issuer Location of the token 2 Numerical Specifies where the token is stored, such as 01 - remote/cloud or 02 - secure element Protocol 2 Numerical Describes which protocol the token requester uses to communicate with the cardholder, mobile app API, and/or browser Account Verification Results 2 Numerical Indicates the results of account verification, if successful, Success or Failure Token Requestor Risk Score 4 Numerical A measure of the risk of fraud provided by the token requester Address mismatch indicator 2 Numerical To be filled in if billing and shipping address are different Cardholder billing address Variable Alphanumeric Includes data such as address line 1, address line 2, city, state/province(territory), zip code, and country code Device Information Variable Alphanumeric The device information attribute consists of a set of credentials related attributes. These include, but are not limited to, IP address, operating system, geographic location, device ID, and device category such as laptop or phone. Home phone number 16 Numerical Home phone number provided by the cardholder Cell phone number 16 Numerical Mobile phone number provided by the cardholder Work phone number 16 Numerical Business phone number provided by the cardholder Account information Variable Alphanumeric The account information element consists of a set of attributes related to the payment account, such as email address, account age, number of PANs in the record, and average transaction speed.

Table 3

Input data elements passed through the guarantee interface (ID&V) of the token

[0163] In response to an ID&V request, the token assurance (ID&V) interface 914 may send a request response message to the token service provider 904 that contains one or more data elements, including, but not limited to, the status of the request (e.g., success or failure) and, if ID&V was unsuccessful, a reason code explaining the type of failure. For successful requests, the token assurance (ID&V) interface 914 may return additional data elements in the ID&V request response message. Exemplary output elements for the ID&V Request Response message sent over the Token Guarantee (ID&V) interface 914 are shown in Table 4.

Field name Length Format Field description cardholder's PAN Variable (13 to 19 digits) Numerical Primary account number; a financial PAN that can be associated with a token Assigned guarantee level 2 Alphanumeric Indicates the level of validation that the token requester would like to be performed and can be changed by the network Verification value Variable Alphanumeric The verification value is obtained by the issuer or entity that performs the authentication. Verification algorithm Variable Alphanumeric Specifies the algorithm used to generate the verification value

Table 4

Output data elements transmitted through the guarantee interface (ID&V) of the token

Detokenization interface(s)

[0164] The detokenization interface(s) 916 may provide the necessary mechanism for exchanging the issued token by returning the original PAN data and the PAN expiration date to the authenticated entity. The token service provider 904 may interact with other networks 908 (via the detokenization interface 916) to handle detokenization. The token service provider 904 may implement appropriate security controls to provide access to the detokenization interface 916 . The token service provider 904 can ensure that the request is received from a recognized and authenticated source. In some embodiments, the token service provider 904 may be a payment network, and detokenization may be performed by the payment network. Exemplary input data elements for the detokenization request message sent through the detokenization interface 916 are depicted in Table 5.

Field name Length Format Description Token Requester ID eleven Numerical Unique ID assigned to the requester Token length 1 Alphanumeric Token length Token Variable (13 to 19 digits) Alphanumeric Issued token Token expiration date 4 Numerical Issued token expiration date

Table 5

Input elements passed through the detokenization interface

[0165] The detokenization interface 916 may send a detokenization request response message that contains output elements such as the status of the request (eg, success or failure) and, if the request is unsuccessful, a reason code explaining the type of failure. For successful requests, additional data elements such as PAN and PAN expiration date may be returned in the detokenization request response message. Exemplary output elements for the detokenization request response message sent through the detokenization interface 916 are shown in Table 6.

Field name Length Format Description Request Status 1 Binary Indicates the success or failure of a request Reason code Variable Binary Present if the status of the request is unsuccessful PAN length 1 Binary Present if the status of the request is successful, with the length of the PAN field PAN Variable (13 to 19 digits) Numerical Present if request status is successful, with PAN PAN expiration date 4 Numerical Present if the status of the request is successful, with a PAN expiration date

Table 6

Output elements passed through the detokenization interface

Token routing interface(s)

[0166] The token routing interface(s) 918 provides the necessary mechanism for routing a token transaction to the payment network 910, which is responsible for processing the transaction. In some embodiments, such as when a payment network is acting as a token service provider, the routing may also include detokenization routing to route the token for detokenization. Exemplary input data elements for the token processing message passed through the token routing interface 918 are depicted in Table 7.

Field name Length Format Description Token Requester ID eleven Numerical Unique ID assigned to the requester Token Length 1 Binary Token Length Token Variable (13 to 19 digits) Numerical Issued token Token expiration date 4 Numerical Issued token expiration date Length of transaction data elements Variable Binary The length of the Other Transaction Data Elements field may be zero (0) if not present. Transaction Data Elements Variable Implementation dependent Other transaction data elements required by the token service provider to fulfill the request, the content is the property of the token service provider

Table 7

Input elements passed through the token routing interface

[0167] The token routing interface 918 may send a token processing request response message that contains output elements such as the status of the request (eg, success or failure) and, if the request is unsuccessful, a reason code explaining the type of failure. For successful requests, additional data elements such as PAN and PAN expiration date may be returned in the token processing request response message. Exemplary output elements for a token processing request response message sent via token routing interface 918 are shown in Table 8.

Field name Length Format Description Request Status 1 Binary Indicates the success or failure of a request Reason code Variable Binary Present if the status of the request is unsuccessful PAN length 1 Binary Present if the status of the request is successful, with the length of the PAN field PAN Variable (13 to 19 digits) Numerical Present if request status is successful, with PAN PAN expiration date 4 Numerical Present if the status of the request is successful, with a PAN expiration date Length of transaction data elements Variable Binary Length of the Other Transaction Data Elements field, may be zero (0) if absent Transaction Data Elements Variable Implementation dependent Transaction data elements required by the network to continue the transaction, the content is the property of the token service provider

Table 8

Output elements passed through the token routing interface

Interface(s) for token lifecycle management

[0168] Tokens may be subject to ongoing management and updates due to changes to the PAN and PAN expiration date, as well as events that may cause the token requestor 902 to deactivate the match. The token service provider 904 can provide lifecycle updates via interfaces to manage changes that affect the issued token. Lifecycle events can be handled using interfaces such as token unbind interface, token suspend interface, token activation interface, token guarantee update interface, and PAN attribute update interface. Table 9 provides exemplary lifecycle events that may be made available as interfaces by the token service provider 904 .

Interface Event/Description Requested by Action to take Token unbinding • Device lost or stolen
• Original credentials are no longer valid
• The token requester no longer keeps a record of the card
• PAN lost or stolen
• Fraud alert for PAN
• Token failure warning Token Requester
Card issuer
Payment network The token is unlinked from the PAN and matching is disabled for future use. Token Suspension • Temporary deactivation due to lost or stolen device Token Requester Token-PAN matching is temporarily suspended and further use may be denied. Activating a token • Resume token-PAN matching after temporary suspension Token Requester Token-PAN compliance is activated after a temporary suspension to allow further use. Token Guarantee Update • Current management of the token guarantee level Token Service Provider The token guarantee level is updated to match the token-PAN based on the ID&V method being executed. Update PAN Attributes • Updates to original credentials such as PAN expiration date Token Requester Updates to PAN attributes, such as the PAN expiration date, are made to extend the use of the token-PAN match.

Table 9

Lifecycle update interfaces

[0169] Ongoing token-PAN mapping changes due to lifecycle events such as PAN refresh, device loss or theft, and token deactivation due to end of client relationship with token requester may be serviced by a token service provider when implemented in accordance with embodiments of the present invention.

IV. Technical advantages and other specifications

[0170] In accordance with various embodiments of the present invention, the token can increase the cost of the payment processing environment while improving transparency and protecting account holder information. Tokens can be global and multichannel; interoperable with BIN-based tokens; linked to, mapped to, or associated with the base credential; distinct and identifiable in the system; able to be transmitted through or routed by existing objects of the tokenization ecosystem in order to minimize the impact of the ecosystem; compatible with existing payment technologies (eg web, NFC, POS standards); capable of supporting alternative payment channel technologies (for example, QR code); static or dynamic (eg limited use, time limits); capable of supporting authentication by various entities and types (eg, issuer, wallet, merchant); and compatible with all regulatory obligations (eg routing decisions).

[0171] Embodiments of the present invention include using existing data fields, including token-related data in current fields, and new data fields to ensure implementation consistency and interoperability across the tokenization ecosystem. One or more data fields provided as part of some embodiments of the present invention may be optional.

[0172] The transaction authorization messages, in particular the request messages that go from the merchant to the acquirer, from the payment network acquirer, and from the payment network to the issuer, and all corresponding request response messages may depend on embodiments of the present invention. The degree of dependency may vary depending on the use case and may be specified in the specifications of the authorization messages transmitted by the involved payment networks as part of their implementation of tokenization solutions based on embodiments of the present invention.

[0173] In accordance with various embodiments described herein, a payment network may use a token service provider to match an issued token to a PAN in an incoming authorization message prior to sending the message to the issuer. The payment network may map the PAN back to the token in any response messages sent back to the acquirer. The token service provider can indicate to the payment network when tokens that are considered lost/stolen have been marked as suspended. The token service provider may validate the token in the incoming authorization message against data elements, including the token requester ID, and provide a result to the payment network regarding the validity of the token within the token domain's constraint controls. If a PAN is deemed compromised or at risk by a payment network or issuer, the token service provider may notify the relevant token requesters of the compromise and deactivate the associated tokens corresponding to the PAN. The token service provider may continue to add and implement features such as use cases for token and PAN lifecycle management that continue to evolve.

[0174] Processing the token and integrating the participating payment networks with the token stores may provide the ability to apply specific domain constraint controls as defined for a given token requester and use case. The domain constraint controls depend on the availability of specific control-related data items in transaction processing messages and the integrity of the underlying data, because these data items can guarantee controlled use of tokens.

[0175] Using tokens, consumers may be able to conduct a payment transaction using existing card record data, replaced with token credentials and enhanced with security features. In some embodiments, the ability to make payments may be built into a device (eg, mobile phone or smartphone). In some embodiments, a device may include an application or software capable of prompting a user to activate one or more payment cards to enable their use for transactions conducted using the device. The service activation process may include a risk score and a token request, an ID&V process, and a token grant.

[0176] In accordance with various embodiments, when used in person (or in a store), a consumer can "pay by touch" at contactless POS terminals. The process may include sending the token to the issuer via the payment network. The payment network can perform the token/PAN exchange using the accepted token and send the corresponding PAN to the issuer. Additionally, when using the app, the consumer can pay for transactions conducted with the merchant's certified supported app with a single click or selection on their device. The process may include sending the token to the issuer via the payment network. The payment network can perform the token/PAN exchange using the accepted token and send the corresponding PAN to the issuer.

[0177] A payment network or issuer-backed token may be associated with the original account credentials (e.g., payment device or payment account) and provided to the device provider for use in near field communication (NFC) and advanced e-commerce transactions. In some embodiments, when a consumer activates a device, the consumer account record may be replaced with a token from the payment network.

[0178] Embodiments of the present invention do not exclude existing solutions for tokens implemented by an acquirer or other third party, in which these entities generate tokens and define a token-PAN mapping in their tokenization ecosystem.

[0179] Product attributes, such as product type (eg, debit or credit), may be stored for tokenized transactions.

[0180] Issuer portfolio transformations associated with the transfer of cardholder portfolios may be serviced within any usable token service system implemented in accordance with embodiments of the present invention.

[0181] Table 10 provides a list of options that may be implemented by the acquirer, in accordance with various embodiments of the present application. The table shows if the option applies to an NFC transaction or an e-commerce transaction.

Option Change NFC Electronic commerce Accept and transfer the token and the expiration date of the token in field 2 and field 14 √ √ Receive and transmit cryptogram based on token in field 55, use 1 for NFC transactions √ Accept and transmit cryptogram based on token in field 126.9 for e-commerce transactions √ Send AVS data in field 123, use 2 TLV format in existing dataset ID 66 - AVS data √ √ √ Receive token data items in field 123, use 2, data set ID 68 - verification data (token guarantee level, regulated/unregulated; first nine digits of PAN) √ √ √ Accept last 4 digits of PAN in field 44.15 in authorization response √ √ √ Pass the token at positions 5-20 of the TCR 0 that was handled in the authorization message √ √ Send the token guarantee level in positions 6-7 of the additional TCR 1 data that was received in the authorization response √ √ √

Table 10

Options implemented by the acquirer

[0182] Table 11 provides a list of data elements that can be sent in messages transmitted through the acquirer.

Preliminary data Description Positions New field BASE II TC x5 and TC x6, TCR 0* Token
Note: When a token-PAN relationship cannot be found, BASE II will return the transaction with a new return reason code 9E - Token-PAN relationship cannot be found 5-20 √ TC x5 and TC x6, TCR 1 Token Guarantee Level 6-7 √ √

Table 11

Data elements transmitted to the acquirer/acquirer

[0183] Table 12 provides a list of options that may be implemented by an issuer, in accordance with various embodiments of this application. The table shows if the option applies to an NFC transaction or an e-commerce transaction.

Option Change NFC Electronic commerce Accept and process the POS input mode for the token in field 22 √ √ Accept and process cryptogram based on token in field 55, use 1 for NFC transactions √ √ Accept and process token-based cryptogram in poel 126.9 for e-commerce transactions √ √ Receive and process AVS data in field 123, use 2 TLV format in existing data set with ID 66 - AVS data √ √ √ Receive token data items in field 123, use 2, data set ID 68 - verification data (token, token requester ID, token guarantee level) √ √ √ Receive and process chip transaction indicator in field 60.6 with new value 4 (Visa generated token data) √ √ √ Accept token guarantee level in additional data TCR 1, positions 6-7 √ √ √ Accept token in payment service data TCR 5, positions 150-165 √ √ √ Submit token in TC 52 search query record, positions 88-103 √ √ √ Store and return token along with PAN to process chargeback exception, copy requests (TC52 via Base II and 0600 via SMS) √ √ √

Table 12

Options implemented by the issuer

[0184] Table 13 provides a list of data elements that can be sent in messages transmitted through the issuer.

Preliminary data and search query Description Positions New field BASE II TC x5 and TC x6, TCR 0 Account number 5-20 √ TC x5 and TC x6, TCR 1 Token Guarantee Level 6-7 √ √ TC x5 and TC x6, TCR 5 Token 150-165 √ √ TC52, TCR1 Token 88-103 √ √

Table 13

Data elements transmitted to the issuer/issuer

[0185] The data fields depicted in Tables 10-13 are provided for illustrative purposes only and should not be construed as limiting. The same or similar information may be conveyed in other data fields. These and any other data fields used to convey the information discussed herein are within the scope of the present invention.

V. Exemplary Systems

[0186] The various participants and elements shown in FIG. 1-9 may operate one or more computing devices (eg, a server computer) to provide the functions described herein. Any of the elements in Fig. 1-9 may use any suitable number of subsystems to provide the functions described herein. Examples of such subsystems or components are shown in FIG. 10. Shown are subsystems such as a printer 1208, a keyboard 1216, a hard drive 1218 (or other memory containing computer-readable media), a monitor 1212 that couples to a display adapter 1210, and others. Peripherals and input/output (I/O) devices that connect to the I/O controller 1202 may be connected to the computer system through any number of means known in the art, such as serial port 1214. For example, serial port 1214 or external interface 1220 may be used to connect the computing device to a wide area network such as the Internet, a mouse input device, or a scanner. A system bus connection allows the CPU 1206 to communicate with each subsystem and control the execution of instructions from the system memory 1204 or hard disk 1218, and to exchange information between the subsystems.

[0187] Specific details regarding some of the aspects described above are provided below. The specific details of specific aspects may be combined in any suitable manner without departing from the spirit and scope of the embodiments of the invention.

[0188] Storage media and computer-readable media for storing code or portions of code may include any suitable media known or used in the art, including storage media and communication media such as, but not limited to, volatile and non-volatile , removable and non-removable media implemented in any method or technology for storing and/or transmitting information such as machine-readable instructions, data structures, program modules, or other data, including RAM, ROM, EEPROM, flash memory, or other technology memory, CD-ROM, digital versatile disk (DVD) or other optical storage media, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, data signals, data transmissions, or any other medium that can be used for storage or transmission of the desired information and which can be accessed using a computer. Based on the disclosure and ideas presented herein, one of ordinary skill in the art may understand other ways and/or methods for implementing various embodiments.

[0189] It is to be understood that the present invention, as described above, may be implemented in the form of control logic using computer software in a modular or integrated manner. Based on the disclosure and ideas presented herein, one of ordinary skill in the art may recognize and understand other ways and/or methods for implementing the present invention using hardware and a combination of hardware and software.

[0190] Any of the software components or functions described in this application may be implemented as program code for execution by a processor using any suitable computer language such as, for example, Java, C++, or Perl using, for example, traditional or object-based oriented methods. The program code may be stored as a series of instructions or instructions on a computer readable medium such as random access memory (RAM), read only memory (ROM), a magnetic medium such as a hard disk or floppy disk, or an optical medium such as a CD-ROM. ROM. Any such computer-readable medium may reside on a single computing device, and may be present on multiple computing devices within a system or network.

[0191] The above description is illustrative and is not restrictive. Many embodiments of the invention may become apparent to those skilled in the art upon examination of the disclosure. Therefore, the scope of the invention may not be determined with reference to the above description, but may instead be determined with reference to the appended claims together with their full scope or equivalents.

[0192] One or more features from any embodiment may be combined with one or more features from any other embodiment without departing from the scope of the present invention.

[0193] Singular means "one or more" unless specifically stated otherwise.

Claims (46)

1. A method for conducting a payment transaction using a payment token, comprising the steps of: receiving, with the help of the issuer's server computer, an authorization request message from the transaction processing network, wherein the authorization request message contains the primary account number associated with the issuer's account, the token guarantee level associated with the payment token, together with the data used to generate the token guarantee level, wherein the authorization request message is intended to conduct a payment transaction using the primary account number, at the same time, the payment transaction is initiated using the payment token, wherein the token assurance level is an indicator indicating a level of confidence that the payment token is associated and replaces the primary account number that is legitimately used by the token requestor; performing, by means of the server computer, an account validation and an authorization check using the information included in the authorization request message, generating, by the server computer, an authorization response message authorizing or denying the payment transaction based on the account validation and authorization check; And transmitting, by the server computer, an authorization response message of the transaction processing network, wherein the authorization response message contains at least a determination of the issuer authorizing or rejecting the payment transaction using the primary account number. 2. The method of claim 1, wherein the token guarantee level is determined based on the identification and verification method used to identify and verify the identity of the account holder associated with the account. 3. The method of claim 1, wherein the token guarantee level is determined by the issuer performing the identification and verification method used to identify and verify the identity of the account holder associated with the account. 4. The method of claim 2, wherein the guarantee level of the token is updated when the additional identification and verification method is performed. 5. The method of claim 2, wherein the result of the first identification and verification method for identifying and verifying the account holder's identity is a first token guarantee level, and the result of the second identification and verification method for identifying and verifying the account holder's identity is a second token guarantee level, different from the first level of token guarantee. 6. The method of claim 1, wherein the authorization response message further comprises a primary account number and a token guarantee level associated with the payment token, along with the data used to generate the token guarantee level. 7. The method of claim 1, further comprising the steps of: before receiving the authorization request message: performing, by means of the server computer, the identification and verification method, wherein the identification and verification method includes the steps of: transmitting, via the server computer, a request for information to an account holder associated with the account; receiving, via the server computer, information from the account holder verifying the identity of the account holder associated with the account; determine, using the server computer, the guarantee level of the token based on the method of identification and verification; And transmitting, by means of the server computer, the guarantee level of the token and the data used to generate the guarantee level of the token, to the transaction processing network. 8. The method of claim 7, wherein the identification and verification method is performed on the user device of the account holder. 9. The method of claim 7, wherein the token guarantee level determined by the issuer is higher than another token guarantee level determined by any other token service provider. 10. The system for conducting a payment transaction using a payment token associated with the issuer, while the system contains: CPU; And a non-transitory computer-readable medium coupled to the processor, wherein the non-transitory computer-readable medium contains code that, when executed by the processor, causes the processor to: receive an authorization request message from the transaction processing network, wherein the authorization request message contains the primary account number associated with the issuer account, the token guarantee level associated with the payment token, along with the data used to generate the token guarantee level, wherein the authorization request message is intended to conduct a payment transaction using the primary account number, at the same time, the payment transaction is initiated using the payment token, wherein the token assurance level is an indicator indicating a level of confidence that the payment token is associated and replaces the primary account number that is legitimately used by the token requestor; perform account validation and authorization checks using the information included in the authorization request message, generate an authorization response message authorizing or denying the payment transaction based on the account validation and authorization check; And transmit an authorization response message to the transaction processing network, wherein the authorization response message contains at least a definition of the issuer authorizing or denying the payment transaction using the primary account number. 11. The system of claim 10, wherein the token guarantee level is determined based on the identification and verification method used to identify and verify the identity of the account holder associated with the account. 12. The system of claim 10, wherein the token guarantee level is determined by the issuer performing the identification and verification method used to identify and verify the identity of the account holder associated with the account. 13. The system of claim 11, wherein the token guarantee level is updated when an additional identification and verification method is performed. 14. The system according to claim 11, wherein the result of the first identification and verification method for identifying and verifying the identity of the account holder is the first level of guarantee of the token, and the result of the second identification and verification method for identifying and verifying the identity of the account holder is the second level of guarantee of the token, which is different from the first level of token guarantee. 15. The system of claim 10, wherein the authorization response message further comprises the primary account number and token guarantee level associated with the payment token, along with the data used to generate the token guarantee level. 16. The system of claim 10, wherein the code, when executed by the processor, further causes the processor to perform the steps of: before receiving the authorization request message: performing the identification and verification method, wherein the identification and verification method includes the steps of: transmitting a request for information to an account holder associated with the account; receiving information from the account holder verifying the identity of the account holder associated with the account; determine the level of guarantee of the token based on the method of identification and verification; And transmitting the token guarantee level and the data used to generate the token guarantee level to the transaction processing network. 17. The system of claim. 16, in which the method of identification and verification is performed on the user device of the account holder. 18. The system of claim 16, wherein the token guarantee level specified by the issuer is higher than another token guarantee level determined by any other token service provider.

Images