Instant Token Issuance System

Abstract

A user can request that the account information of an account be provided to multiple resource providing entities. The account can be a new or existing account issued by an authorization computer. The authorization computer can prompt the user to select one or more resource providing entities to which a token associated with the account is to be provided. The processor server computer can then tokenize the account information associated with the account by determining the token of each resource providing entity selected by the user. In some cases, the token can be provided to an existing account or archive (e.g., an archived account) associated with the resource providing entity. In other cases, the account or archive associated with the resource providing entity may not yet exist and therefore can be created before the token can be provided. Subsequently, the user can use the provided token to conduct a transaction.

Description

[0001] This application is a divisional application of the invention patent application with Chinese application number: 201680060089.8; the invention name is "Instant Token Issuance System".

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application is a voluntary application of and claims priority to U.S. Provisional Application No. 62 / 242,068, filed on October 15, 2015, and U.S. Provisional Application No. 62 / 242,074, filed on October 15, 2015, which are hereby incorporated by reference in their entirety for all purposes. Background Art

[0004] Users often manage multiple digital accounts associated with various entities. For example, these accounts may be associated with various resource providers, such as merchants, digital wallet providers, and service providers. In some cases, users may add card accounts to these digital accounts to conduct transactions. Typically, before conducting a transaction, users may have to provide their card account information to each of the corresponding resource providers individually. This is cumbersome because users must go through lengthy steps to enter the same card account information. Furthermore, since each resource provider may operate a different platform, the input process is neither smooth nor timely.

[0005] Furthermore, when the card account is new, the process of adding the card account information to a digital account can be even more cumbersome. When a user applies for a card account, such as a credit card, there is often a delay before the user can use the card for transactions. For example, the user may typically have to wait until the card is made of plastic and delivered to the user, which can take at least five to seven days. This delay limits the user's ability to use the card. Furthermore, once the card is approved, if the user wishes to add their card account to other digital accounts, they will need to manually add the card account information for each digital account. It may be desirable to provide the user with the ability to use the new card as quickly as possible.

[0006] Embodiments of the present invention address this and other problems individually and collectively. Summary of the Invention

[0007] Embodiments of the present invention relate to systems and methods for providing account information to resource providing entities and devices. In some cases, the account information may be an already existing account or a new account requested by a user. Embodiments of the present invention enable users to control which resource providing entity (e.g., merchant, digital wallet provider, service provider, etc.) to which account information is provided through an issuer application (or a third-party token port). In some embodiments, the account information may include tokenized card account information associated with a card account. In some cases, the token may also be provided to other devices (e.g., mobile devices, tablet computers, wearable devices, etc.) indicated by the user. The device may have a security element or may be cloud-based. Embodiments of the present invention make it possible to provide a card to a user's device within an application.

[0008] According to an embodiment of the present invention, a server computer can perform a method. The server computer can send a list of participating resource-providing entities to an authorization computer. The authorization computer can prompt a user to operate a user device to select from the list of participating resource-providing entities. The server can then receive a selection from one or more of the participating resource-providing entities, and can receive a request to issue a token associated with an account of a user for the one or more resource-providing entities. For each of the one or more resource-providing entities, the server computer can determine a token associated with the user's account; the token can be sent to a resource-providing entity computer associated with the resource-providing entity, wherein the user uses the token to conduct transactions with the resource-providing entity.

[0009] The account may be a new account or an existing account. When the account is a new account, the server computer may receive account information associated with the account from the authorization computer. When the account is an existing account, the server computer may retrieve account information associated with the account.

[0010] In some embodiments, the server computer may perform an authentication process. For each of the plurality of participating resource-providing entities selected by the user, the server computer may prompt the user for authentication information of the participating resource-providing entity and may send the authentication information to the participating resource-providing entity. In some cases, the authentication information may be used to create a new account for the user associated with the participating resource-providing entity.

[0011] In some embodiments, the server computer may further determine the authentication methods supported by the authorization computer. For each of the participating resource-providing entities in the list, the server computer may further determine the authentication methods supported by the participating resource-providing entity and may compare the authentication methods supported by the participating resource-providing entity with the authentication methods supported by the authorization computer. Upon determining that the compared authentication methods match, the server computer may include the participating resource-providing entity in the list of participating resource-providing entities.

[0012] In some embodiments, the server computer may determine that at least one of the participating resource-providing entities has an account on file with the user. The server computer may send information to the authorization computer indicating that the user has an account on file with the at least one participating resource-providing entity. In some cases, the one or more resource-providing entities selected by the user may include a participating resource-providing entity that has an account on file with the user. In some cases, the user may also conduct transactions using the account on file.

[0013] In some embodiments, the server computer may generate one or more links. In some implementations, the server computer may generate a link routed to the server computer and may send the link to the authorization computer. After the authorization computer prompts the user, the user may activate the link using the user device. In some implementations, the server computer may generate multiple links routed to the multiple resource providing entities and may send the multiple links to the authorization computer. After the authorization computer prompts the user, the user may activate the multiple links using the user device.

[0014] Embodiments of the present invention also relate to a server computer comprising a processor and a computer-readable medium. The computer-readable medium may be coupled to the processor and may include code executable by the processor for implementing any of the methods described herein.

[0015] These and other embodiments of the invention are described in greater detail below. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] Figure 1 An exemplary flow chart of a method according to an embodiment of the present invention is shown.

[0017] Figure 2 An exemplary user interface according to an embodiment of the present invention is shown.

[0018] Figure 3An exemplary user interface according to an embodiment of the present invention is shown.

[0019] Figure 4 A block diagram illustrating an exemplary system according to an embodiment of the present invention is shown.

[0020] Figure 5 A block diagram illustrating an exemplary system according to an embodiment of the present invention is shown.

[0021] Figure 6 An exemplary flow chart of a method according to an embodiment of the present invention is shown.

[0022] Figure 7 A block diagram illustrating an exemplary system according to an embodiment of the present invention is shown.

[0023] Figure 8 An exemplary flow chart of a method according to an embodiment of the present invention is shown.

[0024] Figure 9 A flow chart illustrating a method of providing a user with immediate card access upon approval and providing a token to a merchant account on file, in accordance with an embodiment of the present invention.

[0025] Figure 10 An exemplary flow chart illustrating a method for providing a user with immediate card access upon approval according to an embodiment of the present invention.

[0026] Figure 11 An exemplary flow chart illustrating a method for providing a user with immediate card access upon approval according to an embodiment of the present invention.

[0027] Figure 12 An exemplary flow chart illustrating a method for providing a user with immediate card access upon approval according to an embodiment of the present invention. DETAILED DESCRIPTION

[0028] Embodiments of the present invention relate to account information that can be provided to resource-providing entities and devices. In some embodiments, the account information can be issued to a user instantly. For example, when a user uses a user device to apply for a new payment card from an authorized entity, the user's new payment card can be approved. Subsequently, a token associated with the new payment card can be provided to the user device and the resource-providing entity selected by the user. In other embodiments, the token associated with the new payment card can be created at a later time after the card is issued. Therefore, embodiments of the present invention are not limited to instant card issuance.

[0029] Additional steps may be performed to provide the new payment card account number or a token associated with the new payment account number to a merchant account on file (e.g., card on file). Embodiments of the present invention enable the user to control, through the issuer application (or third-party token portal), to which resource providing entity (e.g., merchant, digital wallet provider, service provider, etc.) the token for the newly issued card is provided. In some embodiments, the token may also be provided to other devices indicated by the user (e.g., mobile devices, tablets, wearable devices, etc.). The devices may have a secure element or may be cloud-based. Embodiments of the present invention make it possible to provide the card to the user's device within the application.

[0030] In some embodiments, users are not limited to using tokens for recurring payments. For example, once a token is provided to a merchant or device, it can be used for any transaction of any type (e.g., recurring, one-time, on-demand, etc.). Payment methods for transactions may include eCommerce, mCommerce, In-app, NFC, MST, and NFC. TM ).

[0031] Furthermore, embodiments of the present invention are not limited to instant issuance and newly issued cards. Embodiments of the present invention can also provide a user's existing cards to resource provisioning entities and devices. For example, a user can log into their mobile or online banking account and push a token tied to one of their existing cards to a resource provisioning entity participating in the tokenization program or to their other devices.

[0032] Furthermore, embodiments of the present invention are not limited to providing tokens to existing accounts or profiles associated with a resource providing entity. Embodiments of the present invention also enable a user to request that a token associated with a new or existing card be added to a new account or profile associated with the resource providing entity, in addition to an existing account or profile associated with the resource providing entity. In some cases, the new or existing account or profile may be one associated with the user or a second user (e.g., a family member, an employee, etc.). A new account or profile may be created upon user request to provide a token to the resource providing entity.

[0033] Before discussing specific embodiments and examples, some description of the terms used herein is provided below.

[0034] An "authorization request message" may be an electronic message sent to a payment processing network and / or the issuer of a payment card to request authorization for a transaction. The authorization request message according to some embodiments may comply with (International Organization for Standardization) ISO 8583, which is a system standard for exchanging electronic transaction information associated with payments made by consumers using payment devices or payment accounts. The authorization request message may include an issuer account identifier that may be associated with the payment device or payment account. The authorization request message may also include additional data elements corresponding to "identification information", including, by way of example only: a service code, CVV (card verification value), dCVV (dynamic card verification value), expiration date, etc. The authorization request message may also include "transaction information", such as any information associated with the current transaction, such as the transaction amount, merchant identifier, merchant location, etc., as well as any other information that may be used to determine whether to identify and / or authorize the transaction.

[0035] An "authorization response message" may be an electronic message generated by the issuing financial institution or payment processing network in response to an authorization request message. The authorization response message may include (by way of example only) one or more of the following status indicators: approved - the transaction was approved; rejected - the transaction was not approved; or call center - the response is pending and the merchant must call a toll-free authorization phone number for more information. The authorization response message may also include an authorization code, which may be a code that the credit card issuing bank returns to the merchant's access device (e.g., a POS device) in response to the authorization request message in the electronic message (directly or through the payment processing network) indicating that the transaction is approved. The code may serve as evidence of authorization. As described above, in some embodiments, the payment processing network may generate or forward the authorization response message to the merchant.

[0036] A "token" may include an alternative identifier for certain information. For example, a payment token may include an identifier for a payment account that is an alternative to an account identifier, such as a primary account number (PAN). For example, a token may include a series of alphanumeric characters that can be used as an alternative to the original account identifier. For example, the token "4900 0000 0000 0001" can be used in place of the PAN "41470900 0000 1234". In some embodiments, the token may be "format-preserving" and may have a numeric format consistent with account identifiers used in existing payment processing networks (e.g., the ISO 8583 financial transaction message format). In some embodiments, the token may be used in place of the PAN to initiate, authorize, settle, or complete a payment transaction. In other systems that typically provide original credentials, the token may also be used to represent the original credentials. In some embodiments, the token value may be generated so that it is not computationally feasible to recover the original PAN or other account identifier from the token value.

[0037] A "resource providing entity" may be an entity that can make resources available to users. Examples of resource providing entities include merchants, suppliers, vendors, owners, traders, wallet providers, service providers, and the like. In some embodiments, such an entity may be a single individual, a group of individuals, or a larger group of individuals (e.g., a company). A resource providing entity may be associated with one or more physical locations (e.g., supermarkets, shopping malls, stores, etc.) and online platforms (e.g., e-commerce websites, online companies, etc.). In some embodiments, a resource providing entity may provide physical goods (e.g., goods, products, etc.) to users. In other embodiments, a resource providing entity may provide digital resources (e.g., electronic documents, electronic files, etc.) to users. In other embodiments, a resource providing entity may manage user access to certain resources. In some embodiments, a resource may be a service (e.g., a digital wallet service). A resource providing entity may also be referred to as a resource provider, etc.

[0038] A "participating resource providing entity" may be a resource providing entity that has joined the program. In some cases, a participating resource providing entity may be a resource providing entity that has registered with the tokenization program. For example, a participating resource providing entity may have an account (e.g., a processor server computer) with a token service provider and may be capable of processing transactions using tokenized account information (e.g., tokens).

[0039] An "authorization computer" may include any system involved in transaction authorization. The authorization computer may be operated by an authorization entity. The authorization computer may determine whether a transaction can be authorized and may generate an authorization response message including an authorization status (also referred to as an authorization decision). In some embodiments, the authorization computer may be a payment account issuer computer. In some cases, the authorization computer may store contact information for one or more users. In other embodiments, the authorization computer may authorize non-financial transactions involving users. For example, the authorization computer may make an authorization decision regarding whether a user may access a resource.

[0040] "Account information" may refer to any information associated with a user's account (e.g., a payment account and / or payment device associated with the account). This information may be directly related to the account or may be derived from information related to the account. Examples of account information may include PAN (primary account number or "account number"), user name, expiration date, CVV (card verification value), dCVV (dynamic card verification value), CVV2 (card verification value 2), CVC3 card verification value, etc. CVV2 is generally understood to be a static verification value associated with a payment device. The CVV2 value is typically visible to the user (e.g., a consumer), while the CVV and dCVV values ​​are typically embedded in a memory or authorization request message and are not easily known to the user (although they are known to the issuer and payment processor). In some cases, account information may also be referred to as card account information.

[0041] "Contact information" may refer to any information that can be used to contact a user. For example, contact information may include an email address, phone number, IP address, or other information. In some embodiments, contact information may be used as an alias identifier for the user.

[0042] “Transaction data” (which may also be referred to as transaction information) may refer to any data or information surrounding or related to a transaction. For example, transaction data may include transaction details and any data associated with the transaction, which may be used by entities involved in the transaction process. For example, transaction data may include information used to process and / or verify a transaction. Transaction data may also include any data or information surrounding or related to any participant involved in or associated with the transaction. Example transaction data may include the transaction amount, transaction location, resource received (e.g., product, document, etc.), information about the resource received (e.g., size, quantity, type, etc.), resource providing entity data (e.g., merchant data, document owner data, etc.), user data, date and time of the transaction, payment method, and other relevant information.

[0043] A "card on file" may alternatively be referred to as an "account on file." An account on file may refer to an account identifier (e.g., an account number) that is on file with a resource-providing entity, such as a merchant, digital wallet, or other entity. In these cases, the account identifier may be used by the user to perform purchases from the resource-providing entity. When conducting a transaction, the user does not need to specifically provide their account number to the resource-providing entity because the resource-providing entity already has the account number. In some embodiments, the frequency and / or amount of purchases made on the account on file may vary, and may represent an agreement between the cardholder and the merchant to purchase goods or services that are provided over a period of time or on demand.

[0044] A "server computer" can be a powerful computer or computer cluster. For example, a server computer can be a mainframe, a minicomputer cluster, or a group of servers that work like a cell. In one example, a server computer can be a database server coupled to a network server.

[0045] Figure 1 An exemplary flow chart 100 of a method according to an embodiment of the present invention is shown. Figure 1 It comprises a user device 10 capable of communicating with an access device 12 . Figure 1 Also included is a user device 14. The user device 10 and the user device 14 may have the same Figure 4 Features similar to those of the user device 103 in FIG.

[0046] Access device 12 can be any suitable device that provides access to a remote system. Access device 12 can be in any suitable form. Some examples of access devices include POS or point of sale devices (e.g., POS terminals), cellular phones, PDAs, personal computers (PCs), tablet PCs, handheld dedicated readers, set-top boxes, electronic cash registers (ECRs), automated teller machines (ATMs), virtual cash registers (VCRs), kiosks, security systems, access systems, and the like. Access device 12 can use any suitable contact or contactless operating mode to send or receive data to or from user device 10, or to associate with the user device.

[0047] In some embodiments where access device 12 may include a POS terminal, any suitable POS terminal may be used and may include a reader, a processor, and a computer-readable medium. The reader may include any suitable contact or contactless operating mode. For example, an exemplary card reader may include a radio frequency (RF) antenna, an optical scanner, a barcode reader, or a magnetic stripe reader to interact with a payment device and / or a mobile device. In some embodiments, a cell phone, tablet, or other dedicated wireless device used as a POS terminal may be referred to as a mobile point of sale or "mPOS" terminal.

[0048] In step S1, a user may apply for a new account. In some embodiments, the user may see an advertisement for creating a new account, which may lead to a website where the user can submit a request to apply for a new account. The website may be hosted by an authorized computer associated with an authorized entity (e.g., an issuer) that can issue new accounts.

[0049] Advertisements can take various forms. In some cases, the advertisement can be in the form of a physical poster that can include a scannable code (e.g., a QR code) or a printed link. The user can scan the scannable code, which can open a browser on the user device 10. In other cases, the user can type in a printed link to open the website. In other cases, the advertisement can be received via email or text message, and the advertisement can include a link that the user can activate to be routed to the website. In yet other embodiments, the advertisement can be an online advertisement that can appear while the user is browsing a web page. The advertisement can be clicked to route the user to the website.

[0050] After being routed to the website, the user may be prompted to enter information to apply for a new account. In some cases, the information may include name, address, and contact information (e.g., email address, phone number, etc.). In some cases, once the information is entered, the user may confirm the information by activating a software button (e.g., an "Apply Now" button). This may trigger the information entered by the user to be sent to an authorization computer, which may perform an approval process to determine whether a new account can be created for the user. If the creation of the account is approved, the authorization computer may create a new account associated with the user. In some cases, creating the new account may include generating an account identifier associated with the new account.

[0051] In step S2, the user may be prompted with a plurality of participating resource-providing entities from which the user may select. A participating resource-providing entity may be an entity participating in the tokenization program. By selecting a resource-providing entity, the user indicates that they wish to provide the token associated with the new account to that resource-providing entity. In some cases, participating resource-providing entities may include various merchants, digital wallet providers, and service providers with which the user may or may not have an existing account or profile.

[0052] Any suitable interface that can prompt the user to select one or more participating resource providing entities. In some cases, the user interface may include a selectable display tile labeled with an identifier (e.g., name) associated with the corresponding resource providing entity, such as Figure 1 In other cases, the user interface may include Figure 2 2. Other exemplary user interfaces may include other selectable user interface elements, such as radio buttons, drop-down lists, list boxes, buttons, toggles, scroll bars, and icons.

[0053] In some embodiments, the participating resource providing entities may be presented in the user interface in some manner. For example, in some cases, the participating resource providing entities may be pre-selected when presented in the interface. In some cases, the participating resource providing entities may also be displayed at the top of the list of participating resource providing entities presented in the user interface. This can make it easy for the user to confirm whether to add the new account to these pre-selected participating resource providing entities. However, the user can deselect any pre-selected participating resource providing entity to indicate that the token associated with the new account should not be provided to that particular participating resource providing entity. The user can also select any additional participating resource providing entities to which the token associated with the new account should be provided.

[0054] In some cases, once the selection of participating resource providing entities is made, the user can confirm the selection by activating a software button (e.g., a "Confirm" button). This can trigger the selection to be sent to an authorization computer or to a processor server computer (e.g., a token service provider). A token associated with the new account can be provided to each of the selected participating resource providing entities.

[0055] In one exemplary case, one of the selected participating resource providing entities may be a digital wallet provider. If the user already has an account associated with the selected digital wallet provider, the token may be provided to the existing account. If the user does not yet have an account associated with the selected digital wallet provider, an account may be created, after which the token may be provided to the account associated with the digital wallet provider.

[0056] In an exemplary case, one of the selected participating resource providing entities may be a merchant. If the user already has an account associated with the selected merchant (e.g., an archived account), the token may be provided to the existing account. If the user does not yet have an account associated with the selected merchant, an account may be created, after which the token may be provided to the account associated with the merchant.

[0057] In step S3, the user can conduct a transaction using the token provided to the selected participating resource provider. As described in the exemplary case above, the selected participating resource provider may be a digital wallet provider. The user can use the user device 10 to run an application hosted by the digital wallet provider. In some embodiments, the application may be a digital wallet provider that enables contactless transactions. In some cases, the user can indicate to the application that they are using the token provided for the transaction. In other cases, information related to the token may be pre-filled by the application. The user device 10 can then transmit the account information including the token to the access device 12 for the transaction. As a result, the new account can be used to conduct transactions with the digital wallet provider immediately after issuance.

[0058] In step S4, the user can use the token provided to another selected participating resource providing entity to conduct another transaction. As described in the exemplary case above, the selected participating resource providing entity can be a merchant. In some embodiments, the user can use the user device 14 to conduct a transaction using the provided token. In some embodiments, the user device 14 can run a website or application hosted by the merchant. In some cases, the user can indicate to the application or website that the token provided for the transaction is used. In other cases, information related to the token can be pre-filled by the application or website. The user can then use the provided token to conduct a transaction with the merchant. As a result, the new account can be used to conduct transactions with the merchant immediately after issuance.

[0059] Although the exemplary case above describes a user operating user device 10 and user device 14, the embodiments are not limited thereto. For example, a token may be provided for use by another second user (e.g., a family member, an employee, etc.). Based on the user's selection of a participating resource providing entity, the second user can conduct transactions using the token associated with the user's account opened at the selected participating resource providing entity.

[0060] Furthermore, although in the exemplary case the provided token is associated with a newly issued account, the embodiments are not so limited. For example, the provided token can be used for an existing account associated with the user. In this case, the user can open an application associated with the authorization entity on the user device 10, and the application can host the existing account. The user can indicate that he or she wants to provide the token associated with the existing account to multiple selected participating resource providing entities. For any of the selected participating resource providing entities for which no account or profile exists, an account or profile can be generated, and the token can then be added to the generated account or profile. As a result, the user can control the token provided from the application associated with the authorization entity, and each of the selected resource providing entities can store the token for future use.

[0061] Embodiments of the present invention can provide tokens for various use cases, such as those shown in Table 1 below.

[0062] Table 1

[0063]

[0064]

[0065] In some embodiments, the user may manage the provided tokens through an application (e.g., hosted by an authorized entity) or a third-party token portal. Figure 3An exemplary user interface 300 is shown in FIG. Activating any of the user interface elements (e.g., buttons) of user interface 300 opens another user interface, enabling the user to view data and configure settings associated with a provided token. For example, activating the "History" button allows the user to review historical information (e.g., historical transactions) for any provided token. Activating the "Pause" button allows the user to request a pause in the use of any provided token. In an exemplary case, the user can instruct to pause the use of a provided token by a specific second user or a specific device (e.g., temporarily). Activating the "Delete" button allows the user to request the deletion of any provided token from the corresponding resource providing entity's system. Activating the "Control" button allows the user to configure and exercise controls (e.g., spending controls, time limits, etc.) over the provided token. For example, the user can configure the provided token to authorize transactions below a specific transaction amount. Activating the "Warning" button allows the user to configure warning settings, indicating when the user should receive warnings regarding the provided token. In an exemplary case, the user can configure the warning settings so that a warning is sent if the provided token is used for transactions totaling more than a specific transaction amount within a single day.

[0066] Figure 4 An exemplary system 400 is illustrated having at least some components for implementing embodiments of the present invention. Figure 4 It includes a user 101 , a user device 103 operating a service provider application 113 , a resource provider computer 106 , a transmission computer 108 , a processor server computer 110 in communication with a token repository 116 , an authorization computer 112 , and a service provider computer 114 . Figure 1 Any computing devices in (eg, user device 103, resource provider computer 106, transfer computer 108, processor server computer 110, service provider computer 114, and authorization computer 112) may communicate via any suitable communication network.

[0067] The communication network may include multiple networks for secure communication of data and information between entities. In some embodiments, the communication network may follow a suitable communication protocol to generate one or more secure communication channels between the user device 103 and the processor server computer 110. Any suitable communication protocol may be used to generate the communication channel. In some cases, the communication channel may include a "secure communication channel" that can be established using any known means, including the use of mutual authentication and session keys and the establishment of an SSL session. However, any method for creating a secure channel may be used. By establishing a secure channel, sensitive information can be securely transmitted to facilitate transactions.

[0068] User 101 (also referred to as a consumer) may be a cardholder operating a user device 103. User 101 may select one or more resource-providing entities (e.g., a merchant, a digital wallet service provider, a service provider, etc.) and provide a token associated with an account to the resource-providing entity. In some embodiments, the account may be an existing account associated with user 101. In other embodiments, user 101 may request the creation of a new account (e.g., a new card account) from authorization computer 112. In some embodiments, user 101 may conduct transactions using user device 103 using the provided token associated with an account opened with service provider application 113 or other platform associated with the selected one or more resource-providing entities.

[0069] The user device 103 may be any suitable device for conducting transactions. The user device 103 may include a memory that may store a service provider application 113 that the user device may use to conduct transactions using the service provider application 113. The user device 103 may communicate with one or more entities, including a service provider computer 114 and a processor server computer 110, over a communications network. The user device 103 may be used in transactions where a card is not presented (e.g., through a website hosted by a resource providing entity). In some embodiments, the user device 103 may also be able to communicate with an access device at a payment terminal by contact or wireless means. In some embodiments, the payment method for the transaction may include eCommerce (e-commerce), mCommerce (mobile commerce), In-app (in-app shopping), NFC (near field communication), MST (magnetic secure transmission™), TM )

[0070] Some non-limiting examples of user devices 103 may include mobile devices (e.g., cellular phones, keychain devices, personal digital assistants (PDAs), pagers, notebook computers, laptop computers, notepads, smart watches, fitness bands, jewelry, etc.), automobiles equipped with telecommunications capabilities, personal computers, payment cards (e.g., smart cards, magnetic stripe cards, etc.), etc. In some embodiments, user devices 103 may be configured to communicate with one or more cellular networks.

[0071] The service provider application 113 can be accessed by the user device 103. The service provider application 113 can be operated by the service provider computer 114. In some embodiments, the service provider application 113 can store a digital wallet and can include card account information associated with the user 101. In some cases, the digital wallet can be a mobile wallet. Some exemplary service provider applications include a wallet application, a digital wallet application, a wallet provider application, a mobile wallet application, and the like.

[0072] The service provider computer 114 can issue a service provider account for the user. In some embodiments, the service provider computer 114 can be associated with a service provider. In some cases, the service provider can be an application provider, which can be an entity that provides applications to mobile devices for use by users. In some embodiments, the service provider can be a wallet provider computer and can provide a mobile wallet or payment application (such as a wallet application) to the user device 103. The service provider computer 114 can operate a server computer that can send messages to the service provider application 113 on the user device 103 and receive messages from it. The service provider account issued by the service provider computer 114 can also be accessed through a website. In some embodiments, the service provider computer 114 can maintain one or more digital wallets for each user, and each digital wallet can be associated with payment data of one or more payment accounts. An example of a digital wallet can be Visa Checkout TM In some cases, a service provider may be referred to as a resource provider, and service provider computer 114 may be referred to as a resource provider computer.

[0073] The resource provider computer 106 can be configured to receive and process transaction data. In some embodiments, the transaction data can be received from the user device 103 or an access device in communication with the user device 103. The resource provider computer 106 can participate in transactions, sell goods or services, or provide consumers with access to goods or services. The resource provider computer 106 can accept payment data in various forms and can use various tools to conduct different types of transactions. For example, the resource provider computer 106 can also sell goods and / or services via a website or application and can accept payment over the Internet. The resource provider computer 106 can also be associated with a physical store that uses an access device that can receive transaction data for in-person transactions from the user device 103.

[0074] The transmission computer 108 is typically the system of an entity (e.g., a bank) that has a business relationship with a particular merchant or other entity. The transmission computer 108 can route authorization requests for transactions to an authorization entity computer 112 via a processor server computer 110. In some cases, the transmission computer 108 can be referred to as an acquirer computer.

[0075] The processor server computer 110 may include data processing subsystems, networks, and operations for supporting and delivering authorization services and clearing and settlement services. Examples of the processor server computer 110 include Operational The processor server computer 110 may include a wired or wireless network, including the Internet. In some embodiments, the processor server computer 110 may be a token service provider and may communicate with a token repository 116, which may store tokens associated with the accounts of the users 101. In some cases, the processor server computer 110 may also be referred to as a payment processing server computer.

[0076] The token repository 116 may include any information related to tokens. For example, the token repository 116 may store tokens associated with the service provider application 113 and a mapping of these tokens to their associated accounts. The token repository 116 may include any sensitive information associated with the tokens (e.g., account numbers). In some embodiments, the processor server computer 110 may communicate with the token repository 116 to de-tokenize the tokens. In some cases, the token repository 116 may reside on the processor server computer 110.

[0077] Authorization computer 112 may be a computer that participates in the authorization process. In some embodiments, authorization computer 112 may be run by an entity that can issue accounts. When a transaction involves an account issued by authorization computer 112, authorization computer 112 may verify the account and respond to transmitting computer 108 with an authorization response message, which may be forwarded to an access device (if applicable). Some systems may perform the functions of both authorization computer 112 and transmitting computer 108.

[0078] Upon receiving a request for a new account from user 101 via user device 103, authorization computer 112 may approve user 101 and prompt user 101 to select a resource providing entity with which to use the new account. In some embodiments, authorization computer 112 may communicate with processor server computer 110 to request tokenization of the newly approved account. In some embodiments, authorization computer 112 may be an issuer computer associated with an authorization entity (e.g., an issuing bank) that issues payment (credit / debit) cards, account numbers, or payment tokens for transactions.

[0079] At a later time (eg, at the end of the day), a clearing and settlement process may occur between the transfer computer 108 , the processor server computer 110 , and the authorization computer 112 .

[0080] Any computing device (e.g., user device 103, resource provider computer 106, transfer computer 108, processor server computer 110, service provider computer 114, and authorization computer 112) may include a processor and a computer-readable medium including code that is executable by the processor to perform the functions described herein.

[0081] Embodiments of the present invention can provide tokens to resource providing entities. There are several configurations of systems and computers, e.g. Figure 4 As described in , it can be used to complete the provision of tokens. One exemplary case may include a one-to-many implementation, and another exemplary case may include a one-to-one implementation, which will be described in more detail below.

[0082] Embodiments of the present invention may implement a one-to-many implementation where the authorization computer may be integrated with multiple resource providing entities through a single connection to a token provider, which may be a processor server computer. Figure 4 Although not explicitly shown, the processor server computer 110 can communicate with multiple resource providing entities that participate in the tokenization program. Once the authorization computer 112 requests, the processor server computer 110 can provide tokens to multiple resource providing entities. Figure 5 and Figure 6 The description of FIG. 1 describes an exemplary one-to-many implementation in more detail.

[0083] Figure 5 A block diagram 500 is shown for an exemplary system implementing a one-to-many implementation according to an embodiment of the present invention. Figure 5 The processor server computer 510 includes a plurality of authorization computers 512 in communication with the processor server computer 510. In some embodiments, the processor server computer 510 may be a token provider or a token service provider. Each authorization computer 512 may have a plurality of authorization computers 512 in communication with the processor server computer 510. Figure 4 The processor server computer 510 may have features similar to those described for the authorization computer 112 of FIG. Figure 4 The processor of the server computer 110 has features similar to the features described above.

[0084] The processor server computer 510 is capable of communicating with multiple resource providing entities. In some cases, upon request by any one of the authorization computers 512, the processor server computer 510 can provide a token to any one of the multiple resource providing entities. The resource providing entities may include those associated with the following: service provider computer 501, issuer digital wallet provider computer 502, third party digital wallet provider computer 503, merchant computer 504, and networking device 505. The service provider computer 501 can be associated with any service provider that can store and use tokens for transactions. In some embodiments, the service provider computer 501 can be a provider of services (e.g., Visa Checkout) associated with the processor server computer 510. TM) The issuer digital wallet provider computer 502 can enable accounts issued by the authorized computer to have digital wallets. The third-party digital wallet provider computer 503 can be associated with a third party that provides a digital wallet, and the digital wallet can store multiple accounts. The digital wallets provided by the issuer digital wallet provider computer 502 and the third-party digital wallet provider computer 503 can use tokens for transactions performed using the digital wallets. The merchant computer 504 can be associated with a merchant, which enables transactions using tokens. In some cases, the merchant computer 504 can store archived accounts with information related to the tokens. The networked device 505 can be any suitable device that can communicate with other computing devices and can store data. In some embodiments, the networked device 505 can be referred to as an IoT device (Internet of Things device), which can include a wearable device that can be used to conduct transactions using tokens.

[0085] In a one-to-many implementation, you can execute Figure 6 An exemplary process is shown in flowchart 600 . Figure 6 The user device 601 may be in communication with the authorization computer 612, the processor server computer 610, and the resource provider computer 615. Figure 4 The authorization computer 612 may have features similar to those described for the user device 103 in FIG. Figure 4 The authorized computer 112 and Figure 5 The processor server computer 610 may have features similar to those described for the authorization computer 512 of FIG. Figure 4 The processor server computer 110 and Figure 5 The resource provider computer 615 may have similar features to those described with reference to the processor server computer 510. Figure 4 The resource provider computer 106 and Figure 5 The resource provider computers 501-505 may have similar features to those described above.

[0086] In step S61, a user device 601 operated by a user may communicate with an authorization computer 612. In some embodiments, the user device 601 may run an application hosted by the authorization computer 612. In other embodiments, the user device 601 may run a browser for a website hosted by the authorization computer 612. From within the application or browser, the user may send a request for a token associated with their account (e.g., a new or existing account) to a plurality of selected resource providing entities. The resource providing entities may also be referred to as token requestors.

[0087] In step S62, the authorization computer 612 may communicate with the processor server computer 610 to request a token. The processor server computer 610 may be a service provider that provides tokenization services. The processor server computer 610 may generate a token for each of a plurality of resource providing entities.

[0088] In step S63, the processor server computer 610 can communicate with the resource provider computer 615. The resource provider computer 615 can be associated with one of the multiple selected resource providing entities. In some cases, the processor server computer 610 can send a token generated for the resource providing entity (associated with the resource provider computer 615) to the resource provider computer 615. Before providing the token, an authorization process can be performed between the user and the resource provider computer 615. Various authentication methods can be used in one-to-many implementations.

[0089] One authentication method may be direct provisioning. In this case, existing integration between the authorization computer 612 and the processor server computer 610 (e.g., Security Assertion Markup Language) may be utilized. The processor server computer 610 may provide a service that facilitates account creation and loads the authentication information of the resource providing entity. In an exemplary case, the service provided by the processor server computer 610 may be Visa Checkout TM When a user requests a token, they can access their Visa Checkout account through an application or website hosted by the authorization computer 612. TM Account for authentication.

[0090] Another exemplary authentication method for a one-to-many implementation may utilize a pop-up display or the like. For example, when a user utilizes an application or website hosted by the authorization computer 612 to request a token, a lightbox display may appear. The lightbox display may be pre-populated with information related to the user. In some cases, the lightbox display may prompt the user to enter or create a password for an account or profile associated with the resource provider computer 615 to which the token will be provided.

[0091] In steps S64 and S65, the resource provider computer 615 may send information confirming that the token has been provided. In some embodiments, the information may be sent to the authorization computer 612 via the processor server computer 610. Figure 6 A single resource provider computer 615 is shown, but it is understood that the authentication process and token provisioning process may be performed for each of a plurality of resource providing entities selected by the user.

[0092] The one-to-many implementation described above also allows the authorization computer to select preferences related to authentication through a single platform, which is convenient. This preference configuration can occur at any time. For example, the authorization computer 612 can log in to an account hosted by the processor server computer 610. The authorization computer 612 can select a channel (e.g., application, browser, etc.) that can implement push provisioning of tokens. The authorization computer 612 can also select supported authentication methods (e.g., Visa Checkout). TM , lightbox display, etc.). The authorization computer 612 can view a list of all resource providing entities (e.g., token requestors) that are compatible with push provisioning of tokens based on the selected channel and authentication method. In some embodiments, the authorization computer 612 can also view other information, such as the reason why push provisioning cannot be supported for some resource providing entities (e.g., incompatible channels or authentication methods). The one-to-many implementation enables the authorization computer to easily "opt in" to the tokenization program without having to interact with multiple resource providing entities.

[0093] In some embodiments, the processor server computer 610 can determine the authentication methods and authentication channels supported by the authorization computer 612, and compare the authentication methods and authentication channels supported by the authorization computer 612 with the authentication methods and authentication channels supported by the resource providing entity to determine whether the resource providing entity is provided to the user for selection. If the authentication methods and authentication channels of the compared authorization computer and resource providing entity match, the processor server computer 610 can notify the authorization computer 612 of the resource providing entity. Subsequently, the authorization computer 612 can then prompt the user for a list of participating resource providing entities including the resource providing entity. In some embodiments, this comparison process can be performed for each participating resource providing entity in the list of participating resource providing entities.

[0094] Embodiments of the present invention can also implement another implementation, which can be referred to as a one-to-one implementation. The one-to-one implementation can enable the authorization computer to directly integrate with the resource providing entity individually. For example, the authorization computer can provide tokens to each resource providing entity individually based on a standard or proprietary API (e.g., a push provisioning API) (e.g., associated with a processor server computer). Figure 7 and Figure 8 An exemplary one-to-one implementation is described in more detail.

[0095] Figure 7 A block diagram 700 is shown of an exemplary system for implementing a one-to-one implementation according to an embodiment of the present invention. Figure 7 The authorized computer 710, the authorized computer 711 and the authorized computer 712 are included. Each authorized computer 710, 711, 712 may have a Figure 4Features similar to those described for the authorized computer 112 in . Figure 7 Also included are a resource provider computer 720, a resource provider computer 721, and a resource provider computer 722. Each resource provider computer 720, 721, 722 may have a Figure 4 For simplicity, the resource provider computer 106 has similar features to those described above. Figure 7 Only three authorization computers and three resource provider computers are shown in FIG. However, the embodiment is not limited thereto, and there can be any number of authorization computers and resource provider computers in a one-to-one implementation.

[0096] exist Figure 7 In the illustrated one-to-one implementation, each authorization computer can be directly integrated with each resource provider computer (e.g., token requestor). Thus, there can be no intermediate entity, such as a processor server computer, that handles all tokenization. This can provide the ability to integrate with each resource provider computer, performing such integration based on either a standard (e.g., associated with a processor server computer) or a proprietary push provisioning API specific to the resource provider computer.

[0097] In a one-to-one implementation, one can perform Figure 8 The exemplary process is shown in flowchart 800 of . Figure 8 The user device 801 may be in communication with the authorization computer 812, the resource provider computer 815, and the processor server computer 810. Figure 4 The authorization computer 812 may have features similar to those described for the user device 103 of FIG. Figure 4 The authorized computer 112 and Figure 7 The processor server computer 810 may have features similar to those described for any of the authorized computers 710-712 of FIG. Figure 4 The resource provider computer 815 may have similar features to those described for the processor server computer 110 of FIG. Figure 4 The resource provider computer 106 and Figure 7 The resource provider computers 720-722 may have similar characteristics to those described above for any one of the resource provider computers 720-722.

[0098] In step S81, a user device 801 operated by a user may communicate with an authorization computer 812. In some embodiments, the user device 801 may run an application hosted by the authorization computer 812. In other embodiments, the user device 801 may run a browser for a website hosted by the authorization computer 812. From within the application or browser, the user may send a request for a token associated with their account (e.g., a new or existing account) to a plurality of selected resource providing entities. The resource providing entities may also be referred to as token requestors.

[0099] In step S82, the authorization computer 812 can communicate with the resource provider computer 815 to request that a token be provided to the resource provider computer 815. The resource provider computer 815 can be associated with one of the plurality of resource providing entities selected by the user. In some embodiments, an authentication process can be performed between the user and the resource provider computer 815.

[0100] One authentication method may include redirecting the user to a channel associated with a resource providing entity. For example, the user may be redirected from an application or browser hosted by the authorization computer 812 to an application or website hosted by the resource provider computer 815. In some embodiments, a web page may be displayed prompting the user to enter information to complete the account creation or authentication process. For example, the user may create or enter a password for their account or profile hosted by the resource provider computer 815.

[0101] Another type of authentication method may include sending a message to enable the second user to log in to an account or create an account at the resource provider entity. For example, in some cases, the user may want to provide a token to the second user's account (e.g., a family member's account, an employee's account, etc.). In some embodiments, the user can enter a channel identifier associated with the second user (e.g., an email address, a phone number, etc.), and the authorization computer 812 can send a message to the second user via the channel associated with the channel identifier (e.g., an email, a text message, etc.). The message may include a link that can direct the second user to an application or website hosted by the resource provider computer 815, which can prompt the second user to enter information to log in or create an account. For example, the second user can create or enter a password for their account or profile hosted by the resource provider computer 815.

[0102] In step S83, the resource provider computer 815 may request a token from the processor server computer 810. In some cases, before a token can be generated, the resource provider computer 815 may confirm with the processor server computer 810 that the user or second user is authenticated based on information provided by the user.

[0103] At step S84, the processor server computer 810 may generate a token and provide the token to the resource provider computer 815. The processor server computer 810 may generate a token suitable for the resource provider computer 815 and send it to the resource provider computer 815.

[0104] In step S85, the resource provider computer 815 may send a message confirming that the token was provided. In some embodiments, the user may be redirected back to the application or website hosted by the authorization computer 812. Figure 8 Shown is a single resource provider computer 815, but it is understood that the authentication process and token providing process can be performed for each of a plurality of resource providing entities selected by the user. In the one-to-one embodiment, each authentication process performed can be specific to each resource provider computer.

[0105] Figures 9 to 12 Flowcharts illustrating exemplary methods that may be performed according to embodiments of the present invention are provided. However, it is understood that additional methods and processes may be included in these methods and may be identified by one of ordinary skill in the art based on the description below. Furthermore, in some embodiments of the present invention, the methods may be combined, mixed, and matched as will be appreciated by one of ordinary skill in the art.

[0106] For example, according to an embodiment of the present invention, Figure 9 and Figure 12 Some of the steps described in can be modified to implement different use cases. For example, although Figure 9 and Figure 12 This involves providing account information associated with a newly issued card account, but a similar process can be applied to existing card accounts. In this case, the step of applying for a new card can be omitted. Instead, the process can begin with the user's user device running an application or browser hosted by the authorization computer 912, which may already store information about the existing account.

[0107] Please refer to Figure 9 A method according to an embodiment of the present invention is described. Figure 9 A flow chart 900 illustrates a method for immediately providing card access and providing a token to a resource providing entity once a user is approved for use, according to an embodiment of the present invention. Figure 9The system includes a user device 903 operated by a user, a resource provider computer 906 associated with a resource-providing entity, a processor server computer 910, an authorization computer 912 associated with an authorization entity, and a service provider computer 914. In some embodiments, the authorization computer 912 may also be referred to as an issuer computer, the service provider computer 914 may also be referred to as a digital wallet provider, and the resource provider computer 906 may be referred to as a merchant computer. In some cases, the user may already have an account on file with the resource provider computer 906. The processor server computer 910 may also be a token service provider.

[0108] In step 1, resource provider computer 906 may send a request to processor server computer 910 to sign up for tokenization. This signing process can occur at any time prior to a transaction. A resource-providing entity associated with resource provider computer 906 may request processor server computer 910 to participate in a tokenization transaction, in which a user may use a token when making payments to the resource-providing entity. Upon receiving the request, processor server computer 910 may store information identifying the resource-providing entity as a participating resource-providing entity.

[0109] In step 2, the user can apply for a new card account using their user device 903. In some embodiments, the user can receive a prompt to create a new card (e.g., via email, text message, etc.). The prompt can include a link that the user can activate to initiate the request for a new card. The user can activate the link (e.g., by clicking on it), which can launch an application (e.g., a banking application) on the user device 903. In some embodiments, the application can be hosted by the authorization computer 912. The application can display a user interface requesting the user to enter information for creating a new card account with an authorized entity associated with the authorization computer 912. The user can enter the user information into the user device 903.

[0110] In step 3, the user device 903 may send a request for a new card account (including information entered by the user) to the authorization computer 912. In some embodiments, the information may include user information, such as name, address, and other contact information about the user.

[0111] In step 4, the authorization computer 912 may approve the user based on the information entered. If the authorization computer 912 approves the user, the authorization computer 912 may issue a new card to the user. The authorization computer 912 may generate card account information for the new card requested by the user. In some embodiments, the card account information may include an account identifier (e.g., an account number), an expiration date, a card verification value (CVV), and other transaction information that may be used for the transaction.

[0112] In step 5, the authorization computer 912 may send the card account information and user information of the new card to the processor server computer 910. The information may be sent in any suitable manner, such as an electronic message sent over a communication network. The processor server computer 910 may be a token service provider.

[0113] In step 6, the processor server computer 910 may notify the authorization computer 912 of a list of participating resource-providing entities that have signed up for tokenization. In this exemplary case, the resource provider computer 906 and the service provider computer 914 may be associated with the participating resource-providing entities. In some embodiments, the resource provider computer 906 may also be referred to as a merchant computer, and the service provider computer 914 may also be referred to as a digital wallet provider computer. Furthermore, in some embodiments, the processor server computer 910 may notify the authorization computer 912 of a list of entities with pre-existing tokens, and therefore, the processor server computer 910 already has an account on file associated with the user. This may enable immediate association with a pre-existing token associated with the user.

[0114] In step S7, the authorization computer 912 may prompt the user to select from participating resource providing entities using the new card. For example, the authorization computer 912 may prompt the user using a user interface displayed on the user device 903 (e.g., including a list, tiled display options, etc.), which includes participating resource providing entities that have signed tokens. In some embodiments, the authorization computer 912 may also provide pre-selected resource providing entities corresponding to those resource providing entities with which the user already has an archived account (e.g., a token). However, if the user does not want to use a new card for any pre-selected resource providing entity, the user may deselect any pre-selected resource providing entity. Therefore, the resource providing entity options provided to the user may be resource providing entities with which the user may or may not have an archived account. Although Figure 9 The authorization computer 912 is shown communicating directly with the user device 903, but the embodiments are not so limited. For example, the authorization computer 912 can send communications to the user device 903 indirectly through another computer (such as the processor server computer 910).

[0115] In step S8, the user can select one or more resource providing entities from the received list. By any suitable interaction with the user interface displayed on the user device of the user, the selection can be indicated. For example, the user can confirm its selection by clicking a software or hardware button (such as a check box, tile display, etc.), inputting a voice command or other suitable methods. In an exemplary case, the user can select the resource providing entity associated with the resource provider computer 906 and the resource providing entity associated with the service provider computer 914. Although in the exemplary case described in the flow chart 900, the user has selected two resource providing entities, in other embodiments, the user can select the resource providing entity of any appropriate number. The user device 903 can send the selection of one or more resource providing entities to the processor server computer 910, requesting that the token associated with the user's account be issued to the selected one or more resource providing entities.

[0116] In some embodiments, the processor server computer 910 may verify the communication sent from the user device 903 in step 8. The processor server computer 910 may perform the verification process based on information related to the user operating the user device 903 or the user device 903. For example, in step 8, the user device 903 may send an identifier (e.g., a transaction identifier) ​​and a selection of one or more resource providing entities. In some cases, the identifier may be generated by the user device 903 or the authorization computer 912 hosting the application on the user device 903. In some embodiments, the identifier may be generated based on any combination of a device identifier, a timestamp, user information, an IP address, or other information. The processor server computer 910 may check whether the identifier received from the user device 903 in step 8 matches an identifier previously received from the user device 903 (e.g., in step 3) or the authorization computer 912 (e.g., in step 5).

[0117] In step 9, the processor server computer 910 may tokenize the new card. The processor server computer 910 may generate one or more tokens associated with the account of the new card, which may be used by the user for transactions. The processor server computer 910 may communicate with a token repository, which may store one or more tokens, a mapping between one or more tokens and the account of the new card issued to the user, and any other information related to the tokens. During a transaction, the processor server computer 910 may receive one or more tokens and, based on the information in the token repository, may detokenize the tokens so that the transaction can be applied to the appropriate account associated with the tokens.

[0118] The processor server computer 910 can determine a token for each selected resource providing entity. Determining the token can include generating the token or identifying the token if it has already been pre-generated. For example, the processor server computer 910 can determine a first token to be provided to the service provider computer 914 and a second token to be provided to the resource provider computer 906. Both the first token and the second token can be associated with the newly issued card via the authorization computer 912. In the exemplary flowchart 900, the user may already be registered with the service provider computer 914 and have an account on file with the resource provider computer 206.

[0119] At step 10, the processor server computer 910 may send the user information and the first token to a service provider computer 914. The service provider computer 914 may be associated with a wallet provider selected by the user, which is supported by an authorization entity associated with the authorization computer 912. The user information and the first token may be sent in any suitable manner, such as an electronic message sent over a communication network.

[0120] In step 11, the service provider computer 914 may authenticate the user. In some embodiments, the service provider computer 914 may perform the authentication process using background processing without requesting input from the user, such as checking whether the received user information matches the information already stored in the system and associated with the user. Figure 6 More details about an exemplary authentication process are described.

[0121] At step 12, the service provider computer 914 may store the received user information and the first token. The service provider computer 914 may store the first token so that it is associated with the newly issued card and the user information. Thus, the first token may be provided directly to the service provider computer 914 from the mobile banking application operated by the user.

[0122] In step 13, the processor server computer 910 can send the user information and the second token to the resource provider computer 906. The resource provider computer 906 can be associated with the resource providing entity (e.g., a merchant) selected by the user. The user information and the second token can be sent in any suitable manner, such as an electronic message sent over a communication network.

[0123] In step 14, the resource provider computer 906 may authenticate the user. In some embodiments, the resource provider computer 906 may perform the authentication process using background processing without requesting input from the user, such as checking whether the received user information matches the information already stored in the system and associated with the user. Figure 6 More details about an exemplary authentication process are described.

[0124] At step 15, the resource provider computer 906 may store the received user information and the second token. The resource provider computer 906 may store the second token so that it is associated with the newly issued card and the user information. Thus, the second token may be provided directly to the resource provider computer 906 from the mobile banking application operated by the user. In some embodiments, the second token may also be stored in association with other accounts on file that the user already has on the resource provider computer 906 (e.g., including pre-existing tokens).

[0125] In some embodiments, steps 10 through 12 and steps 13 through 15 described above may be initiated simultaneously or in a different order than that shown in flowchart 900. For example, processor server computer 910 may send information to resource provider computer 906 in step 13, followed by steps 14 and 15, before sending the information to service provider computer 914 in step 10 (followed by steps 11 and 12), or may send the information to resource provider computer 906 and service provider computer 914 simultaneously.

[0126] In step 16, the user can use his user device 903 to conduct a transaction using the newly provided token. For example, the user can access his digital wallet associated with the service provider computer 914 (for example, through a wallet application) and use the first token to make a purchase with the digital wallet. In addition, the user can access an online website associated with the resource provider computer 906 and use the second token to make another purchase. In subsequent purchases, the user can use the first token and the second token. Therefore, the token can be provided when the card is issued, which allows the user to immediately access and use the token to conduct transactions, including archiving accounts with merchants. This is very efficient, consumes the least effort from the user, and provides the user with more flexibility. Moreover, the use of tokenization can achieve the security of transactions because sensitive data is shielded.

[0127] The following provides a specific example scenario in which the steps of flowchart 900 may be performed. A user may be operating a user device and may receive a notification regarding a new card via email. The user may click on the notification, which may launch a mobile banking application on their user device. The user may enter user information to apply for a new card, which is then sent to the issuer hosting the application by pressing an "Apply" button. The issuer may approve the user, and the new card may be issued to the user.

[0128] Subsequently, the user may be prompted to add the newly issued card (e.g., token) to participating resource providing entities. The user may be presented with a user interface including a list of resource providing entity names (e.g., suppliers, retailers, digital wallet providers, etc.). The user may select one or more resource providing entities by clicking on one or more resource providing entities indicated on the list. The user may select a digital wallet provider and a merchant, with whom the user may already have an account. A first token may be generated and pushed to the user's digital wallet provider account associated with the selected digital wallet provider, and a second token may be generated and pushed to the user's merchant account associated with the selected merchant.

[0129] The provided token is then immediately available to the user. For example, a user might go to a store and buy a drink. The user can use their user device to access their digital wallet provider account, paying for the drink with the newly issued card's account. Alternatively, the user can use the same user device or another device to make an online purchase with their merchant account. When the user checks out for their purchase, the newly issued card may already be provided, allowing the user to select it from a list of other accounts the user already has on file with the merchant. In other cases, account information (e.g., token) may be pre-filled on the checkout page. The user can then use the newly issued card to pay for the purchase.

[0130] As described above, the user can use their new card for transactions conducted at a physical POS (point of sale) terminal as well as for transactions conducted remotely. For example, the user can use their new card to pay for a transaction through a contactless transaction with an access device at a merchant. In addition, the user can use their new card account to pay for e-commerce transactions. Thus, the user device can be any suitable device capable of conducting both types of transactions. Some exemplary payment methods may include eCommerce (e-commerce), mCommerce (mobile commerce), In-app (in-application shopping), NFC (near field communication), MST (magnetic secure transmission), and the like. TM ).

[0131] As mentioned above with Figure 9 As noted in the related description, embodiments of the present invention enable multiple tokens to be provided to multiple resource providing entities. However, it is to be understood that Figure 9 An exemplary case is depicted in which two tokens are provided to two resource providing entities, but this is not limiting. For example, embodiments of the present invention can enable one or more tokens to be provided to one or more resource providing entities. In some embodiments, more than one token can be provided to a single resource providing entity.

[0132] Although the above Figure 9The relevant description describes an exemplary use of the present invention, but the embodiments are not limited thereto. For example, embodiments of the present invention can also be used to provide tokens associated with a user's existing cards, not just newly issued cards. Moreover, tokens (e.g., associated with a user's existing cards and newly issued cards) can be provided to resource providing entities that may participate in the tokenization program, which may not be archived account merchants. Therefore, tokens can be used for a variety of different transaction types (e.g., recurring, one-time, on-demand, etc.). In some embodiments, tokens can also be pushed to other devices indicated by the user (e.g., mobile devices, tablets, wearable devices, etc.).

[0133] Embodiments of the present invention may provide several advantages. For example, embodiments of the present invention improve efficiency because users no longer need to wait to receive a plastic card in order to use a new card account. Once approved by the issuer, the new card can be made available immediately, with minimal user input on their mobile device. This eliminates the need for users to manually set up accounts with multiple resource-providing entities, which can be repetitive and cumbersome. In some cases, embodiments of the present invention may make users more willing to use new cards from new resource-providing entities (including digital wallet services and merchants) in addition to resource-providing entities with which they already have accounts on file, as tokens for newly issued cards can be easily provided with minimal user effort. Furthermore, embodiments of the present invention enable users to proactively create, view, and manage their tokens, giving users control, security, flexibility, and the ability to better track their credentials. With respect to the processor server computer, embodiments of the present invention also provide several advantages. For example, by leveraging the token service capabilities provided by the processor server computer, the need for a third party to establish and manage any token repositories can be eliminated, which may not be efficient or secure.

[0134] Below with Figure 10-12 The corresponding description describes an exemplary method according to an embodiment of the present invention, but is not intended to be limiting. For example, although the description is about providing a token to a service provider computer, which may be a digital wallet provider, the embodiments are not so limited. Similar processes can be performed on any resource provider computer associated with a resource providing entity (e.g., a merchant, a digital wallet provider, a service provider, etc.). For example, in Figure 10-12 The service provider computer in can be replaced by a resource providing computer.

[0135] You can refer to Figure 10 A method according to an embodiment of the present invention will be described. Figure 10A flowchart 1000 is shown of a method for enabling a user to immediately access a card upon approval according to an embodiment of the present invention, including a user 201, a processor server computer 210, an authorization computer 212 associated with an authorization entity, and a service provider computer 214. In some embodiments, the processor server computer 210 may also be a token service provider. Any communications sent to and received from the user 201 may be made via a user device operated by the user 201, such as Figure 4 In some embodiments, the processor server computer 210 may also be referred to as a payment processor server computer or a payment processing network, the authorization computer 212 may also be referred to as an issuer computer, and the service provider computer 214 may also be referred to as a resource provider computer. In the exemplary case described below, the service provider computer 214 may be a wallet provider computer.

[0136] In step 1, user 201 applies for a new card using their user device. For example, user 201 may be shopping online using their user device on a merchant's website and may see an advertisement offering a discount for checking out with a card issued by an issuer associated with authorization computer 212. User 201 may click on the advertisement, which redirects user 201 to a website associated with an authorization entity and hosted by authorization computer 212. The website may display a user interface requesting user 201 to enter information for creating a new card from the issuer. User 201 may enter the information, which may be forwarded to authorization computer 212. In some embodiments, the information may include user data (e.g., name, address, contact information, etc.).

[0137] In step 2, authorization computer 212 may approve user 201 based on the information entered. If authorization computer 212 approves user 201, authorization computer 212 may issue a new card to user 201. Authorization computer 212 may generate card information for the new card requested by user 201. In some embodiments, the card information may include an account identifier (e.g., account number), other account information (e.g., expiration date, CVV, etc.), and transaction information that may be used for transactions. Card information may also be referred to as account information or card account information.

[0138] In step 3, authorization computer 212 may send the card information for the new card to processor server computer 210. In addition to the card information, authorization computer 212 may send cardholder information, cardholder contact information, and any additional future processing instructions. An example of a future processing instruction may be an instruction not to verify the consumer's address when the consumer creates their account. The card information and additional information may be sent in any suitable manner, such as an electronic message sent over a communications network. Processor server computer 210 may be a token service provider.

[0139] In step 4, the processor server computer 210 may activate the account associated with the new card and may tokenize the new card. For example, the processor server computer 210 may generate a token associated with the account of the new card, which can be used by the user 201 for transactions. The processor server computer 210 may communicate with a token repository, which may store tokens, mappings between tokens and the account of the new card issued to the user 201, and any other information related to the tokens. During a transaction, the processor server computer 210 may receive the token and, based on the information in the token repository, detokenize the token so that the transaction can be applied to the appropriate account associated with the token.

[0140] In step 5, the processor server computer 210 may send token information to the authorization computer 212. The token information may be any information related to the token generated by the processor server computer 210. The token information may be sent in any suitable manner, such as an electronic message sent over a communication network. In some embodiments, the processor server computer 210 may also send an access link to the authorization computer 212 along with the token information. For example, the access link may be a link that redirects the user 201 using their user device to a website or application hosted by the processor server computer 210.

[0141] In step 6, in some embodiments, the authorization computer 112 may send a confirmation that the token information has been received from the processor server computer 210. In some embodiments, the authorization computer 212 may send the user information received in step 1 to the processor server computer 210. In other embodiments, the user information may be sent along with the card information in step 3 or other appropriate steps.

[0142] In step 7, authorization computer 212 may prompt user 201 to select a wallet provider for use with the new card. For example, authorization computer 212 may prompt user 201 via a user interface (e.g., including a list, a tiled display option, etc.) displayed on a user device of user 201. Authorization computer 212 may provide user 201 with the option to select a wallet provider that supports use of the new card issued by an issuer associated with authorization computer 212. In some embodiments, user 201 may already be registered with one or more of the offered wallet providers. In other embodiments, user 201 may not be registered with one or more of the offered wallet providers.

[0143] In step 8, user 201 may select a wallet provider from the options provided by authorization computer 212. The selection may be indicated by any suitable interaction with a user interface displayed on user device 201. For example, user 201 may confirm their selection of a wallet provider by clicking a software or hardware button, entering a voice command, or other suitable method. Although, for simplicity, an exemplary case is described in flowchart 1000 in which user 201 selects a single wallet provider, in some embodiments, user 201 may select multiple wallet providers from the options provided for using a new card.

[0144] After user 201 selects a wallet provider, authorization computer 212 may redirect user 201 to processor server computer 210 so that the new card can be registered with the selected wallet provider. This redirection may be implemented in any suitable manner. For example, in one embodiment, once user 201 confirms their selection of a wallet provider, authorization computer 212 may redirect user 201 to authorization computer 212 in step 5 based on an access link provided by processor server computer 210. In another embodiment, authorization computer 212 may embed the access link in a button that user 201 clicks to confirm their selection of a wallet provider. When user 201 clicks the button, the access link may be activated, redirecting user 201 to a website hosted by processor server computer 210.

[0145] Processor server computer 210 may display information to user 201, via user device 201, that will be used to register a new card with the selected wallet provider. For example, the information may include user information and token information associated with the new card. Before registering the new card with the wallet provider, processor server computer 210 may request user 201 to verify the information. For example, user 201 may check whether the displayed information is accurate and then confirm that the information is valid. User 201 may indicate the confirmation by clicking a software or hardware button, entering a voice command, or other suitable method. In some embodiments, user 201 may verify the information before selecting a wallet provider.

[0146] In step 9, after user 201 verifies the information, processor server computer 210 may send the user information and token information to service provider computer 214. Service provider computer 214 may be associated with a wallet provider selected by user 201, which is supported by an issuer associated with authorization computer 212. The user information and token information may be sent in any suitable manner, such as an electronic message sent over a communication network.

[0147] At step 10, the service provider computer 214 may store the received information in its local system. Based on the received information, the service provider computer 214 may determine whether the user 201 has an existing account opened with the service provider computer 214. For example, the service provider computer 214 may check whether any existing accounts including the received user information (e.g., name, address, etc.) are stored in its system.

[0148] In step 11, in some embodiments, the service provider computer 214 may notify the processor server computer 210 that the received information is stored. In some embodiments, the service provider computer 214 may also notify the user 201 whether or not the user has an existing account opened at the service provider computer 214.

[0149] At step 12, the service provider computer 214 may prompt the user 201 to provide wallet provider account information. If the service provider computer 214 determines that the user 201 does not have an existing account, the service provider computer 214 may prompt the user 201 to create a new account. For example, the service provider computer 214 may prompt the user 201 to create a new username, password, and enter any other registration information (e.g., contact information) to generate a new account.

[0150] At step 13, the user 201 may enter wallet provider account information in response to a prompt from the service provider computer 214. If the user 201 is creating a new account on the service provider computer 214, the user 201 may enter a new username, password, and any other registration information to generate the new account.

[0151] At step 14, the service provider computer 214 may create a wallet provider account for the user 201. The account may be associated with the registration information entered by the user 201. Furthermore, the service provider computer 214 may link the new account to a token received by the processor server computer 210 and associated with the new card issued by the authorization computer 212. This may enable the user 201 to use the newly issued card with their wallet provider account.

[0152] In other embodiments, user 201 may already have an existing account opened with service provider computer 214. In this case, at step 12, service provider computer 214 may simply prompt user 201 to register a username and password. Furthermore, at step 13, if user 201 already has an existing account opened with service provider computer 214, user 201 may enter their registered username and password into a user interface on their user device to log in to their existing account. At step 14, service provider computer 214 may link the existing account to the token received by processor server computer 210 and associated with the new card issued by authorization computer 212.

[0153] At step 15, user 201 can use their newly issued card to proceed with the checkout process on the merchant's website. User 201 can receive the advertised discount for the transaction. Thus, user 201 can request a new card and immediately be able to use the newly issued card in their digital wallet for transactions.

[0154] Although the above embodiments describe that the user device of user 201 is used for remote transactions (e.g., e-commerce transactions, online transactions, etc.), the embodiments are not limited thereto. For example, embodiments of the present invention can be extended to transactions performed at a physical POS terminal, where the transactions can be performed using the same method as described above. Figure 10 The process is similar to the process described above. After user 201 requests a new card, the new card is then approved and linked to the digital wallet, and user 201 can use the new card at a POS terminal. For example, user 201 can use their new card to pay for a transaction through a contactless transaction with an access device at a merchant. Therefore, user 201's user device can be any suitable device capable of conducting both types of transactions.

[0155] As described above, in some embodiments, user 201 may select multiple wallet providers from among the options provided for using the new card. In this case, for each service provider selected by user 201, processor server computer 210 may transmit user information and token information to the wallet provider computer associated with each selected wallet provider. Furthermore, each wallet provider computer that receives information from processor server computer 210 may perform steps 10-12, receive information from user 201 in step 13, and further perform step 14. Thus, tokens associated with the newly issued card can be provided to multiple digital wallets of user 201, where they are immediately available for use by user 201.

[0156] A specific example case in which the steps of flowchart 1000 may be performed is provided below. A user may be shopping at a merchant's online website, where the website displays an advertisement offering the user a 25% discount on their transaction if they use a card issued by an issuer. The user may click on the advertisement and apply for a new card from the issuer, which may approve the user and send the card account information to a processor server computer. The processor server computer, which may also be a token service provider, may tokenize the card (e.g., generate a new token) and send the token information to an issuer computer associated with the issuer, along with a link that is routed to the token service of the token service provider. The issuer computer may then send the link to the user.

[0157] The token service can then verify the user and ask which wallet the user would like to register with. The user can select a wallet provider (e.g. Visa Checkout TM ), triggering the token service to send token information to Visa Checkout TM Associated servers. Merchants can accept Visa Checkout TM Transaction. Visa Checkout TM The server can then prompt the user to create a new Visa Checkout TM account or log in to an existing Visa Checkout TM The new token can then be provided to the user's Visa Checkout TM Account. Users can then use the newly issued Visa Checkout TM Card account to conduct transactions with merchants and receive an advertised 25% discount.

[0158] Another use case according to an embodiment of the present invention is described below. A user may be at a shopping mall and may see an advertisement that offers rewards (e.g., earning loyalty points) for using a card issued by a specific issuer. The user may open a wallet provider application on their mobile device. The wallet provider application may register the user with the issuer. Accordingly, the wallet provider application may collect user information from the user and send it to an issuer computer associated with the issuer indicated in the advertisement. The issuer may approve the user and send the new account information to a processor server computer, which may also be a token service provider. The processor server computer may tokenize the card and send the token back to the issuer computer. The issuer computer may send the token to the wallet provider, which may provide the token on the user's mobile device. The user may then use the mobile device to proceed with the checkout process using the rewards applicable to the advertisement. Thus, after approval by the issuer, the card may become immediately available on the mobile device.

[0159] In some embodiments, tokenization of the card account information may not be performed. Figure 10 In the case of flowchart 1000, steps 3 to 6 can be omitted. In a later step (e.g., step 9), the account number can be sent instead of the token. Even if tokenization is omitted, the user can still use the newly issued card immediately after approval by the issuer. However, tokenization can provide security benefits because the token cannot be easily linked to the actual account except through the token provider service.

[0160] You can refer to Figure 11 A method according to an embodiment of the present invention will be described. Figure 11 A flowchart 1100 illustrating a method for enabling a user to immediately access a card upon approval according to an embodiment of the present invention includes a user 301, a browser 302, an authorization computer 312 associated with an authorization entity, a processor server computer 310, and a service provider computer 314. In some embodiments, the processor server computer 310 may also be a token service provider implementing a tokenization scheme. Any communications sent to and received from the user 301 may be made via the user device, e.g. Figure 4 The user device 103 may be running a browser 302. In some embodiments, the processor server computer 310 may also be referred to as a payment processor server computer or a payment processing network, the authorization computer 312 may also be referred to as an issuer computer, and the service provider computer 314 may also be referred to as a resource provider computer. In the exemplary case described below, the service provider computer 314 may be a wallet provider computer.

[0161] In step 1, user 301 may activate a card. User 301 may enter user data into their user device, which sends the entered user data to authorization computer 312. Authorization computer 312 may approve user 301 based on the entered information. If authorization computer 312 approves user 301, authorization computer 312 may issue a new card to user 301. Authorization computer 312 may generate card information for the new card requested by user 301. In some embodiments, the card information may include an account identifier (e.g., account number), other account information (e.g., expiration date, CVV, etc.), and transaction information that may be used for transactions. Card information may also be referred to as account information or card account information.

[0162] In step 2, authorization computer 212 may register the user data with the tokenization program and send the user data and the card information for the new card to processor server computer 210. The user data may include cardholder information and cardholder contact information. In addition to the user data and card information, authorization computer 212 may send any additional future processing instructions. An example of a future processing instruction may be an instruction not to verify the consumer's address when the consumer creates their account. The user data, card information, and additional instructions may be sent in any suitable manner, such as an electronic message sent over a communication network.

[0163] In step 3, the processor server computer 310 may store the received user data and card information and activate the account of the user 301. The received user data and card information may be stored in association with the user 301, for example, in a data record of the user 301 account.

[0164] In step 4, the processor server computer 310 may register the new card into the tokenization program. The processor server computer 310 may generate a token and a token identifier for the new card. The token identifier may be a reference to a card account or token. In some embodiments, the token identifier may be specific to the wallet provider or may be a generic identifier that refers to an account number. In some embodiments, the processor server computer 310 may also generate card art for the new card.

[0165] In step 5, the processor server computer 310 may generate a wallet provider link (WP link). In some embodiments, the link may be a client wallet provider link. The wallet providers for which the processor server computer 310 generates the link may be those supported by the authorization computer 312.

[0166] In step 6, the processor server computer 310 may send a response to the authorization computer 312. The response may include a token identifier, any generated links to wallet providers, card art, and other information that may be helpful to the authorization computer 312. In some embodiments, sending multiple wallet provider links may be optional.

[0167] At step 7, the authorization computer 312 may transmit the token identifier and wallet provider link to the user 301. In some embodiments, the wallet provider link may be provided in a user interface that prompts the user 301 to select a wallet provider corresponding to one of the provided wallet provider links.

[0168] At step 8, user 301 can access the selected link received from authorization computer 312. User 301 can select a link by clicking on the link or a software button with an embedded link. Although the process describes the case of selecting a single link, in other cases, user 301 can select more than one link. In some embodiments, the selected link can be associated with service provider computer 314.

[0169] In response to user 301 accessing the link, user 301 may be directed to browser 302 at step 9. Browser 302 may open a website or application hosted by service provider computer 314.

[0170] At step 10, user 301 may access a website or application hosted by service provider computer 314. Behind the scenes, browser 302 may request any information needed to run the website or application from service provider computer 314. For example, the information may include user interface components, instructions, or other information.

[0171] In step 11, the service provider computer 314 may return the requested information to the browser 302. This may cause the browser 302 to display an appropriate page to the user 301, such as a login page.

[0172] At step 12, user 301 may be prompted to log into their account at service provider computer 314 via browser 302. User 301 may enter authentication attributes into a user interface displayed by browser 302. The authentication attributes may include a username, password, and token identifier, which may then be transmitted to service provider computer 314 at step 13.

[0173] In step 14, the service provider computer 314 may call the processor server computer 310 to pull user data associated with the user 301 and the new issuing bank. For example, the processor server computer 310 may open an application programming interface (API) so that the service provider computer 314 can pull data, which may include cardholder information, payment account information, and cardholder contact information. In some embodiments, the service provider computer 314 may use the API to request the processor server computer 310 to retrieve specific data. For example, the service provider computer 314 may provide a token identifier to the processor server computer 310 and request a token associated with the account of the user 301 from the processor server computer 310. Thus, instead of Figure 10 The processor server computer 310 is depicted pushing data to the service provider computer 314, and the flow diagram 1100 shows the service provider computer 314 calling the API of the processor server computer 310 to obtain the information.

[0174] At step 15, the processor server computer 310 may retrieve a token associated with the account of the user 301 stored in its system. At step 16, the processor server computer 310 may send the retrieved token, cardholder information, payment account information, and cardholder contact information to the service provider computer 314.

[0175] The service provider computer 314 may log the user into their wallet provider account at step 17. The service provider computer 314 may store the information retrieved in steps 14 to 16, including cardholder information, payment account information, cardholder contact information, and token information, in association with the user's 301 account.

[0176] At step 18, the service provider computer 314 may display a notification to the browser 302 that the user 301 may use their new card with the wallet provider account associated with the service provider computer 314. This may indicate that a token associated with the newly issued card is provided so that the user 301 may use their new card for subsequent transactions.

[0177] You can refer to Figure 12 A method according to an embodiment of the present invention will be described. Figure 12 A flowchart 1200 illustrating a method for enabling a user to immediately access a card upon approval according to an embodiment of the present invention includes a user 401, a browser 402, an authorization computer 412 associated with an authorization entity, a processor server computer 410, and a service provider computer 414. In some embodiments, the processor server computer 410 may also be a token service provider implementing a tokenization scheme. Any communications sent to and received from the user 401 may be made via the user device, e.g. Figure 4The user device 103 may be running a browser 402. In some embodiments, the processor server computer 410 may also be referred to as a payment processor server computer or a payment processing network, the authorization computer 412 may also be referred to as an issuer computer, and the service provider computer 414 may also be referred to as a resource provider computer. In the exemplary case described below, the service provider computer 414 may be a wallet provider computer.

[0178] Steps 1 to 11 in flowchart 1200 may be similar to Figure 11 Therefore, steps 1 to 11 are not included in the description of flowchart 1200 in order to avoid duplication of information. However, it is understood that the description corresponding to steps 1 to 11 in flowchart 1100 can be incorporated into Figure 12 1200 is described in detail.

[0179] At step 12, the browser 402 may have opened a website or application hosted by the service provider computer 414. The browser 402 may enable the user 401 to register an account on the service provider computer 414 or log into an existing account.

[0180] Accordingly, in step 13, if the user 401 does not already have an account opened on the service provider computer 414, the user 401 may create a username and password and provide any additional authentication data requested by the service provider computer 414. If the user 401 already has an account opened on the service provider computer 414, the user 401 may enter their registered username and password and any additional authentication data requested by the service provider computer 414 to access their existing account. The additional authentication data may include a token identifier associated with their new card account.

[0181] In step 14, the service provider computer 414 may call the processor server computer 310 to pull user data associated with the user 401 and the newly issued card. For example, the processor server computer 410 may open an application programming interface (API) so that the service provider computer 414 can pull data, which may include cardholder information, payment account information, and cardholder contact information. In some embodiments, the service provider computer 414 may use the API to request the processor server computer 410 to retrieve specific data. For example, the service provider computer 414 may provide a token identifier to the processor server computer 410 and request a token associated with the account of the user 401 from the processor server computer 410. Thus, instead of Figure 10The processor server computer 410 is depicted pushing data to the service provider computer 414, and the flow diagram 1200 shows the service provider computer 414 calling the API of the processor server computer 410 to obtain the information.

[0182] At step 15, the processor server computer 410 may send the cardholder information, payment account information, and cardholder contact information to the service provider computer 414. Subsequently, at step 16, the service provider computer 414 may save the received user data in the data record of the wallet provider account of the user 401.

[0183] At step 17, service provider computer 414 may send a payload including the user data to a user interface displayed on browser 402 for confirmation by user 401. For example, service provider computer 414 may send a web form to be filled out with user data associated with user 401. The form may display the user data in editable fields on the user interface so that user 401 can modify any values ​​if desired.

[0184] At step 18, user 401 can review the data sent by service provider computer 414 and update or confirm the data. User 401 can update any data by editing the fields in the user interface. Upon completion of editing, or if no further editing is required, user 401 can confirm that the data is accurate by clicking a button on browser 402. Subsequently, at step 19, browser 402 can send an instruction to service provider computer 414 that user 401 has confirmed the data for the wallet provider account. By requiring user 401 to confirm the data, service provider computer 414 ensures the accuracy of the data while eliminating the need for user 401 to enter all user data, which can be time-consuming and cumbersome.

[0185] At step 20, the service provider computer 414 may link the payload data to the wallet provider account of the user 401. For example, the service provider computer 414 may store the payload data in association with any other information related to the wallet provider account of the user 401.

[0186] At step 21, the service provider computer 414 may display a notification to the browser 402 that the user 401 may use their new card with the wallet provider account associated with the service provider computer 414. This may indicate that a token associated with the newly issued card is provided so that the user 401 may use their new card for subsequent transactions.

[0187] Embodiments of the present invention may provide several advantages. For example, embodiments of the present invention improve efficiency because users no longer need to wait to receive a plastic card in order to use a new card account. Once approved by the issuer, the new card can be immediately available with minimal user input on their mobile device. This eliminates the need for users to manually add new cards to multiple digital wallets before use. This contrasts with conventional systems, where manually adding new cards to digital wallets disrupts the user experience during transactions, such as the checkout process.

[0188] Furthermore, embodiments of the present invention enable the issuance of new cards that can be used with mobile wallets, even if the mobile wallet is not already installed on the mobile device at the time of card issuance. In other words, digital wallet providers can be selected after the new card is issued. This allows users to easily use the issued card without having to previously install a mobile wallet that must be compatible with the issuer. This is convenient because, before the new card is issued, users may not know which digital wallets are compatible with the issuer. Since the issuer's computer provides users with wallet provider options, users have the flexibility to choose from multiple wallet providers that may offer different benefits. Furthermore, embodiments of the present invention integrate tokenization processes, improving efficiency without compromising transaction security.

[0189] The computer system can be used to implement any of the above-mentioned entities or components. The subsystems of the computer system can be interconnected via a system bus. Additional subsystems may include a printer, a keyboard, a fixed disk (or other memory including a computer-readable medium), a monitor coupled to a display adapter, and other devices. Peripherals and input / output (I / O) devices coupled to an I / O controller (which may be a processor or any suitable controller) may be connected to the computer system by any number of means known in the art (such as serial ports). For example, a serial port or external interface can be used to connect a computer device to a wide area network (such as the Internet), a mouse input device, or a scanner. Interconnection via a system bus allows a central processing unit to communicate with each subsystem and control the execution of instructions from a system memory or fixed disk and the exchange of information between subsystems. The system memory and / or fixed disk may embody a computer-readable medium. In some embodiments, the monitor may be a touch-sensitive display screen.

[0190] A computer system can include multiple identical components or subsystems connected together, for example, via external or internal interfaces. In some embodiments, the computer systems, subsystems, or devices can communicate via a network. In this case, one computer can be considered a client and the other a server, where each computer can be part of the same computer system. The client and server can each include multiple systems, subsystems, or components.

[0191] It should be understood that any embodiment of the present invention can be implemented in a modular or integrated manner using hardware (e.g., an application specific integrated circuit or a field programmable gate array) and / or computer software in the form of control logic with the aid of a general-purpose programmable processor. As used herein, a processor includes a single-core processor, a multi-core processor on the same integrated chip, or multiple processing units or networks on a single circuit board. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will know and appreciate other ways and / or methods of implementing embodiments of the present invention using hardware and a combination of hardware and software.

[0192] Any software component or functionality described in this application may be implemented as software code 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, traditional 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 including random access memory (RAM), read-only memory (ROM), magnetic media such as a hard drive or floppy disk, or optical media such as a compact disc (CD) or DVD (digital versatile disc), flash memory, etc. The computer-readable medium may be any combination of these storage or transmission devices.

[0193] Alternatively, the computer readable medium of embodiment of the present invention can be used to encode and transmit such a program by the carrier signal that is suitable for wired, optical and / or wireless network transmission that meets various protocols (comprising the Internet).Therefore, the data signal with this program encoding can be used to create according to the computer readable medium of embodiments of the present invention.The computer readable medium utilizing program code encoding can utilize compatible device to encapsulate, or can provide (such as downloading by the Internet) separably with other devices.Any such computer readable medium can reside on or inside a single computer product (such as hard disk drive, CD or whole computer system), and can be present on or inside the different computer products in system or network.Computer system can comprise monitor, printer, or be used to provide other suitable displays of any result mentioned herein to the user.

[0194] The above description is illustrative and non-restrictive. After reading this disclosure, many variations of the present invention will become apparent to those skilled in the art. Therefore, the scope of the present invention should not be determined with reference to the above description, but should be determined with reference to the pending claims and their full scope or equivalents.

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

[0196] Unless expressly indicated to the contrary, the use of "a," "an," or "the" is intended to mean "one or more."

[0197] All patents, patent applications, publications, and descriptions mentioned above are incorporated herein by reference in their entirety for all purposes. No admission is made that they are prior art.

Claims

1. A method comprising executing the following steps by a resource providing entity computer associated with a resource providing entity: Before receiving a request from a user to conduct a transaction: receiving a payment token and user identification information associated with the payment token directly from a server computer, wherein the payment token is an identifier of the account that replaces a real account identifier associated with an account of the user; storing the payment token in association with the user's account on file at a storage device accessible by a computer of the resource providing entity; receiving the request to conduct the transaction from a user device of the user; identifying a payment token associated with the user; as well as Processing the transaction using the payment token, wherein processing the transaction comprises: generating a transaction authorization request message including the payment token; transmitting the transaction authorization request message to the server computer; and A transaction authorization response message is received from the server computer indicating whether the transaction is authorized.

2. The method according to claim 1, further comprising: Prior to receiving the payment token from the server computer: receiving authentication information from the user device; executing an authentication method using the authentication information to authenticate the user; as well as The results of the authentication method are provided to the server computer.

3. The method according to claim 1, further comprising: Prior to receiving the payment token from the server computer: The payment token is requested from the server computer.

4. The method according to claim 1, further comprising: Prior to receiving the payment token from the server computer: A request is transmitted to the server computer to participate in a tokenization program, the tokenization program being provided by an entity associated with the server computer.

5. The method according to claim 1, further comprising: retrieving a list of payment tokens associated with the user from a storage device accessible by the resource providing entity computer; providing the user with a list of payment tokens associated with the user; receiving a selection of the payment token from the user device; The transaction is processed using the payment token.

6. The method of claim 1 , wherein the transaction is an electronic transaction, the method further comprising: A checkout page associated with the electronic transaction is provided, wherein payment information associated with the payment token is pre-filled on the checkout page by the resource providing entity computer. The method according to claim 1 , wherein the transaction is initiated at a transaction terminal of the resource providing entity.

8. The method according to claim 1, further comprising: determining that the user already has an existing archived account; or Before storing the payment token, a new archive account is generated for the user.

9. The method according to claim 1, further comprising: Authentication information associated with the user is received from the server computer.

10. A resource providing entity computer associated with a resource providing entity, the resource providing entity computer comprising: processor; as well as A computer-readable medium coupled to the processor, the computer-readable medium comprising code executable to perform a method comprising: Before receiving a request from a user to conduct a transaction: receiving a payment token and user identification information associated with the payment token directly from a server computer, wherein the payment token is an identifier of the account that replaces a real account identifier associated with an account of the user; storing the payment token in association with the user's account on file at a storage device accessible by a computer of the resource providing entity; receiving, from a user device of the user, a request to conduct a transaction using the user's account on file; and Processing the transaction using the payment token, wherein processing the transaction comprises: generating a transaction authorization request message including the payment token; transmitting the transaction authorization request message to the server computer; and A transaction authorization response message is received from the server computer indicating whether the transaction is authorized.

11. The resource providing entity computer according to claim 10, wherein the method further comprises: Prior to receiving the payment token from the server computer: receiving authentication information from the user device; executing an authentication method using the authentication information to authenticate the user; as well as The results of the authentication method are provided to the server computer.

12. The resource providing entity computer according to claim 10, wherein the method further comprises: Prior to receiving the payment token from the server computer: The payment token is requested from the server computer.

13. The resource providing entity computer according to claim 10, wherein the method further comprises: Prior to receiving the payment token from the server computer: A request is transmitted to the server computer to participate in a tokenization program, the tokenization program being provided by an entity associated with the server computer.

14. The resource providing entity computer according to claim 10, wherein the method further comprises: retrieving a list of payment tokens associated with the user from a storage device accessible by the resource providing entity computer; providing the user with a list of payment tokens associated with the user; receiving a selection of the payment token from the user device; The transaction is processed using the payment token.

15. The resource providing entity computer according to claim 10, wherein the transaction is an electronic transaction, and wherein the method further comprises: A checkout page associated with the electronic transaction is provided, wherein payment information associated with the payment token is pre-filled on the checkout page by the resource providing entity computer.

16. The resource providing entity computer according to claim 10, wherein the transaction is initiated at a transaction terminal of the resource providing entity.

17. The resource providing entity computer according to claim 10, wherein the method further comprises: determining that the user already has an existing archived account; or Before storing the payment token, a new archive account is generated for the user.

18. The resource providing entity computer according to claim 10, wherein the method further comprises: Authentication information associated with the user is received from the server computer.

Images