US10915899B2 - Replacing token on a multi-token user device - Google Patents

Abstract

Embodiments of the invention are directed to methods, systems, and devices for replacing a token on a user device, such as a transaction card. The transaction card includes tokens representing an actual account identifier which is not visible on the transaction card. The transaction card may store a first token on a and include a digital display that displays a second token. When the first token or the second token is compromised, the compromised token is replaced without replacing the transaction card. When the second token is compromised, the compromised token is replaced with a new replacement second token using an electronic device. The replacement second token replaces the old second token on the digital display. After the second token is compromised and before the replacement second token is provisioned on the transaction card, the transaction card may still be used for transactions using other tokens provisioned on the card.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

None.

BACKGROUND

A transaction card is a physical device associated with an account of an account holder. Exemplary transaction cards may include payment cards (e.g. a debit card, a credit card or a prepaid card), identification cards, access cards (e.g. a building access card) and the like. The transaction card may enable the account holder present account information embedded in the transaction card to a third party entity. For example, the transaction card may be used to conduct a transaction (e.g. a payment transaction) at a merchant.

Often, the transaction card will have the account identifier associated with the account embossed (or otherwise printed) on the card. Therefore, a fraudulent party may get a hold of the account identifier simply by looking at the transaction card. Thus, even when the account holder may be in possession of the transaction card, the account identifier may be stolen and used to conduct fraudulent transactions. When the fraudulent party uses the account identifier to commit fraud or when the account identifier is otherwise compromised, the transaction card must be destroyed by the account holder and a new (e.g. replacement) transaction card is provided to the account holder within a predetermined amount of time (e.g. few days or a week). However, until the card is replaced, the account holder does not have access to the account or cannot use the transaction card to conduct any transactions. Sometimes, the account is blocked for further use before the account holder receives the replacement transaction card and activates the card by contacting the issuer of the account to confirm that the account holder is in possession of the replacement card.

In addition to the burden placed on the account holder (e.g. not being able to use the account and/or the transaction card for a period of time), replacing transaction cards has a production cost and an environmental cost (e.g. more plastic material being used to generate replacement cards along with any additional material such as material used for smart chips) associated therewith.

According to another conventional use of account identifiers, some transacting entities store the account holder information (e.g. account holder's account identifier) on file to conduct faster and more efficient transactions. However, storing actual account identifiers pose a security threat and is susceptible to information theft. In order to protect account holder information, some companies prefer to store tokens instead of account identifiers. Such companies interact with the transaction processing entities and/or issuer entities that issued the account identifiers to obtain tokens representing the actual account identifiers. Current systems do not allow the account holders to provide tokens to be stored on file by transacting entities.

Embodiments of the invention address this and other problems, individually and collectively.

BRIEF SUMMARY

Embodiments provide a user device (such as a transaction card) including one or more tokens representing an actual account identifier associated with an account of an account holder. According to various embodiments, the account identifier is not visible on the transaction card. For example, in some embodiments, the actual account number may be stored on a contact, contactless or dual-interface chip of the transaction card. In yet other embodiments, the actual account number may not be stored or otherwise provided on the transaction card. Thus, in some embodiments, the holder of the transaction card may not learn the account identifier by simply being in possession of the transaction card.

The transaction card may store the account identifier or a first token representing the account identifier on the contact, contactless or dual-interface chip coupled to the transaction card. The transaction card may include a digital display that displays a second token representing the account identifier. The second token representing the account identifier may be provided on the transaction card using electronic ink. Thus, when the holder of the transaction card (e.g. the account holder, the user) needs to provide account information to a resource provider, the holder may not have access to the account identifier and may provide the second token instead. If the second token is compromised, the second token may be replaced without replacing the transaction card. The transaction card may store additional tokens representing the account identifier. For example, a third token may be stored at a magnetic stripe coupled to the transaction card.

When the second token is compromised, a replacement (e.g. new) second token may be pushed to the transaction card. The replacement second token may replace the old second token on the digital display. After the second token is compromised and before the replacement second token is provisioned on the transaction card, the transaction card may still be used for transactions using other tokens provisioned on the transaction card (e.g. the first token or the account identifier stored on the contact, contactless or dual-interface chip of the transaction card).

According to various embodiment, an expired, stolen or compromised token on the transaction card may be replaced with a replacement token using an electronic device such as a resource provider terminal (e.g. a point of sale terminal (POS)), a communication device (e.g. a mobile phone) or an authorizing computer terminal (e.g. an automated teller machine (ATM) of an issuer). The authorizing computer may send the replacement token to the electronic device using a message, for example an authorization response message, an over-the-air message via cellular communication network, or a system update message.

Embodiments of the invention are directed to methods, systems, and devices for replacing a token on a transaction card. The method, performed by a server computer, includes transmitting a tokenization request message to a token service provider system. The tokenization request message includes an account identifier representing an account. The method also includes receiving, from the token service provider system, a plurality of tokens corresponding to the account identifier. The method includes provisioning the plurality of tokens on a user device. Each token is associated with a different communication channel between the user device and a token recipient device. The method further includes deactivating at least one token among the plurality of tokens when the at least one token is compromised, and transmitting a replacement token to an electronic device such that the at least one token on the user device is replaced with the replacement token when the user device is in communication with the electronic device.

Embodiments of the invention may provide a user device comprising a substrate and a dynamic display provided on the substrate displaying a first token representing an account identifier associated with an account. The user device may also include a data storage unit coupled to the substrate storing a second token representing the account identifier, the second token being different from the first token. According to some embodiments, when the user device is in communication with an electronic device, the first token displayed on the dynamic display is replaced with a replacement token representing the account identifier. The first token and the replacement token may be restricted in use based on a type of communication between the user device a token-recipient device. In some embodiments, the plurality of tokens are provisioned on the user device instead of the account identifier. The user device may also include a data storage unit coupled to the substrate storing the account identifier such that the account identifier is invisible on the user device. In some embodiments, the user device may be a transaction card.

Embodiments of the invention may provide methods, systems, and devices for replacing a token on a transaction card. The method, performed by a server computer, includes receiving a tokenization request message from an authorizing computer. The tokenization request message includes an account identifier associated with an account. The method may also include generating a first token and a second token associated with the account identifier and storing the first token, the second token, and a mapping between the first token, the second token and the account identifier at a storage. The method may further include transmitting the first token and the second token to the authorizing computer. The server computer may receive, from a resource provider computer, a processing request including the first token. The server computer may determine that the first token has been compromised or expired, and generate a replacement token associated with the account identifier to replace the first token. The server computer may transmit an authorization response message to the resource provider computer. The authorization response message includes a replacement token that replaces the first token on a user device in communication with the resource provider computer.

These and other embodiments of the invention are described in further detail below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a block diagram of an exemplary transaction card according to an embodiment of the invention.

FIG. 2 shows a block diagram of a processing network according to an embodiment of the invention.

FIG. 3 shows a swim-lane diagram of a tokenized transaction card generation according to an embodiment of the invention.

FIG. 4 shows a block diagram of a system for processing a transaction according to an embodiment of the invention.

FIG. 5 shows a swim-lane diagram of updating a token on a tokenized transaction card at an access device according to an embodiment of the invention.

FIG. 6 shows a swim-lane diagram of updating a token on a tokenized transaction card using an electronic device according to an embodiment of the invention.

DETAILED DESCRIPTION

Prior to discussing the details of some embodiments of the present invention, description of some terms may be helpful in understanding the various embodiments.

A “server computer” may typically be 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, a server computer may be a database server coupled to a Web server. Data transfer and other communications between components such as computers may occur via any suitable wired or wireless network, such as the Internet or private networks. The server computer may be associated with an entity such as a resource provider, a database (e.g. an information database, an application database, an entertainment database), an transaction processing entity or an authorizing entity.

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 CPU comprises 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.

An “account holder” may hold an account. An “account holder” may include an individual or an entity that uses a system. An account holder may be associated with one or more accounts and/or user devices. In some cases, the account holder may also be referred to as a user or a consumer.

An “authorizing entity” (e.g. an issuer) 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 authorization 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. The account (which may be associated with one or more user devices) may refer to any suitable account including payment accounts (e.g. a credit card account, a checking account, a savings account, a merchant account assigned to a consumer, a prepaid account, etc.), an employment account, an online account (e.g. email account, database subscription account, etc.).

A “user device” may include any suitable device that may be used to conduct a financial transaction, such as to provide payment credentials to a merchant. Suitable payment devices can be hand-held and compact so that they can fit into a user's wallet and/or pocket (e.g., pocket-sized). Example payment devices may include smart cards, keychain devices (such as the Speedpass™ commercially available from Exxon-Mobil Corp.), etc. Other examples of user devices include transaction cards, payment cards, smart media, transponders, objects that are connected via a network (i.e. internet of things (IoT) connected devices), and the like. If the payment device is in the form of a debit, credit, or smartcard, the payment device may also optionally have features such as magnetic stripes. Such devices can operate in either a contact or contactless mode.

A “resource provider” may be an entity that can provide a resource such as goods, services, information, and/or access. Examples of resource providers includes merchants, data providers, transit agencies, governmental entities, venue and dwelling operators, etc.

A “resource provider computer” may be a computer operated by a resource provider. Suitable computers may include access devices, back end server computers, as well as combinations of the above.

An “access device” may be any suitable device for providing access to an external computer system. An access device may be in any suitable form. Some examples of access devices include point of sale (POS) devices, 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), kiosks, security systems, access systems, Websites, 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 portable communication device. In some embodiments, where an access device may comprise a POS terminal, any suitable POS terminal may be used and 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 card readers can include radio frequency (RF) antennas, optical scanners, bar code readers, or magnetic stripe readers to interact with a portable communication device. The POS terminal may also be referred as a “request processing device”. The access device may be include IoT connected device(s).

An “authorization request message” may be an electronic message that is sent to request authorization for a transaction. The authorization request message can be sent to a payment processing network and/or an issuer of a payment card. An authorization request message according to some embodiments may comply with ISO 8583, which is a standard for systems that exchange electronic transaction information associated with a payment made by a user using a payment device or payment account. Other standard message formats may include ISO 20022 as well as block chain message format. The authorization request message may include information that can be used to identify an account. An authorization request message may also comprise additional data elements such as one or more of a service code, 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. In addition, an authorization request message may further comprise open data fields, in which additional values may be requested and stored. The authorization request message may also include other information such as information that identifies the access device that generated the authorization request message, information about the location of the access device, etc.

An “authorization response message” may be an electronic message reply to an authorization request message. The authorization response message can 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 computer that indicates approval of the transaction. The code may serve as proof of authorization.

An “account identifier” may include any suitable information associated with an account of a user which identifies the account. Such information may be directly related to the account or may be derived from information related to the account. For example, an account identifier may include an account number, an employment identification number, a virtual account identifier, a primary account number (PAN), a token, a service code, a CVV (card verification value), a dCVV (dynamic card verification value), CVV2 (Card Verification Value 2), CVC3 card verification values, an expiration date, 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). The PAN may be a variable length, (e.g. 13 to 19-digit) industry standard-compliant account number that is generated within account ranges associated with a Bank Identification Number (BIN) by an issuer.

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 payment tokens, access tokens, personal identification tokens, etc. A payment token may include an identifier for an account that is a substitute for account data, such as an account number. 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 network computers. In some embodiments, a token may be used in place of an account number to initiate, authorize, settle or resolve a 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 account number 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.

Embodiments of the invention provision tokens on a user device, such as a transaction card. Any type of user device such as a mobile communication device or a key fob may be used in connection with the embodiments of the present invention. Even though a transaction card is used as an exemplary user device in the following description, the use of the transaction card is for illustration purposes and should not be construed as limiting.

The transaction card can be issued with at least two tokens: a first token and a second token. A first token may be provisioned on a contact, contactless or dual interface chip. The first token may be restricted to in-person transaction channels such as terminal entry modes for contact, contactless or magnetic stripe transactions. In some embodiments, a different token may be issued and domain restricted to magnetic stripe transactions where chip card based cryptograms are not required for the transaction. A magnetic stripe transaction may be configured to work only in situations where a chip transaction is not supported. A second token (different from the first token) may be issued and displayed on the transaction card. In some embodiments, the second token may be dynamically displayed on the transaction card. For example, the second token may be displayed using a digital display. In some embodiments, the second token may be printed on a replaceable element coupled to the transaction card (e.g. a label or a sticker). The second token may be domain restricted to remote or e-commerce transactions (including key entered transactions).

According to various embodiments, if the second token is compromised, the transaction card may still be used to conduct transactions using the first token. In embodiments where the second token is digitally displayed on the card, the second token, if compromised, may be renewed or replaced with a replacement second token without having to replace the transaction card. The second token and the replacement second token are domain restricted to the same transaction type. That is, the second token and the replacement second token are restricted to the same communication channel between the transaction card and a token recipient device.

In some embodiments, only tokens are provisioned on the transaction card, without provisioning the actual account identifier corresponding to the tokens. In other embodiments, the account identifier (e.g. a primary account number (PAN)) may be provisioned or otherwise stored on the contact, contactless or dual interface chip. Accordingly, the account identifier may not be visible on the transaction card.

FIG. 1 illustrates atransaction card100 according to various embodiments. Thetransaction card100 may include a payment card such as a debit card, a credit card or a prepaid card; an identification card; an access card such as a building access card, and the like.

In some embodiments, thetransaction card100 may be a “smart card” or similar device, such as a credit or debit type card in which a chip is embedded. One form of such a device is known as an EMV (Europay™, MasterCard™, and Visa™) card. In the context of the present invention, EMV refers to a standard for interoperation of integrated circuit (IC) cards (“chip cards”) and IC card capable POS terminals and ATMs, and is used for authenticating credit and debit card payments. The EMV standard defines the interactions at the physical, electrical, data and application levels between IC cards and IC card processing devices for use in financial transactions.

Thetransaction card100 may display or store information associated with an account and a holder of the account (i.e. the owner of the transaction card100). According to various embodiments, a user or a holder of thetransaction card100 may present thetransaction card100 or information stored on thetransaction card100 to a resource provider or a resource provider computer operated by the resource provider to obtain or use the resources provided by the resource provider. For example, if thetransaction card100 is a payment card, thetransaction card100 may be presented at a terminal (e.g. point of sale terminal) of the resource provider (e.g. a merchant) to conduct a transaction with the resource provider. In some embodiments, the user may enter the credentials (e.g. a token representing an account identifier) provided on the face of thetransaction card100 to a computer operated by the resource provider. According to another example, thetransaction card100 may electronically communicate with the terminal of the resource provide to transmit credentials that are invisibly stored on thetransaction card100.

Thetransaction card100 may include asubstrate102. An account holder information such as theaccount holder name106 or a token representing an account identifier may be embossed or otherwise printed on thesubstrate102. Thetransaction card100 may also include aninterface104 such as a contact interface, a contactless interface or a dual-purpose interface (e.g. a dual-interface chip that may be accessed through contact and contactless interfaces) coupled to thesubstrate102. Theinterface104 may include amemory unit112 that stores afirst token114 representing the account identifier and/or, in some embodiments, the account identifier (e.g. an account number or a primary account number (PAN))115 associated with the account. When the user places thetransaction card100 in contact with or in proximity of a terminal (e.g. point of sale terminal), theinterface104 may transmit the first token to the terminal (or the terminal may retrieve the first token from the interface104).

Adigital display108 such as an electronic paper display (EPD or e-paper), a light emitting diode (LED) display, a liquid crystal display (LCD), an organic light emitting diode (OLED) display, etc. may be coupled to thesubstrate102. Thedigital display108 may dynamically display asecond token110 representative of the account. The second token dynamically displayed on thedigital display108 may be changed or updated without replacing thetransaction card100, as discussed below in greater detail.

Thetransaction card102 may include additional elements (e.g. a second memory and/or a magnetic stripe) to store and/or displayadditional transaction tokens116 associated with the account.

FIG. 2 illustrates anexemplary processing network210 according to various embodiments. For example the processing network210 (e.g. a transaction processing network) may be a payment transaction processing network. Theprocessing network210 may include aserver computer220 and various databases such as a token vault280 where token to account identifier (e.g. PAN) mapping may be stored, and an accountholder information database290 where user information about account holders may be stored.

Theserver computer220 may include adata processor222, anetwork interface224 and a computerreadable medium230 storing various modules for generating tokens and processing tokenized transactions. The various modules may include atokenization module240 for generating multiple tokens representing a same account, a transactionmessage processing module250 for receiving an authorization request message and an authorization response message, atoken verification module260 for verifying the token in the authorization request message and identifying the account corresponding to the token, and atransaction processing module270 for identifying an issuer of the account and providing the authorization request message along with any additional information to the issuer.

Other modules and submodules may also reside on the computerreadable medium230. Examples of additional modules may include a clearing and settlement module for processing and routing clearing messages and performing settlement between parties, and data extraction (e.g., for retrieving data from external data sources such as databases) modules, storage modules, and message modification modules. Each module in theprocessing network210 may be combined with any of the additional modules as appropriate. Each module in theprocessing network210 may comprise one or submodules, where each submodule may comprise one or more functions implemented by code, executable by thedata processor222.

The data processor222 (e.g., a microprocessor) may process functions of theserver computer220. Thedata processor222 may include hardware that can carry out instructions embodied as code in a computer-readable medium. Thedata processor222 may be a central processing unit (CPU). As used herein, a processor can include a single-core processor, a plurality of single-core processors, a multi-core processor, a plurality of multi-core processors, or any other suitable combination of hardware configured to perform arithmetical, logical, and/or input/output operations of a computing device.

Thenetwork interface224 may be any suitable combination of hardware and software that enables data to be transferred to and from theprocessing network210. Thenetwork interface224 may enable theprocessing network210 to communicate data to and from another device (e.g., resource provider computer, transport computer, authorization computer, etc.). Some examples of thenetwork interface224 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 thenetwork interface224 may include Wi-Fi™.

Data transferred via thenetwork interface224 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 thenetwork interface224 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.

According to various embodiments, theprocessing network210 may generate, using thedata processor222, tokens to identify an account. The tokens may be used as proxy to the account identifier (e.g. PAN) associated with the account. In some embodiments, the account holder, a third party entity (e.g. a resource provider) or the issuer of the account may request theprocessing network210 to generate the tokens. Thetokenization module240 of theprocessing network210 may be configured, in conjunction with thedata processor222, to generate one or more tokens to represent or otherwise identify the account. In some embodiments, each token may be associated with a transaction channel. For example, a first token may be generated for use in e-commerce transactions and a second token may be generated for use in contact transactions where thetransaction card100 is brought in contact with a terminal such as a POS terminal. The e-commerce and contact transaction channels are exemplary transaction channels and should not be construed as limiting. Thetokenization module240 may generate, using thedata processor222, additional tokens for different transaction channels such as close proximity (e.g. contactless) transactions, transactions within mobile applications stored on a mobile device, and the like.

The tokens generated by thetokenization module240 and the mapping between the tokens and the corresponding account identifier (e.g. PAN) may be stored at the token vault280. Thetokenization module240, in conjunction with thedata processor222, may access the token vault280 to store the generated tokens and the mapping between the tokens and the corresponding account identifier.

The transactionmessage processing module250, in conjunction with thenetwork interface224, may receive an authorization request message from a resource provider (e.g. a merchant) for example through an intermediary server (e.g. an access device). The transactionmessage processing module250 may identify, using thedata processor222, that the authorization request message includes a token. The transactionmessage processing module250 may retrieve, using thedata processor222, the token from the authorization request message and provide the token to thetoken verification module260.

Thetoken verification module260 may query, using thedata processor222, the token vault280 to determine if there is an entry for the token. If an entry is found, thetoken verification module260, in conjunction with thedata processor222, may retrieve the account identifier corresponding to the token. In some embodiments, thetoken verification module260, in conjunction with thedata processor222, may query databases and/or lists to determine whether the token or the account identifier has been associated with fraudulent activities. For example, thetoken verification module260, in conjunction with thedata processor222, may determine whether the token or the account identifier has been blacklisted or has been reported as stolen or otherwise compromised. Thetoken verification module260, in conjunction with thedata processor222, may further determine whether the token has expired. Thetoken verification module260, in conjunction with thedata processor222, may transmit the account identifier to thetransaction processing module270. If thetoken verification module260 obtained any information about the token and/or the account identifier (e.g. the token being expired, stolen or compromised), the token verification module may pass that information to thetransaction processing module270 along with the account identifier.

Thetransaction processing module270 may process, using thedata processor222, the transaction using the account identifier provided by the token verification module. Thetransaction processing module270 may also receive the transaction details from the transactionmessage processing module250 or thetokenization module260. In some embodiments, thetransaction processing module270, in conjunction with thedata processor222, may generate a modified authorization request message including the account identifier instead of the token. Thetransaction processing module270, in conjunction with thedata processor222, may determine an issuer of the account and send the modified authorization request message to the issuer. In some embodiments, thetransaction processing module270, in conjunction with thedata processor222, may determine the issuer based on information received from the accountholder information database290. In other embodiments, thetransaction processing module270, in conjunction with thedata processor222, may determine the issuer based on a format of the account identifier.

The issuer may process the transaction request and send an authorization response message to theprocessing network210. The transactionmessage processing module250 may receive, via thenetwork interface224, the authorization response message from the issuer and transmit the authorization response message to the intended party (e.g. the resource provider). After receiving the authorization response message, the transactionmessage processing module250 may determine, with thedata processor222, whether the authorization response message includes the account identifier. If the message includes the account identifier, the transactionmessage processing module250, in conjunction with thedata processor222 may retrieve from the token vault280 the token associated with the account identifier. In some embodiments, the transactionmessage processing module250, in conjunction with thedata processor222, may request thetokenization module240 to replace the account identifier with the token in the authorization response message. This may prevent other entities that process the authorization response message from obtaining confidential account information.

In some embodiments, thetoken verification module260 may determine, using thedata processor222, that the token provided in the authorization request message is stolen, compromised or expired. Thetoken verification module260, in conjunction with thedata processor222 may request thetokenization module240 to generate a new token to replace the expired, stolen or compromised token.

In some embodiments, thetoken verification module260, in conjunction with thedata processor222 may determine that permission from an authorization computer is required for replacing the expired, stolen or compromised token with a new token. The account can be a financial account (e.g. a bank account) and the authorization computer can be a bank or an issuer; the account can be a data access account (e.g. an email account or an account at a website) and the authorization computer can be a web server; or the account can be a physical location access account (e.g. an employee card to gain access to a building) and the authorization computer can be the administrator for the building. Thus, thetoken verification module260, in conjunction with thenetwork interface224, may request permission from the authorization computer. The authorization computer may initiate a form of identification and verification process or a step-up authentication process (e.g. one time pass code, call center call, requesting a PIN from the account holder, etc.) with the account holder before authorizing the generation of a replacement token.

Thetokenization module240, in conjunction with thedata processor222, may generate the replacement token, update the token vault280 to store the new replacement token in connection with the account identifier, and update the mapping between the account identifier and corresponding tokens. Thetoken verification module260, in conjunction with thedata processor222, may return the replacement token to the transactionmessage processing module250.

The transactionmessage processing module250 may send, via thenetwork interface224, a message (e.g. the authorization response message) to the terminal including the new (e.g. replacement) token. The new token may be transferred to thetransaction card100 via a contact or contactless interaction between the terminal and thetransaction card100. As discussed below in greater detail, the replacement token may replace the token that was digitally displayed on thetransaction card100. In some embodiments, the replacement token may replace a token that was previously stored at a contact/contactless/dual-interface chip of thetransaction card100.

In some embodiments, theprocessing network210, in conjunction with thedata processor222, may inform the authorization computer that a token associated with an account has been compromised and a new replacement token has been issued to replace the compromised token. This process does not impact the account identifier as the account identifier has not been compromised. Thus, it is not necessary for the authorization computer to replace the account identifier (e.g. PAN) or to generate areplacement transaction card100 with the new account information.

In some embodiments, the authorization computer may send a message to the account holder requesting the account holder to update the information on thetransaction card100 via an electronic device. For example, the authorization computer may send a message including the new (e.g. replacement) token to a mobile device of the account holder. The account holder may place thetransaction card100 in proximity of the mobile device (or insert thetransaction card100 in a card reader coupled to the mobile device) to transmit the replacement token from the mobile device to thetransaction card100. In other exemplary embodiments, the account holder may be asked to bring thetransaction card100 to an electronic device associated with the authorization computer (e.g. a banking location, an automated teller machine (ATM), or the like). The account holder may place thetransaction card100 in proximity of the electronic device (or insert thetransaction card100 in a card reader coupled to the electronic device) to transmit the replacement token from the electronic device to thetransaction card100.

FIG. 3 illustrates anexemplary flowchart310 for generating a transaction card with multiple tokens. At S312, theaccount holder300 requests opening an account with anauthorization computer302. The account can be a financial account (e.g. a bank account) and the authorization computer can be a bank or an issuer; the account can be a data access account (e.g. an email account or an account at a website) and the authorization computer can be a web server; or the account can be a physical location access account (e.g. an employee card to gain access to a building) and the authorization computer can be the administrator for the building.

At S314, theauthorization computer302 may create the account for theaccount holder300 in response to the request and assign an account identifier to the account. The account identifier may include an account number (e.g. PAN) that is used to identify the account.

At S316, theauthorization computer302 may request one or more tokens from thetoken service computer304 to represent the account identifier. According to various embodiments, each token may serve as a proxy for the account identifier (e.g. the tokens may be used in lieu of the account identifier). For example theauthorization computer302 may transmit a tokenization request message to the tokenservice provider computer304 and the tokenization request message may include the account identifier representing the account.

At S318, thetoken service computer304 may generate one or more tokens for the account identifier in response to the request from theauthorization computer302. At S320, thetoken service computer304 may store the generated tokens, as well as a mapping between the tokens and the account identifier at a storage (e.g. token vault306). At S322, thetoken service computer304 may transmit the one or more generated tokens to theauthorization computer302. According to various embodiments, thetoken service computer304 may be a part of or managed by the transaction processing network. In some embodiments, thetoken service computer304 may be a third party entity server.

Upon receiving the generated tokens from thetoken service computer304, theauthorization computer302 may generate (or interact with a card producing entity to generate) the transaction card including the one or more tokens at S324. The tokens may be provisioned on the transaction card. According to various embodiments, each provisioned token may be associated with a different communication channel between the transaction card and a token recipient device. The account identifier associated with the generated transaction card may not be visible on the transaction card. In some embodiments, the account identifier may not be stored on the transaction card such that only tokens are stored or otherwise provisioned on the transaction card. In yet other embodiments, the account identifier may be stored on a contact and/or contactless element of the transaction card such that the account identifier is not visible on the transaction card. Theauthorization computer302 may then send (e.g. provide) the transaction card to the account holder at S326.

FIG. 4 illustrates an exemplary block diagram of asystem400 for processing a transaction. Anaccount holder402 may present their transaction card (e.g. the account holder card404) to anaccess device406 for interacting with theaccess device406. Theaccess device406 may transmit and receive data to and from theaccount holder card404 using any number of communication methods supported by theaccess device406 and theaccount holder card404 such as near-field communications, magnetic-stripe, electrical contact, internet protocol, etc.

Theaccess device406 may be a device that is coupled to theresource provider computer408 in this example. In other examples, theaccess device406 may be a resource provider computer, or theaccess device406 in combination with theresource provider computer408 may constitute a “resource provider computer.” Theresource provider computer408 may be configured to generate, send, and receive authorization messages based on interactions with theaccount holder402. Thesystem400 may further comprise atransport computer410 configured to receive and forward authorization messages, atransaction processing network412 configured to process transaction data, and anauthorization computer416 configured to determine authorization decisions or authorization results.

During a transaction, theaccount holder402 may present theaccount holder card404 to a resource provider. The transaction may be a purchase of goods or services, a request to access a building, an inquiry for sensitive information, etc. In order to conduct the transaction, the resource provider may ask theaccount holder402 to transmit his or her stored credentials (e.g. a token) to theaccess device406. For example, the resource provider may be a merchant that asks theaccount holder402 to insert his or her payment card into a smart card reader of theaccess device406. The credentials of the account holder402 (e.g. the token) may be stored on the account holder card404 (e.g. the transaction card) in the form of an account identifier or a token that identifies an account of the user.

According to embodiments of the invention, theaccount holder card404 may transmit credentials instantly to theaccess device406 after a connection has been established or after confirmation of authenticating data such as a PIN, password, biometric, etc. Theaccess device406 may receive the credentials from theaccount holder card404 and may transmit the credentials to theresource provider computer408. The resource provider may use the received credentials to generate a message requesting information relating to theaccount holder402.

In one embodiment, theresource provider computer408 may use the received credentials to generate an authorization request message. For example, the authorization request message may comprise the token associated with the account of theaccount holder402. Theresource provider computer408 may send the authorization request message to thetransport computer410. Thetransport computer410 may be any computer for receiving and forwarding authorization messages according to embodiments of the invention. In one embodiment,transport computer410 may be a computer of an acquiring entity that enables a resource provider to conduct specific types of transactions.

Thetransport computer410 may receive the authorization request message from theresource provider computer408 and may forward the message to thetransaction processing network412. Thetransaction processing network412 may be any computer or server computer for processing transactions according to embodiments of the invention. For example, thetransaction processing network412 may be a computer of a payment processing network, such as VisaNet, and may be configured to receive, read, analyze, store, and retrieve transaction data as well as determine appropriate actions based on predetermined logic. Thetransaction processing network412 may analyze the authorization request message to determine whether the message includes a token. If thetransaction processing network412 determines that the authorization request message includes a token, thetransaction processing network412 provides the token to thetoken vault414 and retrieves the account identifier (e.g. PAN) corresponding to (e.g. represented by) the token. Thetransaction processing network412 may then replace the token with the account identifier in the authorization request message.

According to embodiments of the invention, thetransaction processing network412 may determine, based on the data in the authorization request message, an authorizing entity computer orauthorization computer416. For example, thetransaction processing network412 may analyze the account identifier and may determine that the first six digits of the account identifier comprises an issuer identification number (IIN) specifying an authorizing system associated with the account represented by the account identifier. In one embodiment, theauthorization computer416 may be a computer of an issuing entity that issues credentials and/or theaccount holder card404 to theaccount holder402 such as a bank, government agency, security network, etc. Upon determination of the authorizing entity computer, thetransaction processing network412 may determine an address of theauthorization computer416, so that the authorization request message can be routed to theauthorization computer416 for authorization of the transaction.

Thetransaction processing network412 may send the authorization request message to theauthorization computer416, and theauthorization computer416 may receive the authorization request message to determine an authorization result based on the data contained therein. For example, the data may comprise an account identifier or PAN that is associated with an availability of funds or credit that may be compared to a transaction amount. Theauthorization computer416 may evaluate the received data and determine an authorization result of “approve” or “decline.” The authorization result may be used to generate an authorization response message that may be sent back to thetransaction processing network412. Thetransaction processing network412 may receive the authorization response message and may send the message to thetransport computer410. Thetransport computer410 may then forward the authorization response message to theresource provider computer408 so that the resource provider may determine an action based on the authorization result contained therein.

Some of the steps discussed in connection withFIG. 4 may be used to update a token that is expired, stolen or compromised.

FIG. 5 shows a swim-lane diagram340 of updating a token on a tokenized transaction card at an access device according to an embodiment of the invention. As discussed in connection withFIG. 4, the account holder may use the transaction card to conduct a transaction with a resource provider. During the transaction, at S342 theaccount holder300 may present a first token (e.g. the token that is stored on a contact/contactless or dual interface of the transaction card) to anaccess device332 of the resource provider. For example, when theaccount holder300 brings the transaction card in contact with or in close proximity of theaccess device332, theaccess device332 may read or otherwise retrieve the first token from the contact/contactless or dual interface of the transaction card. At S344, theaccess device332 may transmit the first token along with additional transaction data (e.g. a transaction amount, transaction date, an identifier for the access device, among other data) to atransport computer334.

Thetransport computer334 or, in some embodiments, the access device, may generate an authorization request message including the first token and the additional transaction data. At S346, thetransport computer334 may transmit the authorization request message to theprocessing network336.

Upon receiving the authorization request message including the first token, theprocessing network336 may process the authorization request message to detokenize the first token. That is, theprocessing network336 may query the token vault to identify the account identifier corresponding to the first token. At S348, theprocessing network336, while processing the authorization request message using the first token, may determine that another token associated with the transaction card (e.g. the second token that is digitally displayed on the transaction card) is expired, stolen or compromised. For example, theprocessing network336 may query a database for blacklisted tokens. In some embodiments, theprocessing network336 may have been previously notified (e.g. by a resource provider) that the second token is among tokens that have been used in fraudulent transactions or compromised during a data breach. Upon determining that the second token is expired, stolen or compromised, theprocessing network336 may generate a replacement token. Theprocessing network336 may store the replacement token along with a mapping between the replacement token and the corresponding account identifier at a token vault (S350).

At S352, theprocessing network336 may notify theauthorization computer302 that the second token was compromised and that a replacement token was generated to replace the compromised second token. Theprocessing network336 may send the replacement token to theauthorization computer302. Theprocessing network336 may also send the authorization request message along with the account identifier (retrieved from the token vault) corresponding to the first token to theauthorization computer332.

Upon being notified that the second token was compromised, theauthorization computer302 may deactivate the second token (S353). According to various embodiments, when one of the tokens (e.g. second token) provisioned on the payment card is deactivated, the transaction card includes at least one active token that can be used to conduct transactions.

In some embodiments, theauthorization computer302 may deactivate all tokens associated with account identifier if one of the tokens have been compromised. Theprocessing network336 may also have been previously instructed by theauthorization computer302 to replace all tokens associated with an account identifier in the event that one of the tokens associated with that account identifier has been compromised. In yet other embodiments, theauthorization computer302 may request theprocessing network336 to update the tokens on a transaction card periodically. As discussed herein, the tokens on the transaction card may be replaced without replacing the transaction card, and with little or no burden to the card holder.

In some embodiments, when theauthorization computer302 deactivates one or more tokens, theauthorization computer302 may notify the account holder (e.g. via e-mail, text message, mail or telephone call) that the information on the transaction card (e.g. one or more tokens provisioned on the transaction card) need to be updated using an electronic device, such as an ATM or terminal at a physical location of theauthorization computer302. According to some embodiments, theauthorization computer302 may send the replacement token to a communication device (e.g. mobile phone) of theaccount holder300. The information on the transaction card may be updated by the communication device via short range communication or through a card reader coupled to the communication device. The token update process on the transaction card is discussed below in connection withFIG. 6.

In some embodiments, the information on the transaction card may be updated using the access device (e.g. a terminal) associated with the resource provider. In such embodiments, theauthorization computer302 may generate an authorization response message that includes a determination of the authorization request (e.g. approve or decline authorization for the transaction initiated using the first token) along with the replacement token(s) for the compromised token(s) (e.g. the replacement token for the second token). At S354, theauthorization computer302 may transmit the authorization response message to theprocessing network336. The authorization response message is associated with the transaction initiated using the first token at S342. However, the authorization request message may also include the replacement second token. At S355, theprocessing network336 may transmit the authorization response message (along with the replacement token) to thetransport computer334.

After receiving the authorization response message approving or declining authorization for the transaction, thetransport computer334 may process the transaction (either proceeds with the transaction or cancels the transaction depending on the authorization computer's reply). At S356, thetransport computer334 may transmit the replacement token(s) in the authorization response message to theaccess device332. When theaccount holder300 brings the transaction card in contact with or in close proximity to theaccess device332, the access device replaces the compromised token (e.g. the second token) with the replacement token on the transaction card (S358). If the authorization response message includes multiple tokens, all corresponding tokens are replaced with the new replacement tokens on the transaction card. In the case of multi-token replacement, each replacement token may be paired with the old token or an indicator of which token is to be replaced.

In some embodiments, the authorization response message transmitted to theaccess device332 from theauthorization computer302 may include a script with the replacement token. The script, when executed by theaccess device332, may replace the second token with the replacement token on the transaction card when theaccess device332 is in communication with the transaction card.

FIG. 6 shows a swim-lane diagram360 of updating a token on a tokenized transaction card using an electronic device according to an embodiment of the invention. As discussed above in connection withFIG. 5, theprocessing network336 may notify theauthorization computer302 that the token (e.g. second token) is expired, stolen or compromised. Theprocessing network336 may also send, to theauthorization computer302, the new replacement token generated to replace the second token (at S352).

At S362, theauthorization computer302 may transmit the replacement token and, if necessary, the account holder identifying information (e.g. account holder name, billing address, a consumer identification number, telephone number, etc.) to anelectronic device338. In some embodiments, theauthorization computer302 may send a script with the replacement token. The script, when executed by theelectronic device338, may replace the second token with the replacement token on the transaction card when theelectronic device338 is in communication with the transaction card. Theelectronic device338 may be an access device (e.g. a point of sale terminal), a user device of the account holder (e.g. a mobile phone) or a terminal at a physical location associated with the authorization entity (e.g. an ATM). At S362, theauthorization computer302 may also notify theaccount holder300 to update the account information stored on the transaction card using theelectronic device338.

At S366, theaccount holder300 may present the transaction card to theelectronic device338 identified by theauthorization computer302. At S368, theelectronic device338 may update the account information on the transaction card. For example, theelectronic device338 may replace the expired or compromised second token with the new replacement token. If the compromised token is displayed on a digital display coupled to the transaction card, theelectronic device338 may reconfigure the digital display to display the replacement token instead of the compromised token. The compromised token will be erased from the transaction card, and the replacement token will be stored and/or displayed on the transaction card.

If theelectronic device338 is an access device (e.g. a POS terminal), theauthorization computer302 may transmit the replacement token and, if necessary, a script and account holder identifying information to the access device in form of an authorization response message. The account holder may either bring the transaction card in close proximity of the access device (e.g. tap the transaction card to the access device), may insert the transaction card into a card reader, or may slide the transaction card through a card reader coupled to the access device. When the access device identifies that information associated with the transaction card matches the information (e.g. the account holder identifying information) provided by theauthorization computer302, the access device may replace at least one token (e.g. the second token) with the replacement token on the transaction card. For example, the access device may execute the script provided by theauthorization computer302 to perform the replacement of the token with the new token on the transaction card.

If theelectronic device338 is a communication device of the account holder (e.g. a mobile phone), theauthorization computer302 may transmit the replacement token and, if necessary, a script to the communication device. In some embodiments, theauthorization computer302 may send an over-the-air message to the communication device using the cellular communication network to transmit the replacement token and, when applicable, the script. In some embodiments, theauthorization computer302 push the replacement token and, when applicable, the script to the communication device (e.g. via e-mail or as part of an issuer update package). The account holder may either bring the transaction card in close proximity of the communication device (e.g. tap the transaction card to the communication device), may insert the transaction card into a card reader, or may slide the transaction card through a card reader coupled to the communication device. The communication device may replace at least one token (e.g. the second token) with the replacement token on the transaction card. For example, the communication device may execute the script provided by theauthorization computer302 to perform the replacement of the token with the new token on the transaction card.

If theelectronic device338 is a terminal of the authorization entity (e.g. an ATM), theauthorization computer302 may transmit the replacement token and, if necessary, a script and account holder identifying information to terminal. The account holder may either bring the transaction card in close proximity of the terminal (e.g. tap the transaction card to the access device), may insert the transaction card into a card reader, or may slide the transaction card through a card reader coupled to the terminal. When the terminal identifies that information associated with the transaction card matches the information (e.g. the account holder identifying information) provided by theauthorization computer302, the terminal may replace at least one token (e.g. the second token) with the replacement token on the transaction card. For example, the terminal may execute the script provided by theauthorization computer302 to perform the replacement of the token with the new token on the transaction card.

According to various embodiments, the compromised token on the transaction card may be replaced when the transaction card is used for a transaction using the compromised token. For example, the account holder may present the transaction card for a transaction using the compromised token without knowing that the token was compromised. For example, if the transaction is an e-commerce transaction, theaccount holder300 may provide the second token to the resource provider using a communication device (e.g. on a website of the resource provider displayed on a computer of the account holder). In some embodiments, the resource provider or theaccount holder300 may enter the second token to the access device332 (e.g. POS) of the resource provider. During the processing of the transaction using the compromised token, theprocessing network336 may determine that the token has been identified and/or reported as expired, stolen or compromised. Theprocessing network336 may generate a replacement token (as discussed above) and provide the replacement token to theauthorization computer302 for provisioning on the transaction card. Theprocessing network336 may also provide the authorization request message for the transaction initiated using the compromised token to theauthorization computer302. Theauthorization computer302 may generate an authorization response message approving or declining the transaction initiated using the compromised token, theauthorization computer302 may include the replacement token in the authorization response message. The expired, stolen or compromised token on the transaction card may be replaced with the replacement token as discussed above. This use case allows the account holder who is still in possession of the transaction card to update the account information (e.g. tokens) stored or provisioned on the transaction card without having to replace the transaction card.

Embodiments of the invention provide for a number of advantages. Embodiments enable the replacement of tokens on a transaction card without replacing the transaction card. In fact, the transaction card may not have to be replaced unless the card holder loses the transaction card. Embodiments further enable the replacement of tokens on a transaction card using electronic devices such as mobile phones, POS terminals or ATM terminals. Conventional systems are not able to use these terminals for token replacement on a transaction card.

Embodiments further provide a digital display coupled to the transaction card for dynamically displaying a token. This way, the token displayed on the digital display may be replaced with a new token by refreshing the digital display without having to replace the transaction card. Eliminating the generation of a replacement transaction card reduces the financial cost and inefficiencies associated with generating a new transaction card. Eliminating the generation of a replacement transaction card also improves the impact on the environment by reducing the plastic and other harmful materials used during the manufacturing of transaction card elements (e.g. chips).

Embodiments also enable the card holder to continue using the account or the transaction card to conduct new transactions if one token is compromised. The card holder does not have to wait for a replacement card to arrive and be activated. Instead, the card holder may continue conducting transactions using the remaining token(s) on the transaction card. In addition, the replacement token may be provisioned on the transaction card on the same day that a token is identified as expired, stolen or compromised. Accordingly, embodiments provide valuable time savings by providing an efficient way to update data on a transaction card.

Some entities or components described herein may be associated with or operate one or more computer apparatuses to facilitate the functions described herein. Some of the entities or components described herein, including any server or database, may use any suitable number of subsystems to facilitate the functions.

Examples of such subsystems or components can be interconnected via a system bus. Additional subsystems such as a printer, keyboard, fixed disk (or other memory comprising computer readable media), monitor, which is coupled to display adapter, and others are shown. Peripherals and input/output (I/O) devices, which couple to I/O controller (which can be a processor or other suitable controller), can be connected to the computer system by any number of means known in the art, such as serial port. For example, serial port or external interface can be used to connect the computer apparatus to a wide area network such as the Internet, a mouse input device, or a scanner. The interconnection via system bus allows the central processor to communicate with each subsystem and to control the execution of instructions from system memory or the fixed disk, as well as the exchange of information between subsystems. The system memory and/or the fixed disk may embody a computer readable medium.

Embodiments of the invention are not limited to the above-described embodiments. For example, although separate functional blocks are shown for an issuer, payment processing network, and acquirer, some entities may perform a combination or all of these functions and may be included in some embodiments.

Messages between the computers, networks, and devices described herein may be transmitted using a secure communications protocols such as, but not limited to, File Transfer Protocol (FTP); HyperText Transfer Protocol (HTTP); Secure Hypertext Transfer Protocol (HTTPS), Secure Socket Layer (SSL), ISO (e.g., ISO 8583) and/or the like.

It should be understood that the present invention as described above can be implemented in the form of control logic using computer software (stored in a tangible physical medium) in a modular or integrated manner. Based on the disclosure and teachings provided herein, a person of ordinary skill in the art will know and appreciate other ways and/or methods to implement the present invention using hardware and a combination of hardware and software.

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++ or Perl 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, such as a 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 CD-ROM. Any such computer readable medium may reside on or within a single computational apparatus, and may be present on or within different computational apparatuses within a system or network.

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.

A recitation of “a”, “an” or “the” is intended to mean “one or more” unless specifically indicated to the contrary.

All patents, patent applications, publications, and descriptions mentioned above are herein incorporated by reference in their entirety for all purposes. None is admitted to be prior art.

Claims (17)

What is claimed is:

1. A method performed by a server computer, the method comprising:

transmitting a tokenization request message to a token service provider system, the tokenization request message including an account identifier representing an account of a user;

receiving, from the token service provider system, a plurality of tokens corresponding to the account identifier;

provisioning the plurality of tokens on a transaction card, wherein each token is associated with a different communication channel between the transaction card and a token recipient device, wherein provisioning includes:

storing a first token at a first element of the transaction card, and

storing a second token at a second element of the transaction card, wherein the first element or the second element is one of a contact interface chip, a contactless interface chip, a dual interface chip, a magnetic strip, or a digital display of the transaction card, wherein the first element is different than the second element;

deactivating the first token when the first token is compromised or expired;

receiving, from a transaction terminal of a resource provider, an authorization request message for a transaction initiated using the second token stored on the transaction card;

processing the authorization request message using the second token; and

transmitting, to the transaction terminal of the resource provider, an authorization response message indicating whether the transaction is authorized or declined using the second token, wherein the authorization response message transmitted to the transaction terminal further includes a replacement token to replace the first token on the transaction card without replacing the transaction card by providing the replacement token to the transaction card via the transaction terminal, the providing including:

presenting, by the user, the transaction card to the transaction terminal;

receiving, by the transaction card, the replacement token while the transaction card is in communication with the transaction terminal, wherein the replacement token is stored on the transaction card replacing the first token.

2. The method ofclaim 1, further comprising:

upon deactivating the first token, notifying an account holder of the account that data associated with the transaction card is to be updated using the transaction terminal.

3. The method ofclaim 1, wherein the first token is digitally displayed on the transaction card.

4. The method ofclaim 3, wherein, after the first token is replaced with the replacement token, the replacement token is digitally displayed on the transaction card instead of the first token.

5. The method ofclaim 1, wherein the first token or the replacement token is visible on an element coupled to the transaction card.

6. The method ofclaim 1 wherein transmitting the replacement token to the transaction terminal further comprises:

transmitting a script with the replacement token to the transaction terminal, wherein the script, when executed by the transaction terminal, replaces the first token with the replacement token on the transaction card.

7. The method ofclaim 1, wherein the first token and the replacement token are associated with a same communication channel between the transaction card and the token recipient device.

8. The method ofclaim 1, wherein the plurality of tokens are provisioned on the transaction card instead of the account identifier.

9. The method ofclaim 1, wherein the account identifier is invisible on the transaction card.

10. The method ofclaim 1, wherein when the first token is deactivated, the transaction card includes at least one active token.

11. A server 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 a tokenization request message to a token service provider system, the tokenization request message including an account identifier representing an account of a user;

receiving, from the token service provider system, a plurality of tokens corresponding to the account identifier;

provisioning the plurality of tokens on a transaction card, wherein each token is associated with a different communication channel between the transaction card and a token recipient device, wherein provisioning includes:

storing a first token at a first element of the transaction card, and

storing a second token at a second element of the transaction card, wherein the first element or the second element is one of a contact interface chip, a contactless interface chip, a dual interface chip, a magnetic strip, or a digital display of the transaction card, wherein the first element is different than the second element;

deactivating the first token when the first token is compromised or expired;

receiving, from a transaction terminal of a resource provider, an authorization request message for a transaction initiated using the second token stored on the transaction card;

processing the authorization request message using the second token; and

transmitting, to the transaction terminal of the resource provider, an authorization response message indicating whether the transaction is authorized or declined using the second token, wherein the authorization response message transmitted to the transaction terminal further includes a replacement token to replace the first token on the transaction card without replacing the transaction card by providing the replacement token to the transaction card via the transaction terminal, the providing including:

presenting, by the user, the transaction card to the transaction terminal;

receiving, by the transaction card, the replacement token while the transaction card is in communication with the transaction terminal, wherein the replacement token is stored on the transaction card replacing the first token.

12. The server computer ofclaim 11, wherein the method implemented by the code further comprises upon deactivating the first token, notifying an account holder of the account that data associated with the transaction card is to be updated using the transaction terminal.

13. The server computer ofclaim 11, wherein the first token is digitally displayed on the transaction card; and wherein, after the first token is replaced with the replacement token, the replacement token is digitally displayed on the transaction card instead of the first token.

14. The server computer ofclaim 11, wherein transmitting the replacement token to the transaction terminal further comprises:

transmitting a script with the replacement token to the transaction terminal, wherein the script, when executed by the transaction terminal, replaces the first token with the replacement token on the transaction card.

15. The server computer ofclaim 11, wherein the first token and the replacement token are associated with a same communication channel between the transaction card and the token recipient device.

16. The server computer ofclaim 11, wherein the plurality of tokens are provisioned on the transaction card instead of the account identifier, and wherein the account identifier is invisible on the transaction card.

17. The server computer ofclaim 11, wherein when the first token is deactivated, the transaction card includes at least one active token.

Images