Patent Application
20250225506
Tokens can be used as substitutes for real credentials to obtain resources. However, tokenization systems cannot keep up with tokenization demands from token requestors. The number of tokens that have been generated in the recent years are in the billions, and this trend is predicted to continue.
An existing tokenization model requires tokens to be created and activated before the first use of the token. This results in multiple interactions between a token service provider and authorizing entities when the token is requested by a token requestor. Also, the infrastructure needed to create and activate tokens in-line between the token service provider and authorizing entities is expensive.
Another problem that needs to be addressed is that tokens can be provided to token requestors and activated, but then they are not used. In fact, a substantial number of card on file (CoF) tokens do not see any authorization requests during their lifespan, meaning that they are generated and activated but are never used in a transaction. This is problematic since such tokens may burden the tokenization system and may use token numbers that could otherwise be actively used.
Embodiments of the disclosure address this problem and other problems individually and collectively.
One embodiment of the invention includes a method. The method comprises: receiving, by a token service computer from a token requestor computer, a request to obtain a token; and providing, by the token service computer, a token request message to a token vault computer, wherein the token vault computer obtains the token, and receives a request to activate the token after the token is used to initiate a transaction.
Another embodiment of the invention includes a token service computer comprising: a processor; and a computer readable medium comprising code, executable by the processor, for performing a method comprising: receiving, from a token requestor computer, a request to obtain a token; and providing a token request message to a token vault computer, wherein the token vault computer obtains the token, and receives a request to activate the token after the token is used to initiate a transaction.
Another embodiment of the invention includes method comprising: transmitting, by a token requestor computer to a token service computer, a request to obtain a token, wherein the token service computer provides a token request message to a token vault computer, wherein the token vault computer obtains the token; and initiating, by the token requestor computer, a transaction, wherein the token vault computer receives a request to activate the token after the token is used to initiate a transaction.
Another embodiment of the invention comprises a token requestor computer comprising: a processor; and a computer readable medium coupled to the processor, the computer readable medium comprising code executable by the processor to implement a method comprising: transmitting, to a token service computer, a request to obtain a token, wherein the token service computer provides a token request message to a token vault computer, wherein the token vault computer obtains the token; and initiating a transaction, wherein the token vault computer receives a request to activate the token after the token is used to initiate a transaction.
A better understanding of the nature and advantages of embodiments of the invention may be gained with reference to the following detailed description and accompanying drawings.
Prior to discussing embodiments of the disclosure, some terms can be described in further detail.
A “resource provider” may be an entity that can provide a resource such as goods, services, information, and/or access to a location (e.g., a parking space, a transit terminal, etc.). Examples of resource providers include merchants, governmental authorities, secure data providers, etc. A resource provider may operate one or more access devices.
A “resource provider computer” can be a computer operated by a resource provider. An example of a resource provider computer can be an access device.
An “access device” may be any suitable device that provides access to a resource. An access device may be in any suitable form. Some examples of access devices include vending machines, kiosks, POS or point of sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, hand-held specialized readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), Web servers, and the like. An access device may use any suitable contact or contactless mode of operation to send or receive data from, or associated with, a user mobile communication device. In some embodiments, an access device may include a reader, a processor, and a computer-readable medium. A reader may include any suitable contact or contactless mode of operation. For example, exemplary readers can include radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers to interact with a payment device and/or mobile communication device.
“Access data” may include any suitable data that can be used to access a resource or create data that can access a resource. In some embodiments, access data may be account information for a payment account. Account information may include a PAN, payment token, expiration date, card verification values (e.g., CVV, CVV2), dynamic card verification values (dCVV, dCVV2), an identifier of an issuer with which an account is held, etc. In other embodiments, access data could include data that can be used to access a location or to access secure data. Such information may be ticket information for an event, data to access a building, transit ticket information, passwords, biometrics or other credentials to access secure data, etc.
An “authorizing entity” may be an entity that authorizes a request. Examples of an authorizing entity may be an issuer, a governmental agency, a document repository, an access administrator, etc. An authorizing entity may operate an authorizing entity computer. An “issuer” may refer to a business entity (e.g., a bank) that issues and optionally maintains an account for a user. An issuer may also issue payment credentials stored on a user device, such as a cellular telephone, smart card, tablet, or laptop to the consumer.
An “acquirer” may typically be a business entity (e.g., a commercial bank) that has a business relationship with a particular merchant or other entity. Some entities can perform both issuer and acquirer functions. Some embodiments may encompass such single entity issuer-acquirers. An acquirer may operate an acquirer computer, which can also be generically referred to as a “transport computer.”
A “processor” may refer to any suitable data computation device or devices. A processor may comprise one or more microprocessors working together to accomplish a desired function. The processor may include a CPU comprising at least one high-speed data processor adequate to execute program components for executing user and/or system-generated requests. The CPU may be a microprocessor such as AMD's Athlon, Duron and/or Opteron; IBM and/or Motorola's PowerPC; IBM's and Sony's Cell processor; Intel's Celeron, Itanium, Pentium, Xeon, and/or XScale; and/or the like processor(s).
A “memory” may be any suitable device or devices that can store electronic data. A suitable memory may comprise a non-transitory computer readable medium that stores instructions that can be executed by a processor to implement a desired method. Examples of memories may comprise one or more memory chips, disk drives, etc. Such memories may operate using any suitable electrical, optical, and/or magnetic mode of operation.
A “mobile communication device” may comprise any suitable electronic device that may be transported and operated by a user, which may also optionally provide remote communication capabilities to a network. Examples of remote communication capabilities include using a mobile phone (wireless) network, wireless data network (e.g., 3G, 4G or similar networks), Wi-Fi, Bluetooth, Bluetooth Low Energy (BLE), Wi-Max, or any other communication medium that may provide access to a network such as the Internet or a private network. Examples of mobile communication devices include mobile phones (e.g., cellular phones), PDAs, tablet computers, net books, laptop computers, wearable devices (e.g., watches), vehicles such as automobiles and motorcycles, personal music players, hand-held specialized readers, etc. A mobile communication device may comprise any suitable hardware and software for performing such functions, and may also include multiple devices or components (e.g., when a device has remote access to a network by tethering to another device—i.e., using the other device as a modem—both devices taken together may be considered a single mobile communication device).
A “user” may include an individual. In some embodiments, a user may be associated with one or more personal accounts and/or user devices.
A “credential” may be any suitable information that serves as reliable evidence of worth, ownership, identity, or authority. A credential may be a string of numbers, letters, or any other suitable characters that may be present or contained in any object or document that can serve as confirmation.
A “value credential” may be information associated with worth. Examples of value credentials include payment credentials, coupon identifiers, information needed to obtain a promotional offer, etc.
“Payment credentials” may include any suitable information associated with an account (e.g., a payment account and/or payment device associated with the account). Such information may be directly related to the account or may be derived from information related to the account. Examples of account information may include a PAN (primary account number or “account number”), username, expiration date, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification values, etc. CVV2 is generally understood to be a static verification value associated with a payment device. CVV2 values are generally visible to a user (e.g., a consumer), whereas CVV and dCVV values are typically embedded in memory or authorization request messages and are not readily known to the user (although they are known to the issuer and payment processors). Payment credentials may be any information that identifies or is associated with a payment account. Payment credentials may be provided in order to make a payment from a payment account. Payment credentials can also include a username, an expiration date, a gift card number or code, and any other suitable information.
A “token” may be a substitute value for a credential. A token may be a string of numbers, letters, or any other suitable characters. Examples of tokens include access tokens such as payment tokens, data that can be used to access secure systems or locations, etc.
A “payment token” may include an identifier for a payment account that is a substitute for an account identifier, such as a primary account number (PAN) and/or an expiration date. For example, a token may include a series of alphanumeric characters that may be used as a substitute for an original account identifier. For example, a token “4900 0000 0000 0001” may be used in place of a PAN “4147 0900 0000 1234.” In some embodiments, a token may be “format preserving” and may have a numeric format that conforms to the account identifiers used in existing transaction processing networks (e.g., ISO 8583 financial transaction message format). In some embodiments, a token may be used in place of a PAN to initiate, authorize, settle or resolve a payment transaction or represent the original credential in other systems where the original credential would typically be provided. In some embodiments, a token value may be generated such that the recovery of the original PAN or other account identifier from the token value may not be computationally derived. Further, in some embodiments, the token format may be configured to allow the entity receiving the token to identify it as a token and recognize the entity that issued the token.
“Tokenization” is a process by which sensitive data is replaced with substitute data. For example, a real credential (e.g., a primary account number (PAN)) may be tokenized by replacing the real account identifier with a substitute number that may be associated with the real credential. Further, tokenization can be applied to any other information to substitute the underlying information with a token. “Token exchange” or “de-tokenization” can be a process of restoring the data that was substituted during tokenization. For example, a token exchange may include replacing a payment token with its associated primary account number (PAN). Further, de-tokenization or token exchange may be applied to any other information to retrieve the substituted information from a token. In some embodiments, token exchange can be achieved via a transactional message, such as an ISO message, an application programming interface (API), or another type of web interface (e.g., web request).
A “token service computer” can include a system that that services tokens. In some embodiments, a token service computer can facilitate requesting, determining (e.g., generating) and/or issuing tokens, as well as maintaining an established mapping of tokens to primary account numbers (PANs) in a repository (e.g., token vault). In some embodiments, the token service computer may establish a token assurance level for a given token to indicate the confidence level of the token to PAN binding. The token service computer may include or be in communication with a token vault where the generated tokens are stored. The token service computer may support token processing of payment transactions submitted using tokens by de-tokenizing the token to obtain the actual PAN.
A “token domain” may indicate an area and/or circumstance in which a token can be used. Examples of the token domain may include, but are not limited to, payment channels (e.g., e-commerce, physical point of sale, etc.), POS entry modes (e.g., contactless, magnetic stripe, etc.), and merchant identifiers to uniquely identify where the token can be used. A set of parameters (i.e., token domain restriction controls) may be established as part of token issuance by the token service computer that may allow for enforcing appropriate usage of the token in payment transactions. For example, the token domain restriction controls may restrict the use of the token with particular presentment modes, such as contactless or e-commerce presentment modes. In some embodiments, the token domain restriction controls may restrict the use of the token at a particular merchant that can be uniquely identified. Some exemplary token domain restriction controls may require the verification of the presence of a token cryptogram that is unique to a given transaction. In some embodiments, a token domain can be associated with a token requestor.
“Token expiry date” may refer to the expiration date/time of the token. The token expiry date may be passed among the entities of the tokenization ecosystem during transaction processing to ensure interoperability. The token expiration date may be a numeric value (e.g., a 4-digit numeric value). In some embodiments, the token expiry date can be expressed as a time duration as measured from the time of issuance.
A “token request message” may be an electronic message for requesting a token. A token request message may include information usable for identifying a payment account or digital wallet, and/or information for generating a payment token. For example, a token request message may include payment credentials, mobile communication device identification information (e.g., a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a cryptogram, and/or any other suitable information. Information included in a token request message can be encrypted (e.g., with an issuer-specific key). In some embodiments, the token request message may include a flag or other indicator specifying that the message is a token request message.
A “token response message” may be a message that responds to a token request. A token response message may include an indication that a token request was approved or denied. A token response message may also include a payment token, mobile communication device identification information (e.g., a phone number or MSISDN), a digital wallet identifier, information identifying a tokenization service provider, a merchant identifier, a cryptogram, and/or any other suitable information. Information included in a token response message can be encrypted (e.g., with an issuer-specific key). In some embodiments, the token response message may include a flag or other indicator specifying that the message is a token response message.
An “authorization request message” may be a message that requests permission to conduct an interaction. For example, an authorization request message may include an electronic message that is sent to a payment processing network and/or an issuer of a payment card to request authorization for a transaction. An authorization request message according to some embodiments may comply with (International Organization of Standardization) 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. The authorization request message may include an issuer account identifier that may be associated with a payment device or payment account. An authorization request message may also comprise additional data elements corresponding to “identification information” including, by way of example only: a service code, a CVV (card verification value), a dCVV (dynamic card verification value), an expiration date, etc. An authorization request message may also comprise “transaction information,” such as any information associated with a current transaction, such as the transaction amount, merchant identifier, merchant location, etc., as well as any other information that may be utilized in determining whether to identify and/or authorize a transaction.
An “authorization response message” may be an electronic message reply to an authorization request message. In some embodiments, it may be generated by an issuing financial institution or a payment processing network. The authorization response message may include, by way of example only, one or more of the following status indicators: Approval—transaction was approved; Decline—transaction was not approved; or Call Center—response pending more information, merchant must call the toll-free authorization phone number. The authorization response message may also include an authorization code, which may be a code that a credit card issuing bank returns in response to an authorization request message in an electronic message (either directly or through the payment processing network) to the merchant's access device (e.g., POS equipment) that indicates approval of the transaction. The code may serve as proof of authorization. As noted above, in some embodiments, a payment processing network may generate or forward the authorization response message to the merchant.
A “server computer” may include a powerful computer or cluster of computers. For example, the server computer can be a large mainframe, a minicomputer cluster, or a group of servers functioning as a unit. In one example, the server computer may be a database server coupled to a Web server. The server computer may comprise one or more computational apparatuses and may use any of a variety of computing structures, arrangements, and compilations for servicing the requests from one or more client computers. A server computer can be a cloud computer.
Current tokenization models require tokens to be created and activated before the first use of the token. When creating and activating a token in existing systems, there can be at least three interactions (via API calls) between a token service system and authorizing entity computer (e.g., an issuer computer). The first interaction can verify the token requestor's eligibility. The second interaction can verify the token activation request. The third interaction can involve relaying activated token details to the authorizing entity computer.
The current tokenization model that requires tokens to be created and activated before first use of the token is inefficient. In fact, a majority of card on file tokens are activated, but are never used by the token requestors that request them. In one example, a user may activate an account for a streaming service to take advantage of free trial period provided by the streaming service. To use the streaming service during the trial period, a payment card number is required to create an account. After the streaming service receives the payment card number, it can tokenize it for future use. However, if the user opts out of the streaming service after the trial period, then the token has been generated and activated, but it was never used to conduct a payment transaction.
In order to solve these problems, using embodiments of the invention, tokens such as card on file tokens can be created in a “pending” state, where token activation with authorizing entity computer is deferred until the time that the tokens are used for authorizing transactions. This reduces the number of interactions between a token service computer and an authorizing entity computer relative to conventional systems. It also only activates tokens if they are used to conduct transactions. Tokens that are not activated within a certain period of time can be reused or reissued, thereby addressing the problems regarding the proliferation of tokens.
Each of the entities in
In a method that can be described with respect to
In step S102, the token requestor computer 104 can transmit a token request message to obtain a token in response to a user's desire to interact with the token requestor computer 104. The token requestor computer 104 can be a resource provider computer, a user device such as a mobile phone, or any other suitable device that requests a token.
The token request message can comprise information such as a credential (e.g., primary account number), a CVV2, an expiration date, etc. to the token service computer 106. The token requestor computer 104 may have received the payment information from a user wishing to obtain a resource (e.g., streaming service) provided by the token requestor computer 104. In some cases, the user may not need to initiate a payment transaction to access the resource provided by the token requestor computer 104, but still provide the payment information to the token requestor computer 104 to access the resource. For example, the user may provide its payment information to the token requestor computer 104 to access streaming content provided by the token requestor computer 104 during a free trial period.
In step S104, upon receiving the request to obtain a token, the token service computer 106 can provide the token request message to the processing network computer 108.
In step S106, the processing network computer 108 can transmit the token request message to the token vault computer 110. The token vault computer 110, upon receiving the token request message, can obtain a token. For example, the token can be mathematically derived from the credential or it may be retrieved from a database and assigned to the credential. The token can be a substitute for the credential, and the token and the credential can have a same format (e.g., 16 digit primary account number). The token vault computer 110 may store the token in a pending state until the token is activated by the token vault computer 110.
In step S107A, the token vault computer 110, upon obtaining the token, can transmit the token to the token service computer 106. In some embodiments, the token vault computer 110 may transmit the token to the processing network computer 108 before transmitting it to the token service computer 106. In some other embodiments, the token vault computer 110 can transmit both the credential and the token to the token service computer 106.
In step S107B, the token service computer 106 can provide the token to the token requestor computer 104. At this time, the token is still in the pending state as it has not been yet activated. A token that is “pending” can be one that has been created, but cannot be used in a transaction authorization process. A token that is “activated” can be one that can be used in a transaction authorization process.
In step S107C, the user may perform a transaction to obtain access to the resource. The resource can be a recurring resource. For example, after an initial free trial period for a streaming service, the user may decide to keep access the streaming service by paying a monthly fee. The token requestor computer 104, upon the user deciding to perform the transaction, can transmit a request for a cryptogram to the token service computer 106. The request for a cryptogram can comprise the token and transaction data such as time, merchant information, transaction mode, category of the item, etc.
In step S107D, the token service computer 106, upon receiving the request for a cryptogram, can obtain a cryptogram. In some embodiments, the cryptogram can be generated by the token service computer 106. For example, the cryptogram can be derived from the credential associated with the token and/or the token, and the transaction data. For example, if the token requestor computer 104 performs an online transaction with the merchant 102, then a cryptogram that encodes (e.g., encrypts) an e-commerce transaction indicator, a resource provider identifier, dynamic information such as a time and date, and a token can be generated by the token service computer 106. The cryptogram can be used to validate that a token is being used in an authorized manner. For example, a cryptogram can encode an e-commerce transaction indicator. If a token that accompanies the cryptogram is used in a transaction that is not an e-commerce transaction, then that transaction may be declined since the token is not being using in an authorized manner.
In step S107E, the token service computer 106 can transmit the token and the cryptogram to the token vault computer 110 to store the cryptogram in the token vault computer 110. The token vault computer 110 can find a matching token stored in its database and store the cryptogram with the token.
In step S107F, the token service computer 106 can transmit the cryptogram back to the token requestor computer 104.
In step S108, the token requestor computer 104 can initiate the transaction by generating an authorization request message comprising the token (which is in a pending state) and the cryptogram to the processing network computer 108. Upon generating the authorization request message, the token requestor computer 104 can send the authorization request message to the processing network computer 108 for authorization of the transaction.
In steps S110 and S112, upon receiving the authorization request message comprising the token and the cryptogram, the processing network computer 108 can detokenize the token into the credential and validate the cryptogram through the token vault computer 110.
In step S110, the processing network computer 108 can transmit a detokenization request comprising the token and the cryptogram to the token vault computer 110. The token vault computer 110, upon receiving the detokenization request, can use the token to obtain a cryptogram associated with the token. In some embodiments, the cryptogram can be obtained from a database and validate the cryptogram by comparing it to the received cryptogram. Upon successful validation, the token vault computer 110 can detokenize the token to obtain the credential associated with the token. In some embodiments, the credential may be mathematically determined from the token. In other embodiments, the credential may be retrieved from a database which links credentials to tokens.
In step S112, the token vault computer 110 can transmit the credential associated with the token to the processing network computer 108. The processing network computer 108 can substitute the credential from the token in the authorization request message. Since the token is in the pending state and is not yet activated, the processing network computer 108 can communicate with the authorizing entity computer 112 to activate the token.
In step S114, the processing network computer 108 can transmit the authorization request message comprising the credential associated with the token in the pending state, token activation information, and optionally the token to the authorizing entity computer 112 for approval. The token activation information can comprise a token activation request and token details or advice information. In some embodiments, authorization request message may be an ISO message such as an ISO 8583 message.
In some embodiments, the authorizing entity computer 112, upon receiving the authorization request message comprising the credential associated with the token, token activation information, and optionally the token, has one of three options. The first option 114 approves the transaction and token activation request. The second option 116 declines the transaction but approves of the token activation request. The third option 118 declines both the transaction and the token activation request.
In step S116, the authorizing entity computer 112 can review the authorization request message and determine if the transaction is approved or not. The authorizing entity computer 112 can determine if there are sufficient funds in the account associated with the credential to conduct the transaction and/or perform any suitable number of fraud and security checks.
The authorizing entity computer 112 can then generate an authorization response message. The authorization response message can comprise the credential, an activation indicator approving of both the transaction and the token activation request, and optionally the token. The authorizing entity computer 112 can then transmit the authorization response message to the processing network computer 108.
In step S118, the processing network computer 108, upon receiving the authorization response message, can transmit a request to activate the token to the token vault computer 110. Token vault computer 110, upon receiving the request to activate the token, can activate the token to an active state in response to receiving the request to activate the token. The token vault computer 110 may change the token status to activated upon activating the token. The token vault computer 110 may store a flag along with the token, where the flat indicates that the token is activated.
In step S120, the authorizing entity computer 112 can review the authorization request message and generate an authorization response message. The authorization response message can comprise the credential, an activation indicator declining the transaction but approving the token activation request, and optionally the token. An example scenario may be that the user does not have any balance left in the account but the account has otherwise been in good standing, so the activation of the token can be approved. The authorizing entity computer 112 can transmit the authorization response message to the processing network computer 108.
In step S122, the processing network computer 108, upon receiving the authorization response message, can transmit a request to activate the token to the token vault computer 110. Token vault computer 110, upon receiving the request to activate the token, can activate the token to an active state in response to receiving the request to activate the token. The token vault computer 110 may change the token status to activated upon activating the token.
In step S124, the authorizing entity computer 112 can review the authorization request message and generate an authorization response message. The authorization response message can comprise the credential, an activation indicator declining both the transaction and the token activation request, and optionally the token. The authorizing entity computer 112 can transmit the authorization response message to the processing network computer 108.
In step S126, the processing network computer 108, upon receiving the authorization response message, can transmit a token deletion message to the token vault computer 110. Token vault computer 110, upon receiving the token deletion message, can delete the token in its database.
In step S128, the processing network computer 108 can transmit an authorization response message with the token and the activation indicator to the token requestor computer 104. The token requestor computer 104, by receiving the authorization response message, can be notified whether the transaction is approved or declined, and whether the token is activated or not.
In
Steps S202 to S207B can be similar to steps S102 to S107B. A user may provide payment information comprising credential (e.g., primary account number), CVV2, etc. to the token requestor computer 104 to access a resource (e.g., streaming service). Although the user may have provided the payment information, the user may not need to perform a transaction yet to access the resource. For example, the user may provide its payment information to the token requestor computer 104 to access a free trial period for a streaming service. The token requestor computer 104 can send token request message to the token service computer 106. The token service computer 106 can then provide the token request message to the token vault computer 110. The token vault computer 110 can obtain a token, store the token in a pending state, and send the token back to the token requestor computer 104.
In step S208, the user can initiate the transaction to obtaining access to a resource. The resource can be a recurring resource that requires a recurring payment to continue. For example, the recurring resource can be video content provided by a streaming service. After an initial free trial period for the streaming service, the user may decide to keep accessing the content provided by the streaming service by paying a monthly fee. The initiation of the transaction can include the token requestor computer 104 transmitting a request for a cryptogram for the transaction using the token to the token service computer 106. The request for the cryptogram can comprise the token and transaction data such as time, merchant information, category of the item, etc., to the token service computer 106.
In step S210A, after receiving the token cryptogram request, the token service computer 106 can look up a status of the token. The token service computer 106 can look up the token status by transmitting a request for the token status to the token vault computer 110. The token vault computer 110, upon receiving the request for the token status, can find the token status of the token.
In step S210B, the token vault computer 110 can transmit the token status of the token to the token service computer 106. The token vault computer 110 can additionally transmit the corresponding credential of the token. The token vault computer 110 may determine that the token is in a pending state or is in an active state. If the token is in the pending state, the token service computer 106 can proceed with activating the token in step S212. If the token is already activated, the token service computer can proceed to step S222.
In step S212, the token service computer 106 can transmit a request for approval to activate the token to an authorizing entity computer 112. The request can comprise comprising the credential and the token, and can be in a data format (e.g., HTTP/HTTPS) that is different than an authorization request message (e.g., an ISO 8583). The authorizing entity computer 112, upon receiving the request to activate the token, can review the token activation request. In some embodiments, the authorizing entity computer 112 may have two options. The first option 214 is to approve the token activation request. The second option 216 is to decline the token activation request.
In step S214, the token service computer 106 can receive a response with an approval to activate the token from the authorizing entity computer 112. For example, the authorizing entity computer 112 may determine that the account associated with the credential associated with the token has a sufficient balance and/or that the credential is otherwise in good standing. The authorizing entity computer 112 can then send a response with approval to activate the token.
In step S216, the token service computer 106 can transmit the details or advice of the token to the authorizing entity computer 112. The details or advice can include details about the token activation including the time and date of activation, the token that was activated, the credential that corresponds to the token, and a digital signature of the token service computer 106.
In steps S218 and S220, a request to activate the token can be sent from the token service computer 106 to the processing network computer 108, and from the processing network computer 108 to the token vault computer 110.
In step S220, the token vault computer 110, upon receiving the request to activate the token, can activate the token in response to receiving the request to activate the token. The token vault computer 110 may change the token status to activated upon activating the token.
In step S221, upon activating the token, the token vault computer 110 may notify the token service computer 106 that the token is now activated.
In step S222, upon receiving the notification that the token is now activated, the token service computer 106 can generate a cryptogram. The cryptogram can be derived from the credential associated with the token and/or the token, and the transaction data. For example, if the token requestor computer 104 performs an online transaction with the merchant 102, then a cryptogram that encodes an E-commerce transaction indicator, the token, the transaction amount, and a resource provider computer identifier, can be generated by the token service computer 106.
In step S223A, upon generating the cryptogram, the token service computer 106 can send the token and the cryptogram to the token vault computer 110. The token vault computer 110 can find a matching token stored in its database and store the cryptogram with the token.
In step S224, the token service computer 106 can send the cryptogram back to the token requestor computer 104.
In step S225A, upon receiving the cryptogram, the token requestor computer 104 can transmit an authorization request message comprising the token, the cryptogram, and a transaction amount to the processing network computer 108. The processing network computer 108 can detokenize the token to obtain the credential associated with the token and validate the token cryptogram by communicating with the token vault computer 110 (steps not shown but similar to steps S110 and S112 of
In step S225B, upon a successful validation of the token cryptogram, the processing network computer 108 can transmit the authorization request message comprising the credential, the transaction amount, and optionally the token to the authorizing entity computer 112. In step S225C, the authorizing entity computer 112 can send an authorization response message to the processing network computer 108 that approves or declines the transaction. In step S225D, the processing network computer 108 sends the authorization response message to the token requestor computer 104.
In step S226, the token service computer 106 can receive a response with declining to activate the token from the authorizing entity computer. For example, the authorizing entity computer 112 may determine that the account associated with the credential associated with the token does not a sufficient balance and/or raises other issues of concern, and can decline the token activation request.
In step S228, upon receiving the response including the indication that token activation is declined, the token service computer 106 can send a request to delete the token to the processing network computer 108.
In step S230, the processing network computer 108 can send the request to delete the token to the token vault computer 110. The token vault computer 110, upon receiving the request to delete the token, can delete the provisioned token.
In step S230, the token service computer 106 can send an error message of token being deleted to the token requestor computer 104. Since the token is deleted, the transaction therefore may be declined, and the authorization steps may not proceed.
The network interface 308 may include an interface that can allow the token service computer 300 to communicate with external computers. The network interface 308 may enable the token service computer 300 to communicate data to and from another device (e.g., a card, an item provider computer, etc.). Some examples of the network interface 308 may include a modem, a physical network interface (such as an Ethernet card or other Network Interface Card (NIC)), a virtual network interface, a communications port, a Personal Computer Memory Card International Association (PCMCIA) slot and card, or the like. The wireless protocols enabled by the network interface 308 may include Wi-Fi™. Data transferred via the network interface 308 may be in the form of signals which may be electrical, electromagnetic, optical, or any other signal capable of being received by the external communications interface (collectively referred to as “electronic signals” or “electronic messages”). These electronic messages that may comprise data or instructions may be provided between the network interface 308 and other devices via a communications path or channel. As noted above, any suitable communication path or channel may be used such as, for instance, a wire or cable, fiber optics, a telephone line, a cellular link, a radio frequency (RF) link, a WAN or LAN network, the Internet, or any other suitable medium.
The computer readable medium 304 may comprise a number of software modules including a cryptogram generation module 304A, a token status module 304B, and a token decision module 304C.
The cryptogram generation module 304A may comprise code that can cause the processor 302 to generate a cryptogram 306B upon receiving a request for a cryptogram or after receiving a notification of a token 306A in transaction being activated. The cryptogram can be generated by using the token 306A and transaction data 306C. The token status module 304B and the processor 302 may identify a status of the token 306A. The token status module 304B and the processor 302 can identify the status of the token 306A by generating a request for the token status and transmitting the request for the token status to the token vault computer 500. The token service computer 300 can then receive a response with the status of the token back from the token vault computer 500. The token decision module 304C may comprise code that can cause the processor 302 to either send a request to activate the token or delete the token to a processing network computer 400. The token decision module 304C can base its decision on whether a response it receives from an authorizing entity computer is an approval to activate the token or declining to activate the token.
The computer readable medium 304 can also comprise code, executable by the processor 302, for performing operations comprising: receiving, from a token requestor computer, a request to obtain a token; and providing, a token request message to a token vault computer, wherein the token vault computer obtains the token, and receives a request to activate the token after the token is used to initiate a transaction.
The database 306 may comprise tokens 306A, cryptograms 306B, and the transaction data 306C. Tokens and cryptograms are described above. The transaction data 306C can be data used in the transaction. The transaction data 306C can comprise time of the transaction, merchant information, category of the item in the transaction, etc. The transaction data 306C may be received from a token requestor computer 600.
The network interface 408 may include an interface that has similar or different characteristics as the network interface 308 in
The computer readable medium 404 may comprise a number of software modules including a detokenization request module 404A, an authorization module 404B, and an activation request module 404C.
The detokenization request module 404A may comprise code that can cause the processor 402 to generate a request to detokenize a token 406A and transmit the request to a token vault computer 500. The request can comprise at least the token 406A and a cryptogram 406B. The processing network computer 400 may then obtain a credential 406C associated with the token 406A from the token vault computer. The authorization module 404B and the processor 402 can process authorization requests and responses. The activation request module 404C may comprise code that can cause the processor 402 to either send a request to activate the token or delete the token to the token vault computer 500.
The database 406 may comprise tokens 406A, cryptograms 406B associated with the tokens 406A, and credentials 406C associated with the tokens 406A, as well as other information.
The network interface 508 may include an interface that has similar or different characteristics as the network interface 308 in
The computer readable medium 504 may comprise a number of software modules including a token generation module 504A, a detokenization module 504B, a token activation module 504C, a cryptogram validation module 504D, and a token status module 504E.
The token generation module 504A may comprise code that can cause the processor 502 to generate a token 506A using payment information including a credential 506D of a user. The token generation module 504A can obtain the token 506A and store the token 506A and the credential associated with the token in the database 506. The detokenization module 504B and the processor 502 can validate the cryptogram by comparing a received cryptogram with the cryptogram 506C in the database 506. Upon successful validation, the detokenization module 504B can detokenize the token in the detokenization request. It can do so by matching the received token with the token 506A in the database 506, and the obtaining the credential 506D associated with the token 506A. The token activation module 504C may comprise code that can cause the processor 502 to either activate the token or delete the token. The token status module 504E can comprise code that can cause the processor 502 to check on the token status of the token 506A.
The database 506 may comprise tokens 506A, token statuses 506B (e.g., activated, pending, inactive), cryptograms 506C, and credentials 506D.
The network interface 608 may include an interface that has similar or different characteristics as the network interface 308 in
The computer readable medium 604 may comprise a number of software modules including an authorization request module 604A, a token request module 604B, and a cryptogram request module 604C.
The authorization request module 604A can comprise code executable by the processor 602 to cause the token requestor computer 600 to generate and transmit authorization request messages, and receive and process authorization response messages. The token request module 604B may comprise code that can cause the processor 602 to generate a request to obtain a token 606A. The request may include payment information. The cryptogram request module 604C may comprise code that can cause the processor 602 to generate a request for a cryptogram 606B. The cryptogram request module 604C may comprise code that can cause the processor 602 to request cryptograms associated with tokens.
The database 606 may comprise tokens 606A and cryptograms 606B, and metadata thereof.
Embodiments of the invention have number of advantages. One advantage of the embodiment is that the token activation is deferred to authorization time. By doing this, the interaction between the token service system and the authorizing entity computer is deferred until the first authorization request message. Tokens are only activated when they are used, this reducing the need to create and/or maintain unnecessary tokens. Further, the number of messages needed to activate tokens is reduced relative to conventional systems.
Any of the software components or functions described in this application may be implemented as software code to be executed by a processor using any suitable computer language such as, for example, Java, C, C++, C #, Objective-C, Swift, or scripting language such as Perl or Python using, for example, conventional or object-oriented techniques. The software code may be stored as a series of instructions or commands on a computer readable medium for storage and/or transmission, suitable media include random access memory (RAM), a read only memory (ROM), a magnetic medium such as a hard-drive or a floppy disk, or an optical medium such as a compact disk (CD) or DVD (digital versatile disk), flash memory, and the like. The computer readable medium may be any combination of such storage or transmission devices.
Such programs may also be encoded and transmitted using carrier signals adapted for transmission via wired, optical, and/or wireless networks conforming to a variety of protocols, including the Internet. As such, a computer readable medium according to an embodiment of the present invention may be created using a data signal encoded with such programs. Computer readable media encoded with the program code may be packaged with a compatible device or provided separately from other devices (e.g., via Internet download). Any such computer readable medium may reside on or within a single computer product (e.g., a hard drive, a CD, or an entire computer system), and may be present on or within different computer products within a system or network. A computer system may include a monitor, printer, or other suitable display for providing any of the results mentioned herein to a user.
The above description is illustrative and is not restrictive. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.
One or more features from any embodiment may be combined with one or more features of any other embodiment without departing from the scope of the invention.
As used herein, the use of “a,” “an,” or “the” is intended to mean “at least one,” unless specifically indicated to the contrary.
This application claims the benefit of U.S. Provisional Application No. 63/319,219, filed Mar. 11, 2022, which is herein incorporated by reference in its entirety for all purposes.
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/US2023/063984 | 3/8/2023 | WO |
| Number | Date | Country | |
|---|---|---|---|
| 63319219 | Mar 2022 | US |
