Patent Description:
<CIT> discloses a verification system that includes a memory storing a common identifier that identifies a user. The system also includes one or more hardware processors coupled to the memory and configured to read instructions from the memory to perform the steps of: receiving a token associated with a request to complete a transaction with an environment; determining the common identifier associated with the token, the common identifier being associated with an identifier of the merchant, an identifier of the user requesting the transaction, and a funding instrument associated with the user; and determining, based on information associated with the common identifier, whether to approve the transaction. <CIT> relates to a system for generating payment tokens. Upon receiving a request for generating a payment token, the system encodes contextual information of a transaction (e.g. transaction channel, geolocation information, device fingerprint) related to the token request into the payment token. <CIT> discloses a payment system wherein a user may use a mobile payment device for performing transactions with a merchant. The payment device provides a set of wallets comprising one or more tokens that can be used for payment transactions. Each token may be associated with specific payment limits and comprise routing information for routing the token through the card association network to the issuing financial institution. <CIT> relates to a system for generating transaction tokens that may be associated with financial accounts of users, user devices and a merchant server. In addition, token usage rules may be defined for individual token, such geographical restrictions, allowed or forbidden products and payment limits. <CIT> discloses a payment method which provides a transactable payment token and a non-transactable payment token that are associated with a primary account identifier to an access device for performing a payment transaction. When authorizing a payment, the transactable payment token is replaced by the primary account identifier in the authorization request message and when an authorization response message is received, the primary account identifier is substituted by the transactable and non-transactable payment tokens. <CIT> relates to a system for managing financial products associated with different providers within a wallet of a mobile device. The financial products are integrated into the wallet in form of mobile wallet tokens that are linked with conditions regarding the usage of the financial products in transactions, such as a transaction limit or a maximal number of transactions. <CIT> discloses a method for providing payment credentials to a mobile device. A token service module of a payment processing network generates a token associated with a primary account number and stores the mapping between the primary account number and the token. The generated tokens is transmitted from the token service module over a wallet provider to a mobile device. When the token is used in context of a payment, the payment processing network receives a message comprising the token and verifies whether a mapping between the token and a primary account number is known.

Systems and methods are provided for using a consumer digital wallet account as a payment method within a merchant digital wallet account. According to certain embodiments, the consumer digital wallet account may be provided to a user by a payment provider. For example, the user may have previously registered the consumer digital wallet account with a payment provide server associated with the payment provider. The payment provider server may be configured to process payment transactions related to using the consumer digital wallet account as a payment method. In other embodiments, the consumer digital wallet account may be provided to the user by a consumer wallet provider that is different from the payment provider. In such embodiments, a consumer wallet provider server may communicate with the payment provider server to facilitate certain payment transactions that use the consumer digital wallet account as a payment method. For example, as described in more detail below with respect to <FIG>, the payment provider server maybe configured to route certain payment transactions to the consumer wallet provider server, which may be configured to process those payment transactions.

The consumer digital wallet account may store one or more payment methods for the user that the user can access at different merchant sites at which the consumer digital wallet account is accepted. As used herein, payment methods may include, but are not limited to, credit cards, debit cards, gift cards, internal balances with the payment provider, balances with other payment providers, coupons, electronic checks, cryptocurrencies, and incentives. The user may be able to access the consumer digital wallet account using a website hosted by the payment provider and/or using a consumer digital wallet application (provided by the payment provider) executing on a user device of the user.

In some implementations, the consumer digital wallet account may be associated with a social media feed that the user can access, post to, and view. The social media feed may display information (e.g., icons, emoji, text, etc.) related to payment transactions that user has participated with other users that have consumer digital wallet account with the payment provider. For example, if a user participates in a particular payment transaction with a second user, a corresponding post detailing aspects of the particular payment transaction may be automatically posted on the social media feed of the user and/or the second user. Additionally, the social media feed of the user may also include posts of payment transactions between other users (e.g., transactions in which the user did not participate), such as between other users that are included in a contact list of the user, or between other users located within a vicinity of the user.

Furthermore, the user may be provided a merchant digital wallet account by a merchant. The merchant digital wallet account may be accessible by the user when the user shops with the merchant, such as when the user visits a website of the merchant or using a merchant digital wallet application provided by the merchant. To this end, the user may store one or more methods of payment within the merchant digital wallet account for purchase transactions the user makes with the merchant. Furthermore, different users may have their own respective merchant digital wallet accounts with the merchant, and each of the merchant digital wallet accounts may store different payment methods of their respective users.

According to certain embodiments, the user may desire to add the consumer digital wallet account as a payment method to store within the merchant digital wallet account. For example, the user may initiate a request, via the user device, to add the consumer digital wallet account as a payment method to the merchant digital wallet account. In some implementations, the user may initiate the request via the consumer digital wallet application while in other implementations, the user may initiate the request via the merchant digital wallet application.

The request may include a account identifier associated with the consumer digital wallet account. In addition, the user device may transmit device information associated with the user device to the merchant server. The device information may include model information, an operating system version, language information, a device identifier, location information, and/or the like. Further, the device information may be included in the request or may be transmitted separately from the request.

The merchant server may receive the request and the device information and forward the account identifier and the device information to a payment provider system of the payment provider (which maintains the consumer digital wallet account for the user). Based on the account identifier and the device information of the user device, the payment provider system may perform a risk assessment of the request to add the consumer digital wallet account to the merchant digital wallet account. In response to determining, based on the risk assessment, that the request is approved, the payment provider system generates an electronic non-transactable token (NTT) corresponding to the consumer digital wallet account. In some implementations, the NTT may be a random string of alphanumeric characters that represents the consumer digital wallet account. Further, the NTT is unusable for payment (e.g., the NTT is unusable and/or unrecognizable by a payment network used to process payment transactions) and does not include any financial information related to the user nor data related to any financial instrument of the user. In addition, the presence of the NTT may indicate that consumer digital wallet account is valid payment option of the user within the merchant digital wallet account.

The NTT may be stored, in association with the account identifier, in a secure database separate from the merchant server. Moreover, the secure database is inaccessible by the merchant servers, and merchant, merchant severs, and/or any other device of the merchant do not have access rights to the secure database. However, the secure database is still accessible by the payment provider system. In addition, the NTT may also be transmitted to the merchant servers and stored on the merchant servers.

Subsequent to the generation and storage of the NTT, the user may initiate a purchase request to purchase an item from the merchant. The purchase request may indicate a selection of the consumer digital wallet account from the merchant digital wallet account as a payment method to complete the transaction. The purchase request may be received by the merchant server, and the merchant server may forward the purchase request to the payment provider system. The purchase request may include the account identifier of the user that is associated with the consumer digital wallet account. As such, the payment provider system may use the account identifier to retrieve the NTT from the secure database. As previously discussed, the existence of the NTT may indicate that the consumer digital wallet account is a valid payment method within the merchant digital wallet account.

Since the NTT is unusable for payment, the payment provider system may generate a single-use payment token based on the NTT. The single-use payment token may be another electronic token that is different from the NTT. Additionally, an association between the single-use payment token and the NTT may be stored in the secure database. Thus, the secure database may store associations between the NTT, the account identifier, and the single-use payment token. Further, the single-use payment token may include another set of random alphanumeric characters. Similar to the NTT, the single-use payment token does not include any financial information related to the user nor data related to any financial instrument of the user. However, in contrast to the NTT, the single-use payment token is usable for a single payment transaction (e.g., the purchase request). Therefore, after the purchase request is processed using the single-use payment token, the single-use payment token is no longer usable for subsequent purchase transactions.

The payment provider system may transmit a card transaction message that includes the single-use payment token to an existing payment network. In certain implementations, the existing payment network may be a credit/debit card payment network, and the single-use payment token may include a bank identification number (BIN) that corresponds to the payment provider and/or payment provider system. The card transaction message may be a card authorization message (e.g., an International Organization for Standardization (ISO) <NUM> car authorization message) that represents a message format for authorization of credit/debit cards over the exiting payment network.

Based on the BIN include in the single-use payment token, the card transaction message may be routed back to payment provider system after being transmitted to the existing card payment network. Thus, payment provider system may in effect emulate the consumer digital wallet account as a typical credit/debit card and leverage an existing mechanism in place that is already used to process credit/debit card transactions (e.g., routing the card transaction message through the existing payment network). Further, in a typical credit/debit card transaction, the existing payment network routes the card transaction message to an issuer that is a different financial institution than the financial institution associated with the merchant. Present embodiments, as previously discussed, enable the card transaction message to be routed back to the payment provider system, with the payment provider providing the role of an issuer.

After the card transaction message is routed back to the payment provider system, the payment provider system may determine the account identifier using the single-use payment token. For example, based on accessing the secure database, the payment provider system may identify the NTT that is associated with the single-use payment token. Further, the payment provider system may determine that the NTT is associated with the account identifier.

Based on the account identifier, the payment provider system may retrieve wallet information corresponding to the consumer digital wallet account, such as a default payment method, wallet balance, payment history, and/or the like. Using the wallet information and/or other information (e.g., merchant information, transaction information such as purchase amount, date, etc.), the payment provider system may execute a risk analysis process with respect to the purchase request. In response to determining, based on the risk analysis process, that the purchase request is authorized, the payment provider system may cause payment from the user to the merchant using the consumer digital wallet account.

Further, according to certain embodiments, the user device may be configured to generate a post corresponding to the purchase transaction with the merchant on the social media feed of the consumer digital wallet account. For example, the user device may automatically generate particular text, icons, emoji, and/or the like in response to the purchase transaction being processed. Further, the particular text, icons, emoji, and/or the like that are posted my depend on the specific merchant corresponding to the purchase transaction. In other implementations, the particular text, icons, emoji, and/or the like maybe manually input by the user.

<FIG> is a block diagram of a networked system <NUM> for implementing the processes described herein, according to an embodiment. As shown, system <NUM> may include or implement a plurality of devices, computers, servers, and/or software components that operate to perform various methodologies in accordance with the described embodiments. Example devices, computers, and servers may include mobile devices, wearable devices, stand-alone devices, desktop computers, laptop computers, and enterprise-class servers, executing an operating system (OS) such as a MICROSOFT® OS, a UNIX® OS, a LINUX® OS, or another suitable device and/or server based OS. It will be appreciated that the devices, computers, and/or servers illustrated in <FIG> may be deployed differently and that the operations performed and/or the services provided by such devices, computers, and/or servers may be combined or separated for a given embodiment and may be performed by a greater number or fewer number of devices, computers, and/or servers. Furthermore, one or more of the devices, computers, and/or servers may be operated and/or maintained by the same or different entities.

System <NUM> includes a user device <NUM> configured to interface with a user, a payment provider server <NUM>, a merchant server <NUM>, and a risk server <NUM>, which may be in communication with each other over a network <NUM>. In addition, the payment provider server <NUM> may be in communication with a payment network <NUM>. The user device <NUM>, the payment provider server <NUM>, the merchant server <NUM>, and the risk server <NUM> may each include one or more processors, memories, and other appropriate components for executing computer-executable instructions such as program code and/or data. The computer-executable instructions may be stored on one or more computer readable mediums or computer readable devices to implement the various applications, data, and steps described herein. For example, such instructions may be stored in one or more computer readable media such as memories or data storage devices internal and/or external to various components of system <NUM>, and/or accessible over network <NUM>.

The user device <NUM> may be implemented as a communication device that may utilize appropriate hardware and software configured for wired and/or wireless communication with the payment provider server <NUM>, the merchant server <NUM>, and/or the risk server <NUM>. The user device <NUM> may be located at a physical location of a merchant (e.g., a merchant location) and may be configured to facilitate payment for products or services sold by the merchant at the merchant location. For instance, the user device <NUM> may be configured to accept various forms of payment, including, but not limited to credit card payments, debit card payments, loyalty card payments, gift card payments, store card payments, and/or payment made by accessing a digital wallet.

The user device <NUM> may include a digital wallet application <NUM>, other applications <NUM>, a database <NUM>, communication components <NUM>, and sensors <NUM>. The digital wallet application <NUM> and other applications <NUM> may correspond to executable processes, procedures, and/or applications with associated hardware. In other embodiments, user device <NUM> may include additional or different components having specialized hardware and/or software to perform operations associated with the digital wallet applications <NUM> and/or the other applications <NUM>.

The digital wallet application <NUM> may be provided and maintained by the merchant associated with the merchant server <NUM>. In certain embodiments, the digital wallet application <NUM> may provide an interface for the user to access a merchant digital wallet account that the user maintains with the merchant. The merchant digital wallet account may store one or more payment methods of the user for purchase transactions specifically between the user and the merchant. As previously discussed, the payment methods may include, but are not limited to, credit cards, debit cards, gift cards, internal balances with the payment provider, balances with other payment providers, coupons, electronic checks, cryptocurrencies, and incentives.

According to one or more embodiments, the merchant digital wallet account may also be configured to store a consumer digital wallet account of the user as a payment method. The consumer digital wallet account may be provided to the user by the payment provider (e.g., of the payment provider server <NUM>). The consumer digital wallet account may also store one or more payment methods within the consumer digital wallet account, and the consumer digital wallet account may be used by the user to pay for items sold by any merchants that accept the consumer digital wallet account. The consumer digital wallet account may also facilitate other types of financial transactions associated with banking, online payments, money transfers, and/or the like.

The user device <NUM> may also include a consumer digital wallet application <NUM> that may be provided by the payment provider. The consumer digital wallet application <NUM> may provide the user direct access to the consumer digital wallet account. Additionally, the consumer digital wallet application <NUM> may facilitate payments between the user and other users that have other consumer digital wallet accounts with the payment provider. Further, after the consumer digital wallet account has been added as a payment method to the merchant digital wallet account, the user may pay the merchant via the consumer digital wallet account. In some implementations, the consumer digital wallet application <NUM>, after being used by the user as a payment method in a purchase transaction with the merchant, may be configured to split payment of the purchase transaction with other users having consumer digital wallet accounts with the payment provider.

According to certain embodiments, the consumer digital wallet application <NUM> may include a social media feed application <NUM>. The social media feed application <NUM> may manage a social media feed of the user corresponding to the consumer digital wallet account. As previously discussed, the social media feed may display information (e.g., icons, emoji, text, etc.) related to payment transactions that user has participated with other users that have consumer digital wallet account with the payment provider. For example, the social media feed application <NUM> may automatically generate particular text, icons, emoji, and/or the like in response to the payment transactions being processed between the user and the other users. Additionally, the social media feed application <NUM> of the user may be configured to access and display posts of payment transactions between other users (e.g., transactions in which the user did not participate), such as between other users that are included in a contact list of the user, or between other users located within a vicinity of the user. Furthermore, after the consumer digital wallet account has been added as a payment method to the merchant digital wallet account, social media feed application <NUM> may generate particular text, icons, emoji, and/or the like in response to the payment transactions being processed between the user and the merchant.

The user device <NUM> may execute the other applications <NUM> to perform various other tasks and/or operations corresponding to the user device <NUM>. For example, the other applications <NUM> may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network <NUM> and/or payment network <NUM>, or other types of applications. The other applications <NUM> may also include additional communication applications, such as email, texting, voice, and instant messaging (IM) applications that enable a user to send and receive emails, calls, texts, and other notifications through the network <NUM>. In various embodiments, the other applications <NUM> may include location detection applications, such as a mapping, compass, and/or global positioning system (GPS) applications, which may be used to determine a location of the user device <NUM>. The other applications may <NUM> include social networking applications. Additionally, the other applications <NUM> may include device interfaces and other display modules that may receive input and/or output information. For example, the other applications <NUM> may include a graphical (GUI) configured to provide an interface to the user.

The user device <NUM> may further include a database <NUM>, which may be stored in a memory and/or other storage device of the user device <NUM>. The database <NUM> may include, for example, identifiers (IDs) such as operating system registry entries, cookies associated with the digital wallet application <NUM> and/or other applications <NUM>, IDs associated with hardware of the communication component <NUM>, IDs used for payment/user/device authentication or identification, and/or other appropriate IDs. According to a particular embodiment, the database <NUM> may also store a merchant identifier associated with the merchant, a location identifier associated with the merchant location, and/or a POS identifier associated with the user device <NUM>. The database <NUM> may also include information corresponding to one or purchase transactions of customers who have purchased goods or services from the merchant, browsing histories of the customers, or other types of customer information. In certain embodiments, the user device <NUM> may also include information corresponding to payment tokens, such as payment tokens generated by the payment provider server <NUM>. Further, the database <NUM> may store login credentials, contact information, biometric information, and/or authentication information.

The user device <NUM> may also include at least one communication component <NUM> configured to communicate with various other devices such as the merchant server <NUM> and/or the payment provider server <NUM>. In various embodiments, communication component <NUM> may include a Digital Subscriber Line (DSL) modem, a Public Switched Telephone Network (PTSN) modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, radio frequency, infrared, Bluetooth, Bluetooth low-energy, near field communication (NFC) devices, and/or the like.

The user device <NUM> may also include one or more hardware sensors <NUM> to determine user inputs from the user <NUM>, motion of the user device <NUM>, biometric information associated with the user <NUM>, and/or various environmental data associated with the user device <NUM>. The sensors <NUM> may include, but are not limited to, gyroscopes, cameras, microphones, accelerometers, barometers, thermometers, compasses, magnetometers, light detectors, proximity sensors, fingerprint sensors, pedometers, and heart rate monitors.

The merchant server <NUM> may be maintained, for example, by a merchant and may be in communication with the payment provider, which may provide payment processing services for the merchant. However, in other embodiments, the merchant server <NUM> may be maintained by or include a financial service provider, social networking service, email or messaging service, media sharing service, and/or other service provider, which may provide payment processing services.

The merchant server <NUM> includes a merchant wallet application <NUM>, which may be executed by the merchant server <NUM> to provide the user access to the merchant digital wallet account. For instance, the merchant wallet application <NUM> may receive requests from the user device <NUM> to add the consumer digital wallet account as a payment method within the merchant digital wallet account. Further, after the consumer digital wallet account has been added as a payment method, the merchant digital wallet account may also receive a purchase request from the user device <NUM> to use the consumer digital wallet account as a payment method to purchase an item from the merchant on behalf of the user. The merchant wallet application <NUM> may be configured to forward these requests to the payment provider server <NUM>. In certain embodiments, the merchant wallet application <NUM> may also be configured to transmit other information about a purchase request to the payment provider server <NUM>, such as merchant information (e.g., merchant name, merchant location, merchant transaction history, and/or the like) and transaction information associated with the purchase request (e.g., item number, item category, purchase amount, purchase history of the user, and/or the like).

The merchant server <NUM> may execute the other applications <NUM> to perform various other tasks and/or operations corresponding to the payment provider server and/or the user device <NUM>. For example, the other applications <NUM> may include security applications for implementing server-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network <NUM>, or other types of applications. The other applications <NUM> may also include additional communication applications, such as email, texting, voice, and instant messaging (IM) applications that enable a user to send and receive emails, calls, texts, and other notifications through the network <NUM>. In various embodiments, the other applications <NUM> may include location detection applications, such as a mapping, compass, and/or global positioning system (GPS) applications, which may be used to determine a location of the user device <NUM>. The other applications may <NUM> include social networking applications. Additionally, the other applications <NUM> may include device interfaces and other display modules that may receive input and/or output information. For example, the other applications <NUM> may include a GUI configured to provide an interface to the user.

The merchant server <NUM> may further include a database <NUM>, which may be stored in a memory and/or other storage device of the merchant server <NUM>. The database <NUM> may include, for example, IDs such as operating system registry entries, cookies associated with the payment processing application <NUM>, biometric information, IDs associated with hardware of the network interface component <NUM>, IDs used for payment/user/device authentication or identification, and/or other appropriate IDs. According to a particular embodiment, the database <NUM> may also store a merchant identifier associated with the merchant, a location identifier associated with the merchant location, and/or a POS identifier associated with the user device <NUM>.

In various embodiments, the merchant server <NUM> also includes at least one network interface component <NUM> that is configured to communicate with the user device <NUM> and/or the payment provider server <NUM> via the network <NUM> and/or the payment network <NUM>. For example, according to a particular embodiment, the merchant server <NUM> may receive voice communication information from the user device <NUM> via the network interface component <NUM>. The network interface component <NUM> may comprise a DSL modem, a payment provider server 114TN modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, RF, and IR communication devices.

The payment provider server <NUM> may be maintained, for example, by the payment provider, which may provide payment processing services for the merchant. In one example, the payment provider server <NUM> may be provided by PAYPAL, Inc. of San Jose, consumer digital wallet account, USA. However, in other embodiments, the payment provider server <NUM> may be maintained by or include a financial service provider, social networking service, email or messaging service, media sharing service, and/or other service provider, which may provide payment processing services.

The payment provider server <NUM> includes a digital token application <NUM> that may be configured to generate and store a non-transactable token (NTT) indicating that the consumer digital wallet account is a valid payment method for the merchant digital wallet account. The digital token application <NUM> may generate the NTT in response to a request (e.g., from the user device <NUM> and/or merchant server <NUM>) to add the consumer digital wallet account to the merchant digital wallet account. Further, the digital token application <NUM> may be configured to generate a single-use payment token corresponding to the consumer digital wallet account in response to a purchase request to use the consumer digital wallet account as a payment method for purchasing an item sold by the merchant. The digital token application <NUM> is discussed in more detail below with respect to <FIG>.

The payment provider server <NUM> may also include a payment processing application <NUM>. The payment processing application <NUM> may be configured to generate transaction messages that include tokens generated by the digital token application <NUM> (e.g., the single-use payment token). The transaction messages may correspond to purchase requests from the user device to use the consumer digital wallet account as a payment method. The payment processing application <NUM> may communicate with the payment network <NUM> to process payment transactions via the transaction messages. According to certain embodiments, the transaction messages may be card transaction messages and the payment network <NUM> may be a credit/debit payment network used to process credit/debit payments. The payment processing application <NUM> is discussed in more detail below with respect to <FIG>.

Further, the payment provider server <NUM> may include a wallet account application <NUM>. The wallet account application <NUM> may be configured to access information associated with the consumer digital wallet account including, but not limited to, an account balance information, transaction history information of the user with respect to the consumer digital wallet account, payment methods stored by the user within the consumer digital wallet account, default payment methods, contact information of the user, contact list information of the user, and/or other types of information. In certain embodiments, the wallet account application <NUM> may provide such information (or at least portions thereof) to the risk server <NUM> (e.g., the risk analysis application <NUM>), which may execute a risk analysis process with respect to the provided information associated with the consumer digital wallet account. In certain embodiments, the wallet account application <NUM> may also be configured to communicate with the social media feed application <NUM> of the user device <NUM> to maintain the social media feed of the user. The wallet account application <NUM> is discussed in more detail below with respect to <FIG>.

In certain embodiments, the wallet account application <NUM> may be executed by a different server than the payment provider server <NUM>. For example, the wallet account application <NUM> may be executed by the consumer wallet provider server dedicated to managing the consumer digital wallet account of various users of the payment provider. The consumer wallet provider server may be in communication with the payment provider server <NUM> and the user device <NUM>, such as via the network <NUM>.

The payment provider server <NUM> may execute the other applications <NUM> to perform various other tasks and/or operations corresponding to the payment provider server and/or the user device <NUM>. For example, the other applications <NUM> may include security applications for implementing server-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network <NUM>, or other types of applications. The other applications <NUM> may also include additional communication applications, such as email, texting, voice, and instant messaging (IM) applications that enable a user to send and receive emails, calls, texts, and other notifications through the network <NUM>. In various embodiments, the other applications <NUM> may include location detection applications, such as a mapping, compass, and/or global positioning system (GPS) applications, which may be used to determine a location of the user device <NUM>. The other applications may <NUM> include social networking applications. Additionally, the other applications <NUM> may include device interfaces and other display modules that may receive input and/or output information. For example, the other applications <NUM> may include a GUI configured to provide an interface to the user.

The payment provider server <NUM> may further include a database <NUM>, which may be stored in a memory and/or other storage device of the payment provider server <NUM>. The database <NUM> may include, for example, IDs such as operating system registry entries, cookies associated with the payment processing application <NUM>, biometric information, IDs associated with hardware of the network interface component <NUM>, IDs used for payment/user/device authentication or identification, and/or other appropriate IDs. According to a particular embodiment, the database <NUM> may also store a merchant identifier associated with the merchant, a location identifier associated with the merchant location, and/or a POS identifier associated with the user device <NUM>.

In various embodiments, the payment provider server <NUM> also includes at least one network interface component <NUM> that is configured to communicate with the user device <NUM>, risk server <NUM>, and/or merchant server <NUM> via the network <NUM> and/or the payment network <NUM>. The network interface component <NUM> may comprise a DSL modem, a payment provider server 114TN modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, RF, and IR communication devices.

The risk server <NUM> may be maintained, for example, by a merchant and may be in communication with the payment provider, which may provide payment processing services for the merchant. However, in other embodiments, the risk server <NUM> may be maintained by or include a financial service provider, social networking service, email or messaging service, media sharing service, and/or other service provider, which may provide payment processing services.

The risk server <NUM> includes a risk analysis application <NUM>, which may be executed by the risk server <NUM> to execute a risk analysis process with respect to the purchase request (e.g., to use the consumer digital wallet account as a payment method) initiated by the user device <NUM>. For example, the risk analysis application <NUM> may execute the risk analysis process based on information provided by the digital token application <NUM>, payment processing application <NUM>, wallet account application <NUM>, and/or any combination thereof. The risk analysis application <NUM> is discussed in more detail below with respect to <FIG>.

The risk server <NUM> may execute the other applications <NUM> to perform various other tasks and/or operations corresponding to the payment provider server and/or the user device <NUM>. For example, the other applications <NUM> may include security applications for implementing server-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network <NUM>, or other types of applications. The other applications <NUM> may also include additional communication applications, such as email, texting, voice, and instant messaging (IM) applications that enable a user to send and receive emails, calls, texts, and other notifications through the network <NUM>. In various embodiments, the other applications <NUM> may include location detection applications, such as a mapping, compass, and/or global positioning system (GPS) applications, which may be used to determine a location of the user device <NUM>. The other applications may <NUM> include social networking applications. Additionally, the other applications <NUM> may include device interfaces and other display modules that may receive input and/or output information. For example, the other applications <NUM> may include a GUI configured to provide an interface to the user.

The risk server <NUM> may further include a database <NUM>, which may be stored in a memory and/or other storage device of the risk server <NUM>. The database <NUM> may include, for example, IDs such as operating system registry entries, cookies associated with the risk analysis application <NUM>, biometric information, IDs associated with hardware of the network interface component <NUM>, IDs used for payment/user/device authentication or identification, and/or other appropriate IDs. According to a particular embodiment, the database <NUM> may also store a merchant identifier associated with the merchant, a location identifier associated with the merchant location, and/or a POS identifier associated with the user device <NUM>.

In various embodiments, the risk server <NUM> also includes at least one network interface component <NUM> that is configured to communicate with the payment provider server <NUM> via the network <NUM>. For example, according to a particular embodiment, the risk server <NUM> may receive voice communication information from the user device <NUM> via the network interface component <NUM>. The network interface component <NUM> may comprise a DSL modem, a payment provider server 114TN modem, an Ethernet device, a broadband device, a satellite device and/or various other types of wired and/or wireless network communication devices including microwave, RF, and IR communication devices.

The network <NUM> may be implemented as a single network or a combination of multiple networks. For example, in various embodiments, the network <NUM> may include the Internet or one or more intranets, landline networks, wireless networks, and/or other appropriate types of networks. Thus, the network <NUM> may correspond to small scale communication networks, such as a private or local area network, or a larger scale network, such as a wide area network or the Internet, accessible by the various components of system <NUM>.

The payment network <NUM> may be implemented as a single payment network or a combination of multiple payment networks. For example, in various embodiments, the network <NUM> may include one or more payment rails operated and maintained by one or more financial institutions such as VISA®, MASTERCARD®, STAR®, PULSE®, and/or the like. The payment network <NUM> may also include secure connections between the user device <NUM> the payment processor <NUM> and one or more payment gateways.

<FIG> illustrates a data flow <NUM> for adding a consumer digital wallet account of a user to a merchant digital wallet account of a merchant. <FIG> illustrates a flow diagram of a method <NUM> for adding a consumer digital wallet account of a user to a merchant digital wallet account of a merchant. As such, <FIG> will be described in conjunction with references to elements illustrated in <FIG>. Note that one or more steps, processes, and methods described herein may be omitted, performed in a different sequence, or combined as desired or appropriate. As previously discussed, the consumer digital wallet account may be provided to the user by the payment provider, and the merchant digital wallet account may be provided to the user by the merchant for use when the user purchases an item or other product from the merchant.

At step <NUM>, the payment provider server <NUM> may receive a request to add a consumer digital wallet account to the merchant digital wallet account. For example, as shown in <FIG>, the user device <NUM> may transmit a request <NUM> to add the consumer digital wallet account as payment method within the merchant digital wallet account for use in subsequent purchase transactions with the merchant. For example, the user device <NUM> may transmit the request <NUM> using the digital wallet application <NUM> provided by the merchant and stored on the user device <NUM>. As another example, the user device <NUM> may transmit the request <NUM> via a website provided by the merchant server <NUM>. As such, the request <NUM> may be transmitted in response to the user selecting (e.g., via the user device <NUM>) the consumer digital wallet account from a plurality of payment methods offered to the user via the digital wallet application <NUM> and/or the website. In other embodiments, the request <NUM> may be transmitted by the user device via the consumer digital wallet application <NUM>. For instance, the user may add the consumer digital wallet account as a payment method to the merchant digital wallet account from within the environment of the digital wallet application <NUM>.

The merchant server <NUM> may receive the request <NUM>, such as via the merchant wallet application <NUM>. The merchant wallet application <NUM> may be configured to forward <NUM> the request to the payment provider system <NUM>. According to some embodiments, the payment provider system <NUM> may include components from the payment provider server <NUM> and the risk server <NUM>. For instance, the payment provider system <NUM> may include the digital token application <NUM> and the wallet account application <NUM> of the payment provider server <NUM> and the risk analysis application <NUM> of the risk server <NUM>.

At step <NUM>, the payment provider server <NUM> may determine device information of the user device <NUM> and a account identifier associated with the consumer digital wallet account. For instance, the wallet account application <NUM> may receive the forwarded request <NUM> from the merchant server <NUM>, and the forwarded request <NUM> may include login credentials provided by the user. Based on the login credentials, the wallet account application <NUM> may authenticate user and determine a account identifier corresponding to the login credentials. The account identifier may be linked to and/or otherwise associated with the consumer digital wallet account provided to the user by the payment provider. In other embodiments, the forwarded request <NUM> itself may include the account identifier. Further, the forwarded request <NUM> may also include the device information associated with the user device <NUM>. As such, the wallet account application <NUM> may transmit a risk analysis request <NUM> that includes the account identifier and the device information. As previously discussed, the device information may include model information, an operating system version, language information, a device identifier, location information, and/or the like.

At step <NUM>, the payment provider server <NUM> may determine, based on the device information and the account identifier, whether the addition of the consumer digital wallet account to the merchant digital wallet account is authorized. For example, the risk analysis application <NUM> may receive the risk analysis request <NUM>. Based on the account identifier and the device information included in the risk analysis request <NUM>, the risk analysis application <NUM> may determine whether the addition of the consumer digital wallet account to the merchant digital wallet account is authorized. At step <NUM>, if the risk analysis application <NUM> determines that the addition of the consumer digital wallet account to the merchant digital wallet account is authorized, the risk analysis application <NUM> may transmit an authorization indication <NUM> to the wallet account application <NUM>. Further, the method may then proceed to step <NUM>.

At step <NUM>, the payment provider server <NUM> may generate a NTT corresponding to the consumer digital wallet account. For instance, in response to receiving the authorization indication <NUM>, the wallet account application <NUM> may transmit a token request <NUM> to the digital token application <NUM>. The digital token application <NUM>, in response to the request, may be configured to generate the NTT. As previously noted, the NTT may represent an indication that the consumer digital wallet account has been added as a valid payment method to the merchant digital wallet account. In certain implementations, the NTT may be a randomly generated string of alphanumeric characters, although it will be appreciated by one or ordinary skill in the art that other representations of the NTT are also possible. As previously discussed, the NTT is unusable for payment and does correspond to any particular financial instrument of the user.

At step <NUM>, the payment provider server <NUM> may store the NTT in a secure database. For example, the digital token application <NUM>, in some instances, may be configured to store an association between the NTT and the account identifier in secure database <NUM>. According to some embodiments, the secure database <NUM> may correspond to the database <NUM> of the payment provider server <NUM> or any other database accessible by the payment provider server <NUM>. In addition, the secure database <NUM> may be inaccessible to the merchant server <NUM>. In other words, the merchant server <NUM> may not have access rights to the secure database <NUM> and /or may be unauthorized to access the merchant server <NUM>.

At step <NUM>, the NTT may be transmitted to the merchant server <NUM>. For instance, the payment provider system <NUM> may transmit <NUM> (e.g., via the payment provider server <NUM> or a consumer wallet provider server) the NTT to the user device <NUM>. Further, the user device <NUM> may provide <NUM> the NTT to the merchant server <NUM> to be stored locally at the merchant server <NUM> or in a storage device associated with the merchant server <NUM>.

<FIG> illustrates a data flow <NUM> for selecting the consumer digital wallet account as a payment method from the merchant digital wallet account for a purchase transaction. Similarly, <FIG> illustrates a flow diagram <NUM> for selecting the consumer digital wallet account as a payment method from the merchant digital wallet account for a purchase transaction. Thus, <FIG> will be described in conjunction with references to elements illustrated in <FIG>. It will be appreciated that the steps discussed with respect to <FIG> and <FIG> may be performed subsequent to adding the consumer digital wallet account to the merchant digital wallet account as previously described with reference to <FIG> and <FIG>. Note that one or more steps, processes, and methods described herein may be omitted, performed in a different sequence, or combined as desired or appropriate.

At step <NUM>, the payment provider server <NUM> may receive a purchase request to use the consumer digital wallet account as a payment method to pay for a product or item sold by the merchant. For instance, the user device <NUM> may transmit a purchase request <NUM> to the merchant server <NUM>, and the merchant server <NUM> may forward <NUM> the purchase request to the payment provider system <NUM>. In certain embodiments, the purchase request <NUM> may include device information associated with the user device <NUM> as well as the account identifier that was provided to the user by the payment provider. Further, the merchant server <NUM> may add additional information to the forwarded request <NUM>, such as transaction information associated with the purchase request (e.g., information related to the item to be purchased from the merchant, a payment amount, and/or other types of transaction information) and merchant information associated with the merchant (e.g., a merchant identifier, merchant location information, and/or other types of merchant information).

At step <NUM>, the payment provider server <NUM> may retrieve an NTT corresponding to the account identifier from a database. For example, the digital token application <NUM> may use the account identifier to retrieve <NUM> the NTT from the secure database <NUM>. As previously discussed, the secure database <NUM> may store an association between the account identifier and the NTT and may be inaccessible to the merchant or merchant server <NUM>. In certain embodiments, the account identifier may be used as an index into a table that stores multiple associations between different NTTs and different account identifiers.

At step <NUM>, the payment provider server <NUM> may determine whether the NTT is in fact stored in the secure database <NUM>, and if so, the method <NUM> may proceed to step <NUM>. Otherwise, an error may be returned to the payment provider server <NUM> and forwarded to the merchant server <NUM> and/or user device <NUM>.

At step <NUM>, the payment provider server <NUM> may generate a single-use payment token based on the NTT. For instance, the digital token application <NUM> may generate a single-use payment token based on the NTT. According to one or more embodiments, the single-use payment token may include a bank identification number (BIN) corresponding to the payment provider and/or payment provider server <NUM>. Additionally, an association between the single-use payment token and the NTT may be stored in the secure database <NUM>. As a result, the secure database <NUM> may store associations between the single-use payment token, the NTT, and the account identifier. Further, it will be appreciated that the single-use payment token may be a digital cryptographic token that can be used for a single payment transaction (e.g., the payment transaction corresponding to the purchase request of the user to purchase the item from the merchant). After processing the payment transaction, the single-use payment transaction may remain unsuable for subsequent payment transactions.

At step <NUM>, the payment provider server <NUM> may transmit, to a payment network, a transaction message that includes the single-use payment token. For example, the digital token application <NUM> may provide <NUM> the single-use payment token to the payment processing application <NUM>, and the payment processing application <NUM> may generate the transaction message that includes the single-use payment token. The payment processing application <NUM> may then transmit <NUM> the transaction message to the payment network <NUM>. In some embodiments, the transaction message may correspond to a credit/debit card transaction message (e.g., an ISO <NUM> authorization message). Further, the payment network <NUM> may be an existing card payment network that routes credit/debit card transaction messages to the appropriate devices.

In embodiments where transaction message corresponds to a credit/debit card transaction message, the digital token application <NUM> may generate the transaction message to include dummy card account information. For example, the transaction message may include a dummy expiration date, a dummy card verification value (CVV) number, other types of credit card information, and/or a combination thereof. Thus, the transaction message may mimic a credit/debit card transaction message, and the payment network <NUM> may be able to process the transaction message as a normal credit/debit card transaction.

According to other embodiments, prior to or concurrently with transmitting the transaction message to the payment network <NUM>, the payment processing application <NUM> may cache <NUM> certain transaction information and merchant information with the risk analysis application <NUM> to be used during execution of a subsequent risk analysis process (e.g., as discussed with respect to step <NUM> below). The transaction information may include, but is not limited to, information related to the user/buyer, account details of the user/buyer, transaction amount, currency, transaction type (e.g., whether the transaction is an authorization transaction or a sale transaction), and a payment type. The merchant information may include, but is not limited to, information corresponding to merchant identifiers, merchant accounts, and merchant location. As an example, the payment processing application <NUM> may associate a unique identifier with the transaction information and the merchant information. To this end, the payment processing application <NUM> may generate the unique identifier by using a hash function to calculate a hash value based on the single-use payment token and the dummy card account information. Further the payment processing application <NUM> may store and/or cache the association between the unique identifier (e.g. the hash value) and the transaction and merchant information with the risk server <NUM>, such as in the databased <NUM> or another storage component in communication with the risk analysis application <NUM>.

At step <NUM>, the payment provider server <NUM> may receive the transaction message that has been routed back to the payment provider server <NUM> based on information included in the single-use payment token. For instance, based on the BIN included in the single-use payment token, the transaction message may be routed <NUM> from the payment network <NUM> back to the payment provider server <NUM> (e.g., the payment processing application <NUM>). For example, the payment network <NUM> may perform a lookup to a routing table using the BIN and determine that the transaction message is to be routed to the payment provider server <NUM> based on the lookup.

At step <NUM>, the payment provider server <NUM> may determine, based on information included in the single-use payment token, wallet account information associated with the consumer digital wallet account. For instance, the payment processing application <NUM> may identify, based on de-tokenizing the single-use payment token, certain information that includes, but is not limited to, a second unique identifier, the account identifier corresponding to the consumer digital wallet account, and user information related to the user. According to some embodiments, the second unique identifier may be a second hash value calculated by the payment processing application <NUM> using the same hash function used to calculate the hash value that was previously cached and associated with the transaction information and merchant information. As such, after the transaction message is routed back to the payment provider server <NUM>, the payment processing application <NUM> may calculate the second hash value by applying the hash function to the single-use payment token and the dummy card account information that was included in the transaction message. Additionally, the payment processing application <NUM> may determine the account identifier based on the association between the single-use payment token, the NTT, and the account identifier stored in the secure database <NUM>.

Further, the payment processing application <NUM> may provide <NUM> the information resulting from the detokenization of the single-use payment token (e.g., the second unique identifier, the account identifier, and/or the user information) to the wallet account application <NUM>. The wallet account application <NUM> may determine whether access to the consumer digital wallet account is authorized, and if so, the wallet account application <NUM> may determine, based on the account identifier, wallet account information corresponding to the consumer digital wallet account. The wallet account information may indicate a default payment method for the user that has been selected from a plurality of payment methods of the user stored in the consumer digital wallet account. The wallet account information may also include other information related to the consumer digital wallet account, such as transaction history of the user's usage of the consumer digital wallet account and other types of information. Furthermore, the wallet account information, the second unique identifier, the user information, or a combination thereof may be provided <NUM> to the wallet account application <NUM>.

As previously discussed, the wallet account application <NUM> may be executed by a different server than the payment provider server <NUM>. For example, the wallet account application <NUM> may be executed by the consumer wallet provider server dedicated to managing the consumer digital wallet account of various users of the payment provider. To this end, the payment processing application <NUM> may transmit the information resulting from the detokenization of the single-use payment token to the consumer wallet provider server. The consumer wallet provider server may then determine the wallet account information from the detokenized information and provide the wallet account information to the risk server <NUM>, as detailed in step <NUM>.

At step <NUM>, a risk analysis process with respect to the purchase request may be executed using the wallet account information. In certain embodiments, in addition to using the wallet account information, the risk analysis process may also be executed using the cached transaction information and merchant information and the user information. For example, the risk analysis application <NUM> of the risk server <NUM> may determine that the second unique identifier is equal to the unique identifier that was previously cached with the transaction information and the merchant information in the database <NUM>. For instance, the second unique identifier may be the second hash value, and the risk analysis application <NUM> may determine that the second hash value is equal to the previously calculated and cached hash value. Based on this determination, the risk analysis application <NUM> may access the transaction information and the merchant information associated with the previously calculated and cached hash value.

At step <NUM>, the payment provider server <NUM> may determine, based on the risk analysis process, whether to proceed with the processing the purchase transaction. For example, based on executing the risk analysis process, the risk analysis application <NUM> may determine a risk profile associated with the purchase transaction. Further, the risk analysis application <NUM> may determine whether the risk profile satisfies a risk threshold. If the risk profile satisfies the risk threshold, the method <NUM> may proceed to step <NUM>, in which the purchase request is processed. Otherwise an error may returned and transmitted to the merchant server <NUM> and/or user device <NUM> indicating that the purchase transaction could not be processed.

At step <NUM>, the purchase request is processed, thereby causing funds to remitted from a financial account of the user to a financial account of the merchant.

<FIG> is a block diagram of a computer system <NUM> suitable for implementing one or more components in <FIG>, according to an embodiment. Referring to <FIG>, an illustrative system <NUM> including a computer <NUM> is shown. The computer <NUM> may be an implementation of a computing system that includes or corresponds to the user device <NUM>, the payment provider server <NUM>, the risk server, and/or the merchant server <NUM> of <FIG>. The computer <NUM> includes at least one computer processor (CPU) <NUM> (e.g., a hardware processor) as well as main memory <NUM>, a memory controller <NUM>, and a non-volatile memory <NUM>. The main memory <NUM> is connected through a memory bus <NUM> to the memory controller <NUM>. The memory controller <NUM> and the non-volatile memory <NUM> are connected through a second memory bus <NUM> and a bus adapter <NUM> to the processor <NUM> through a processor bus <NUM>.

Stored at the memory <NUM> are one or more applications <NUM> that may be module(s) or computer program instructions for carrying out particular tasks (e.g., the digital wallet application <NUM>, consumer digital wallet application <NUM>, social media feed application <NUM>, digital token application <NUM>, payment processing application <NUM>, wallet account application <NUM>, risk analysis application, and merchant wallet application <NUM> of <FIG>). Also stored at the main memory <NUM> is an operating system <NUM>. Operating systems include, but are not limited to, UNIX® (a registered trademark of The Open Group), Linux® (a registered trademark of Linus Torvalds), Windows® (a registered trademark of Microsoft Corporation, Redmond, WA, United States), and others as will occur to those of skill in the art. The operating system <NUM> and the application <NUM> in the example of <FIG> are shown in the main memory <NUM>, but components of the aforementioned software may also, or in addition, be stored at non-volatile memory (e.g., on data storage, such as data storage <NUM> and/or the non-volatile memory <NUM>).

The computer <NUM> includes a disk drive adapter <NUM> coupled through an expansion bus <NUM> and the bus adapter <NUM> to the processor <NUM> and other components of the computer <NUM>. The disk drive adapter <NUM> connects non-volatile data storage to the computer <NUM> in the form of the data storage <NUM> and may be implemented, for example, using Integrated Drive Electronics ("IDE") adapters, Small Computer System Interface ("SCSI") adapters, Serial Attached SCSI ("SAS") adapters, and others as will occur to those of skill in the art. Non-volatile computer memory also may be implemented as an optical disk drive, electrically erasable programmable read-only memory (so-called "EEPROM" or "Flash" memory), RAM drives, and other devices, as will occur to those of skill in the art. In a particular embodiment, the data storage <NUM> may store the data and information described herein.

The computer <NUM> also includes one or more input/output ("I/O") adapters <NUM> that implement user-oriented input/output through, for example, software drivers and computer hardware for controlling input and output to and from user input devices <NUM>, such as keyboards and mice. In addition, the computer <NUM> includes a communications adapter <NUM> for data communications with a data communications network <NUM>. The data communications may be carried out serially through Recommended Standard <NUM> (RS-<NUM>) connections (sometimes referred to as "serial" connections), through external buses such as a Universal Serial Bus ("USB"), through data communications networks such as internet protocol (IP) data communications networks, and in other ways as will occur to those of skill in the art. The communications adapter <NUM> implements the hardware level of data communications through which one computer sends data communications to another computer, directly or through a data communications network. Examples of the communications adapter <NUM> suitable to use in the computer <NUM> include, but are not limited to, modems for wired dial-up communications, Ethernet (Institute of Electrical and Electronics Engineers (IEEE) <NUM>) adapters for wired network communications, and IEEE <NUM> adapters for wireless network communications. The computer <NUM> also includes a display adapter <NUM> that facilitates data communication between the bus adapter <NUM> and a display device <NUM>, enabling the application <NUM> to visually present output on the display device <NUM>.

In various embodiments of the present disclosure, execution of instruction sequences to practice the present disclosure may be performed by computer system <NUM>. In various other embodiments of the present disclosure, a plurality of computer systems <NUM> coupled by communications adapter <NUM> to the network (e.g., such as a LAN, WLAN, and/or various other wired or wireless networks, including telecommunications, mobile, and cellular phone networks) may perform instruction sequences to practice the present disclosure in coordination with one another.

Particular embodiments described herein may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment containing both hardware and software elements. In a particular embodiment, the disclosed methods are implemented in software that is embedded in processor readable storage medium or storage device and executed by a processor that includes but is not limited to firmware, resident software, microcode, etc..

Further, embodiments of the present disclosure, may take the form of a computer program product accessible from a computer-usable or computer-readable storage device providing program code (e.g., computer-executable instructions) for use by or in connection with a computer, processor, or any instruction execution system. For the purposes of this description, a computer-usable or computer-readable storage device may be non-transitory and can be any apparatus that can tangibly embody a computer program and that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, processor, apparatus, or device.

In various embodiments, the medium can include an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or apparatus or device) or a propagation medium. Examples of a computer-readable storage device include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk - read only memory (CD-ROM), compact disk - read/write (CD-R/W) and digital versatile disk (DVD).

A data processing system suitable for storing and/or executing program code may include at least one processor coupled directly or indirectly to memory elements through a system bus. The memory elements can include local memory employed during actual execution of the program code, bulk storage, and cache memories that may provide temporary or more permanent storage of at least some program code in order to reduce the number of times code must be retrieved from bulk storage during execution.

Input/output or I/O devices (including but not limited to keyboards, displays, pointing devices, etc.) can be coupled to the data processing system either directly or through intervening I/O controllers. Network adapters may also be coupled to the data processing system to enable the data processing system to become coupled to other data processing systems or remote printers or storage devices through intervening private or public networks. Modems, cable modems, and Ethernet cards are just a few of the currently available types of network adapters.

Claim 1:
A computer-implemented method, comprising:
generating, by a payment provider system (<NUM>), a first digital token corresponding to a first digital wallet account of a user (<NUM>) that is unusable for a payment transaction to purchase an item from a merchant (<NUM>);
receiving (<NUM>), by the payment provider system (<NUM>), a payment request to purchase the item from the merchant (<NUM>), the payment request including an account identifier corresponding to the first digital wallet account, the first digital wallet account corresponding to a plurality of payment methods included in a second digital wallet account provided by the merchant;
identifying (<NUM>), by the payment provider system, the first digital token using the account identifier,
generating (<NUM>), by the payment provider system (<NUM>), a second digital token usable for the payment transaction based on the first digital token, wherein the second digital token comprises routing information that enables an existing card payment network (<NUM>) to route a card transaction message back to the payment provider system (<NUM>);
generating, by the payment provider system (<NUM>), the card transaction message comprising the second digital token and dummy card account information;
generating, by the payment provider system (<NUM>), a unique identifier by applying a hash function to the second digital token and the dummy card account information;
transmitting (<NUM>), to the existing card payment network (<NUM>) by the payment provider system (<NUM>), the card transaction message ;
receiving (<NUM>), by the payment provider system (<NUM>), based on the routing information from the second digital token, the card transaction message from the existing card payment network (<NUM>);
determining (<NUM>), by the payment provider system (<NUM>), the account identifier and a second unique identifier based on the second digital token from the card transaction message wherein the second unique identifier is obtained by applying the hash function to the second digital token and the dummy card account information from the received card transaction message; and
if the unique identifier and the second unique identifier are equal, and based on the account identifier, processing (<NUM>), by the payment provider system (<NUM>), the payment request between the user (<NUM>) and the merchant (<NUM>).