Digitizing Payment Cards for Web 3.0 and Metaverse Transactions

Abstract

Systems and techniques are provided for digitizing payment cards for Web 3.0 ("Web3") and metaverse transactions. The disclosed systems and techniques enable the use of non-fungible tokens (NFTs) to represent payment tokens for making payments within the Web3 and metaverse environments. In effect, the disclosed systems and techniques provide a financial NFT-enabled representation of a payment card account as a token within a blockchain network, which can be used to facilitate Web3 payments involving real-time exchange between fiat and cryptocurrencies.

Description

[Technical Field]

[0001] This application relates to the digitization of payment cards for Web 3.0 and metaverse transactions. [Background technology]

[0002] Web 3.0 (Web3) and the Metaverse are growing in popularity and will see significant investment by the industry in the coming years. Currently, payments in Web3 / Metaverse rely on either cryptocurrency tokens or other platform-specific credits. This ties funds to a specific ecosystem, and in the case of cryptotokens, their price is subject to volatility due to the volatile nature of cryptocurrencies. Even when payments are made in fiat currency, users must enter their desired payment method into each platform. Summary of the Invention

[0003] Systems and techniques are provided for digitizing payment cards for Web 3.0 ("Web3") and metaverse transactions. The disclosed systems and techniques enable the use of non-fungible tokens (NFTs) to represent payment tokens for making payments within the Web3 and metaverse environments. In effect, the disclosed systems and techniques provide a financial NFT-enabled representation of a payment card account as a token within a blockchain network, which can be used to facilitate Web3 payments involving real-time exchange between fiat and cryptocurrencies.

[0004] This Summary is provided to introduce a selection of concepts in a simplified form that are further described in the Detailed Description. This Summary is not intended to identify key or essential features of the claims, nor is it intended to limit the scope of the claims. [Brief explanation of the drawings]

[0005] [Figure 1] FIG. 1 is a schematic diagram illustrating an example operating environment in which various embodiments of the present invention may be implemented. [Figure 2A] FIG. 1 is a schematic diagram illustrating an example operating environment and signal flow for digitizing payment cards as financial NFTs for Web3 and Metaverse transactions, according to an embodiment of the present invention. [Figure 2B] This shows the process of tokenizing a payment card with a smart contract. [Figure 3] 1 illustrates an example operating environment and signal flow for merchant onboarding, according to an embodiment of the present invention. [Figure 4] 1 illustrates an example operating environment and signal flow for a person-to-merchant (P2M) payment transaction use case using a financial NFT, according to an embodiment of the present invention, for a guest checkout involving a financial NFT in Web3. [Figure 5] 1 illustrates an example operating environment and signal flow for a person-to-merchant (P2M) payment transaction use case using a financial NFT, according to an embodiment of the present invention, for a guest checkout involving a financial NFT on Web2. [Figure 6A]1 illustrates an example operating environment and signal flow for a person-to-merchant (P2M) payment transaction use case using a financial NFT, according to an embodiment of the present invention, relating to adding a financial NFT card-on-file (COF) to a merchant or device. [Figure 6B] 1 illustrates an example operating environment and signal flow for a person-to-merchant (P2M) payment transaction use case using a financial NFT, according to an embodiment of the present invention, including an example process for creating an NFT for a merchant COF. [Figure 7] 1 illustrates an example operating environment and signal flow for a use case of a person-to-merchant (P2M) payment transaction using a financial NFT, according to an embodiment of the present invention, showing a use case for a payment made using a COF of a financial NFT on Web3. [Figure 8] 1 illustrates an example operating environment and signal flow for a use case of a person-to-merchant (P2M) payment transaction using a financial NFT, according to an embodiment of the present invention, showing a use case for a payment made using a COF of a financial NFT on Web2. [Figure 9] 1 illustrates an example operating environment and signal flow for a person-to-person (P2P) payment transaction use case using a financial NFT, according to an embodiment of the present invention, illustrating a fiat-to-fiat use case. [Figure 10] 1 illustrates an example operating environment and signal flow for a use case of a person-to-person (P2P) payment transaction using a financial NFT, between fiat and cryptocurrencies, according to an embodiment of the present invention. [Figure 11]1 illustrates an example operating environment and signal flow for a person-to-person (P2P) payment transaction use case using a financial NFT, according to an embodiment of the present invention, showing a cryptocurrency-to-cryptocurrency use case. [Figure 12] 1 illustrates an example operating environment and signal flow for associating financial NFTs to enable value-added service use cases, according to an embodiment of the present invention. [Figure 13] 1 illustrates an example operating environment and signal flow for associating financial NFTs to enable value-added service use cases, according to an embodiment of the present invention. [Figure 14] 1 illustrates an example operating environment and signal flow for associating financial NFTs to enable value-added service use cases, according to an embodiment of the present invention. [Figure 15] FIG. 2 is an exemplary sequence diagram illustrating an onboarding flow for onboarding a payment card for making payments within a metaverse environment, according to an embodiment of the present invention. [Figure 16] FIG. 1 illustrates an exemplary sequence diagram of a payment flow for making a payment within a metaverse environment. [Figure 17] 1 illustrates an exemplary scenario of tokenizing a payment card for Web3 and metaverse transactions, according to an embodiment of the present invention. [Figure 18] 1 illustrates an exemplary scenario of bidding for an NFT using a tokenized payment card, according to an embodiment of the present invention. [Figure 19] 1 illustrates an exemplary scenario for the transfer of an NFT from a seller to a winning bidder user, according to an embodiment of the present invention. [Figure 20] 1 illustrates components of a computing system that may be used in certain embodiments described in this disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0006] Systems and techniques are provided for payment card digitization for Web 3.0 ("Web3") and metaverse transactions. The disclosed systems and techniques enable the use of non-fungible tokens (NFTs) to represent payment tokens for making payments within the Web3 and metaverse environments.

[0007] definition "Cryptocurrency" ("crypto") refers to digital currency in which transactions are verified and records are maintained by a decentralized system using cryptographic techniques rather than by a central authority. Examples of cryptocurrencies include Bitcoin, Ethereum, Tether, Solana, and Dogecoin.

[0008] Fiat currency refers to government-issued currency that is not backed by a physical commodity such as gold or silver and is backed by the government that issues it. Examples of fiat currency include, but are not limited to, the U.S. dollar, the British pound, the Indian rupee, and the euro.

[0009] "Non-fungible token" ("NFT") refers to a digital token on a blockchain, each representing a different digital or physical asset. Each NFT is unique and cannot be swapped for another version of itself.

[0010] As used in this disclosure, a "financial NFT" refers to a publicly verifiable, non-transferable NFT that represents a tokenized payment card. Each financial NFT can be driven by, for example, an ERC-721 smart contract deployed on a supported blockchain. Each financial NFT has multiple on-chain data elements, which may include, for example, but are not limited to: a Token ID (unique identifier); a Token URI (link to metadata); a hashed primary account number (PAN) (a one-way hash of the PAN); and a status (active / inactive / blocked). Token metadata can be stored in a peer-to-peer distributed file system (e.g., the InterPlanetary File System (IPFS)) and may include, for example, but not limited to, data elements (in JSON format) such as a name, description, image, and a list of custom attributes.

[0011] Examples of code content for financial NFTs include:

number

[0012] Payments with financial NFTs are recorded on the blockchain and are transparent: payment cards are tokenized as financial NFTs and listed on the blockchain itself. Because users own the financial NFT, they can generate cryptograms that can be used on existing payment card rails. Tokenization provides only a one-time token to Web3 / metaverse merchants. Therefore, financial NFTs are more secure because merchants do not have any payment data about the user.

[0013] "Tokenization" refers to the process of replacing a card's primary account number (PAN), such as the 16-digit number on a plastic card, with a unique substitute card number or "token." The token can be used for portable point-of-sale (POS) transactions, in-app purchases, or online purchases.

[0014] "Minting an NFT" refers to the process of publishing a digital asset on the blockchain.

[0015] A "smart contract" is a piece of fixed code within the application layer of a blockchain that directly and automatically controls the transfer of digital assets between parties under specific conditions.

[0016] The "metaverse" refers to a simulated digital environment that uses augmented reality (AR), virtual reality (VR), and blockchain.

[0017] "web2wallet" refers to a custodial digital wallet.

[0018] A "web3 wallet" or "crypto wallet" refers to a digital wallet that stores private keys used to access and manage blockchain-based assets, such as cryptocurrencies and NFTs. When a user creates a web3 wallet, the user is given a unique private key that is used to prove ownership of their digital assets. This private key is then used to generate a corresponding public key that can be used to verify the authenticity of transactions. Using these keys together, a web3 wallet can enable digital identity and the ability to prove ownership of digital assets in a secure and decentralized manner. Examples of Web3 wallets include, but are not limited to, non-custodial wallets, custodial wallets, and smart contract wallets.

[0019] A "private key" is a secret piece of information used to prove ownership of a digital asset. It is used to sign transactions sent to the blockchain and is known only to the owner of the digital asset.

[0020] A "public key" is a piece of information used to prove that a transaction was signed by the owner of a digital asset. It is used to verify the authenticity of the transaction and can be shared publicly.

[0021] A "public address" can be derived from the public key and can be publicly shared, allowing others to send digital assets to a user's wallet. By providing a unique public address, Web3 wallets can enable digital identity and proof of ownership of digital assets in a secure and decentralized manner.

[0022] A "transaction identifier" or "transaction hash" is a unique string of characters that provides proof that a transaction has been validated and added to the blockchain. The transaction hash can be used to provide confirmation that a transaction was completed and to look up transaction details, including but not limited to, sending address, receiving address, amount, date and time, network fee, and confirmation.

[0023] "Seller" refers to a party that offers goods or services in exchange for payment. A seller can be physically present in relation to the transaction or remote, such as an online retailer.

[0024] "Acquirer" refers to the party that processes payments on behalf of a merchant in a payment card transaction. The acquirer may be a banking system or other institution associated with the merchant.

[0025] "Issuer" refers to the banking system or other institution that provides payment cards to cardholders.

[0026] "User," "customer," and "consumer" are used interchangeably in this disclosure.

[0027] "Oracle" refers to an application that sources, validates, and transmits external information (i.e., information stored off the blockchain) to smart contracts running on the blockchain.

[0028] Current payment methods in the Web3 / Metaverse world are limited to dedicated coins / tokens that belong to that Web3 / Metaverse blockchain. Even when using fiat currency, the provider of the Web3 / Metaverse application holds the payment data. This ties users to a specific ecosystem. Advantageously, the disclosed system and technology allows users to securely tokenize payment methods across multiple blockchains via financial NFTs, allowing them to enjoy a seamless in-game payment experience. Financial NFTs are unique and cannot be replicated in the Web3 / Metaverse world. Therefore, using financial NFTs for payments would be highly beneficial. For security, users can withdraw their financial NFTs at any time.

[0029] Payments involving financial NFTs are recorded on the blockchain and are transparent: payment cards are tokenized as financial NFTs and listed on the blockchain itself. Because users own the financial NFT, they can generate cryptograms that can be used on existing payment card rails. Tokenization provides only a one-time token to Web3 / Metaverse merchants. Therefore, financial NFTs offer increased security over current payment methods in the Web3 / Metaverse world, as merchants do not have any payment data about the user.

[0030] Currently, to use an existing payment card in the Web3 / Metaverse world, a user must first add the payment instrument to their crypto wallet through an exchange. Only after doing this can the user make payments in the Web3 / Metaverse world with their existing payment card. Furthermore, everything in the Web3 / Metaverse world is decentralized, and there are no standards for real-time exchanges. In fact, current crypto exchanges are not integrated with Web3 / Metaverse payments. Advantageously, the disclosed systems and techniques enable real-time payment card-to-crypto exchange for Web3 / Metaverse payments.

[0031] Figure 1 illustrates an example operating environment in which various embodiments of the present invention may be implemented. With reference to Figure 1, the example operating environment may include a user wallet 105, a Web3 / metaverse merchant server 110, one or more financial NFT services (e.g., financial NFT service 115), a financial NFT smart contract 120, an attraction / event NFT 125, a card reader 130, an acquirer 135, a payment network 140, and an issuer 145.

[0032] 1, a user can communicate with a user wallet 105 to mint a financial NFT, which can be stored in the user wallet 105, for example, as described in connection with Figures 2A-2B. A user can communicate with the user wallet 105 to initiate an online transaction (e.g., with a Web3 / metaverse merchant server 110), for example, as described in connection with Figures 4-8, or to initiate a transaction at a card reader 130, for example, as described in connection with Figures 12-14.

[0033] The Web3 / Metaverse seller server 110 can communicate with the financial NFT service 115 to onboard and add a seller ID or seller address mapping to the list of registered sellers in the financial NFT smart contract 120, for example, as described in connection with FIG. 3.

[0034] As can be seen from the described use cases, payment cards typically used in payment networks 140 can be converted into financial NFTs for use in the Web3 / metaverse.

[0035] Components (computing systems, storage resources, and the like) within the operating environment may operate in communication with one another on or through a network (not shown). The network may be, but is not limited to, a cellular network (e.g., wireless telephone), a point-to-point dial-up connection, a satellite network, the Internet, a LAN, a WAN, a WiFi network, an ad-hoc network, or a combination thereof. Such networks are widely used to connect various network elements such as hubs, bridges, routers, switches, servers, and gateways. The network may include one or more connected networks (e.g., a multi-network environment), including public networks such as the Internet and / or private networks such as secure enterprise private networks. Access to the network may be provided via one or more wired or wireless access networks, as will be appreciated by those skilled in the art.

[0036] Communication between components may occur in part via an API (Application Programming Interface). An API is an interface implemented by a program code or hardware component (referred to in this disclosure as an "API-implementing component") that allows a different program code or hardware component (referred to in this disclosure as an "API-calling component") to access and use one or more functions, methods, procedures, data structures, classes, and / or other services provided by the API-implementing component. An API may define one or more parameters that are passed between the API-calling component and the API-implementing component. An API is generally a set of programming instructions and standards that allow two or more applications to communicate with each other, and is typically implemented over the Internet as a specified set of format or structure for Hypertext Transfer Protocol (HTTP) request and response messages that follow the Representational state transfer (REST) ​​or Simple Object Access Protocol (SOAP) architectures.

[0037] Figure 2A illustrates an example operating environment and signal flow for digitizing a payment card as a financial NFT for Web3 and metaverse transactions, according to an embodiment of the present invention. Referring to Figure 2A, the example operating environment may include a user 210, a crypto wallet 220, one or more financial NFT services (e.g., financial NFT service 240), a financial NFT smart contract 230, and a financial NFT 235. Figure 2B illustrates the process of tokenizing a payment card with a smart contract (e.g., financial NFT smart contract 230).

[0038] The described digitization of payment cards is similar to "Click to Pay / Secure Remote Commerce" (SRC), which results in a financial NFT containing a token unique reference (TUR). "Click to Pay / SRC" is a password-free checkout option built on the EMV standard.

[0039] The described payment card digitization / tokenization differs from the current Web3 approach of minting NFTs from previously deployed smart contracts. Referring to Figures 2A and 2B, to initiate the signal flow for digitizing a payment card as a financial NFT for Web3 / metaverse transactions, a user 210 can add payment card details (e.g., credit card, debit card, etc.) to a crypto wallet 220 (e.g., non-custodial) (Step 1). In some cases, the user 210 digitally signs upon entering the payment card details. The crypto wallet 220 can encrypt the payment card details and submit a request to create a financial NFT to a financial NFT smart contract 230 (Step 2). In some cases, the payment card details are encrypted using the financial NFT public key.

[0040] Process 250 can be implemented in a smart contract on a blockchain (e.g., financial NFT smart contract 230). As used in this disclosure, references to a smart contract refer to both its code and the underlying hardware running that code.

[0041] At operation 252, the financial NFT smart contract 230 may receive a request to create a financial NFT from the crypto wallet 220. The request to create a financial NFT may include encrypted payment card details for the user's 210 payment card.

[0042] The financial NFT smart contract 230 can communicate with the financial NFT service 240, e.g., via an oracle, to verify the user's 210 payment card details (step 3). An oracle refers to an entity (e.g., a data feed) within a blockchain network that allows access to external data. A smart contract (e.g., financial NFT smart contract 230) can only access data within the blockchain network. However, by using an oracle, the smart contract can access data outside the blockchain network (i.e., off-chain) and place that data on the blockchain (i.e., on-chain) for use by the smart contract. For example, an oracle can facilitate access to payment authorization results from a card payment network.

[0043] At operation 254, the financial NFT smart contract 230 can send a confirmation request to obtain confirmation of the payment card associated with the encrypted payment card details. In some cases, the financial NFT service 240 can send a one-time passcode (OTP) verification to the cardholder. The financial NFT service 240 can create a hashed PAN and a token unique reference (TUR). The TUR can be a token metadata uniform resource identifier (URI). The TUR represents a tokenized version of the payment card and can be generated by the payment network corresponding to the payment card. The TUR can be used by the payment network to identify the tokenized version of the payment card.

[0044] In operation 256, the financial NFT smart contract 230 receives confirmation for the payment card, the hashed PAN, and the TUR of the payment card from the financial NFT service 240.

[0045] The financial NFT smart contract 230 can publish (e.g., mint) the financial NFT 235 and send the financial NFT identifier back to the crypto wallet 220 (step 4).

[0046] At operation 258, financial NFT smart contract 230 mints a financial NFT 235 corresponding to the payment card. The financial NFT 235 includes a financial NFT identifier and TUR. At operation 260, financial NFT smart contract 230 can store an association of the financial NFT identifier, a hashed PAN, and / or a consumer wallet address of crypto wallet 220. At operation 262, financial NFT smart contract 230 can send the financial NFT identifier to crypto wallet 220. Each financial NFT includes a unique NFT identifier, a hashed PAN corresponding to the payment card, and TUR. The financial NFT is represented on the blockchain as owned by the user.

[0047] Accordingly, a method is provided that includes the steps of receiving (252) a request in a smart contract to create a financial NFT from a user's non-custodial wallet, the request for NFT creation including encrypted payment card details for the user's payment card; sending (254) a confirmation request to obtain confirmation for the payment card associated with the encrypted payment card details; receiving (256) the payment card confirmation, a hashed PAN, and a token unique reference for the payment card in the smart contract; minting (258) a financial NFT corresponding to the payment card in the smart contract, the financial NFT having a financial NFT identifier (and token unique reference); storing (260) a mapping between the financial NFT identifier, the hashed PAN, the token unique reference, and a consumer wallet address of the non-custodial wallet in the smart contract; and sending (262) the financial NFT identifier to the non-custodial wallet.

[0048] Figure 3 illustrates an example operating environment and signal flow for merchant onboarding, according to an embodiment of the present invention. Referring to Figure 3, the example operating environment may include a merchant server 310, a payment network API platform 350 having a payment network API gateway 320 and one or more financial NFT services (e.g., financial NFT service 330), and a financial NFT smart contract 340 having a list of registered merchants 345.

[0049] To initiate the signal flow for merchant onboarding, the merchant server 310 may onboard through the payment network API gateway 320 and register with the financial NFT service 330 (step 1). The financial NFT service 330 may then add the merchant's identity or wallet address mapping to the list of registered merchants 345 in the financial NFT smart contract 340 (step 2). In some cases, the financial NFT service 330 adds the merchant wallet address to the list of registered merchants 345 (optional step 3). In some cases, the merchant server 310 registers multiple wallet addresses for additional devices or additional subaccounts. The device identification, subaccount identification, and / or wallet address mapping are associated with the list of registered merchants 345 in the financial NFT smart contract 340 (step 4).

[0050] Figures 4-8 illustrate example operating environments and signal flows for use cases of person-to-merchant (P2M) payment transactions using financial NFTs, according to embodiments of the present invention. Figure 4 illustrates a use case for a guest checkout with a financial NFT on Web3; Figure 5 illustrates a use case for a guest checkout with a financial NFT on Web2; Figure 6 illustrates a use case for adding a card-on-file (COF) of a financial NFT to a merchant or device; Figure 7 illustrates a use case for a payment made using a COF of a financial NFT on Web3; and Figure 8 illustrates a use case for a payment made using a COF of a financial NFT on Web2.

[0051] 4-8, an example operating environment may include a user (e.g., user 410, user 510, user 610, user 710, user 810), a crypto wallet (e.g., crypto wallet 420, crypto wallet 520, crypto wallet 620), an online seller (e.g., online seller 425, online seller 525, online seller 725, online seller 825), one or more financial NFT services (e.g., financial NFT service 440, financial NFT service 540, financial NFT service 740, financial NFT service 840), and a financial NFT smart contract (e.g., financial NFT smart contract 430, financial NFT smart contract 530, financial NFT smart contract 630, financial NFT smart contract 730, financial NFT smart contract 830).

[0052] Prior to the first step of each signal flow in Figures 4-8, a user may add a payment card (e.g., a financial NFT) to a crypto wallet (e.g., via the payment card tokenization process 250 described in connection with Figures 2A and 2B). The financial NFT includes a unique TUR.

[0053] Referring to Figure 4, to initiate the signal flow for a guest checkout involving a financial NFT in a Web3 use case, a user 410 initiates checkout with a Web3 website / metaverse of an online merchant 425 (step 1). The online merchant 425 can be a native Web3 merchant or a merchant within the metaverse environment.

[0054] A user 410 connects their crypto wallet 420 (containing the minted financial NFT) with an online merchant 425 (step 2). To make a payment using the financial NFT, the user 410 provides a digital signature. The online merchant's 425's public address and the amount of blockchain value (e.g., crypto) will be passed to a function within the financial NFT along with the user's 410 digital signature. The output is a transaction hash, which contains a one-time-use, timed cryptogram for TUR. This cryptogram can be exchanged at a payment network / issuer oracle. In some cases, existing tokenization safeguards such as one-time passcode (OTP) verification / 3D Secure (3DS) verification are applied to the exchange before the real-time exchange between fiat and cryptocurrencies for the online merchant's 425 address occurs.

[0055] The online merchant 425 can submit a payment request to the financial NFT smart contract 430 (step 3). The payment request can include card transaction details. The financial NFT smart contract 430 can submit the card transaction details to the financial NFT service 440 (step 4). In some cases, the financial NFT smart contract 430 can submit the card transaction details to the financial NFT service 440 via an oracle. A payment result is sent back to the online merchant 425 (step 5).

[0056] Advantageously, for an exemplary guest checkout involving financial NFTs in a Web3 use case, only user 410 is required to sign for each payment transaction.

[0057] Referring to Figure 5, to initiate the signal flow for a guest checkout involving a financial NFT in a Web2 use case, a user 510 initiates a checkout at an online merchant's 525 Web2 website (step 1). The online merchant 525 can be a Web2-native merchant and can accept fiat currency rather than cryptocurrency.

[0058] A user 510 connects a crypto wallet 520 containing a minted financial NFT with an online merchant 525 (step 2). To make a payment using the financial NFT, the user 510 provides a digital signature. The public address of the online merchant 525, the currency code, and the payment amount can be passed to a function within the financial NFT along with the user's 510 digital signature.

[0059] The online merchant 525 can submit a payment request to the financial NFT smart contract 530 (step 3). The financial NFT smart contract 530 can request detokenization of the financial NFT, for example via an oracle (step 4). The detokenized payment card details can be sent back to the online merchant 525 (step 5). The online merchant 525 can then process the payment as a traditional payment card transaction.

[0060] In an example guest checkout involving a financial NFT in the Web2 use case, there are multiple options for transferring value. In some cases, the output that triggers a smart contract function within the financial NFT to transfer value will add a smart contract transaction containing a hashlock that will be picked up by the Financial NFT Service 540 (acting as a listener). In this case, the output will be processed on the existing payment card rails. Following a successful outcome, the transfer of value to the merchant will be unlocked.

[0061] In some cases, the output that triggers the smart contract function within the financial NFT to effect the transfer of value can be a transaction hash containing a one-time use timed cryptogram for TUR, which can be exchanged at a payment network / issuer oracle. In some cases, existing tokenization security measures such as OTP verification / 3DS are implemented before the real-time exchange between fiat and cryptocurrency occurs for the online merchant's 525 address.

[0062] For the example guest checkout involving a financial NFT in the Web2 use case, the transaction risk of the value transfer resides with the issuer because the issuer authenticates it on the existing card rail. For the example guest checkout involving a financial NFT in the Web2 use case, only the user 510 is required to sign each payment transaction.

[0063] Referring to FIG. 6A, to add a financial NFT card-on-file (COF) to a merchant or device, a user can visit the online merchant's Web3 / metaverse website to add the financial NFT and authorize the financial NFT for use with that online merchant.

[0064] In the example use case of FIG. 6A , to initiate the signal flow, a user 610 can sign and add a financial NFT to an online seller / metaverse device in the metaverse 640 (step 1). The user can send an authorization request via crypto wallet 620 to financial NFT smart contract 630 requesting to authorize the financial NFT with the online seller / metaverse device (step 2). Authorizing the financial NFT can include storing the approved financial NFT information and an authorization reference in financial NFT smart contract 630. The approved financial NFT information can include a financial NFT identifier for the financial NFT and a wallet address of the seller and / or seller device. The approved financial NFT information (e.g., the NFT identifier, the seller / device wallet address, and the authorization reference) can be stored in metaverse 640 (step 3). While the online seller is shown in the example example of FIG. 6A as being in the metaverse, the seller may also be in Web3 or even Web2.

[0065] In some cases, as shown in FIG. 6B, approval of the financial NFT may include minting a new merchant COF NFT in the financial NFT smart contract 630.

[0066] 6B illustrates an example process for minting an NFT for a merchant COF. In some cases, a merchant-specific financial NFT (i.e., an NFT for the merchant COF) may be minted via the smart contract that created the financial NFT corresponding to the payment card (e.g., financial NFT 235 described in connection with FIG. 2A).

[0067] Referring to Figure 6B, process 650 can begin when financial NFT smart contract 630 receives (652) a request for an NFT of a seller COF from a seller (e.g., a seller operating on a Web3 / metaverse website). In some cases, the seller can request an NFT of the seller COF by invoking a function on an existing financial NFT owned by a user (e.g., financial NFT 235 described in connection with Figure 2A). The NFT request for the seller COF can include (and in some cases must include) the user's signature (e.g., the user's private key).

[0068] The request for the merchant COF NFT may include the merchant private key, the merchant public address (e.g., the public address of the merchant crypto wallet), and the financial NFT identifier. In some cases, the merchant may generate the request for the merchant COF NFT by invoking a function on a user-owned financial NFT corresponding to a payment card and request that the consumer sign it (e.g., with the user's private key). The merchant COF NFT may be signed (e.g., multi-sig) by the user's private key and / or the merchant's private key.

[0069] The financial NFT smart contract 630 receives (654) the user private key from the crypto wallet 620. The user private key indicates to the financial NFT smart contract 630 that the user consents to minting the seller COF's NFT, which indicates that the seller has permission to use the financial NFT represented by the seller COF's NFT (e.g., represented via the TUR).

[0070] Once the financial NFT smart contract 630 receives the user private key, the financial NFT smart contract 630 can mint (656) an NFT for the merchant COF. The NFT for the merchant COF may include an NFT identifier for the merchant COF, a merchant identifier, a hashed PAN (i.e., the user's primary account number), and the TUR. Once it has the signatures of both the merchant and the user, the financial NFT smart contract 630 can mint an NFT for the merchant COF using the financial NFT's information stored in the financial NFT smart contract 630 (e.g., the user's hashed PAN and TUR). The merchant COF's NFT is represented on the blockchain as owned by the merchant and signed by the user (as opposed to a financial NFT, which is represented on the blockchain as owned by the user / payment cardholder). Advantageously, minting a merchant COF NFT allows the merchant to activate the merchant COF NFT as a "card-on-file" for transactions made by a user at that particular merchant, thus allowing the user to perform quick checkouts at Web3 / metaverse merchants using the merchant COF NFT (similar to a payment card stored on file with a Web2 merchant).

[0071] Referring to Figure 7, to use a financial NFT as a COF (or similarly to use an NFT of a merchant COF), an online merchant 725 can invoke the "makePayment" function of the financial NFT's COF by passing the online merchant's 725 public address and the amount of blockchain value (crypto) and signature. This will generate a unique cryptogram that can be used in traditional card payment processing along with TUR to complete the payment transaction, for example, via BankNet / ISO8583.

[0072] To initiate a signal flow for an exemplary financial NFT COF payment in a Web3 use case, a user 710 can select the financial COF NFT from a list of NFTs stored at an online seller 725 and confirm the payment (Step 1). The online seller 725 can sign and submit the transaction using a private key (Step 2). In some cases, the online seller 725 resides in the metaverse. In some cases, the online seller 725 resides on Web3. Transaction details can include a financial NFT identifier, an authentication reference, and / or a transaction amount.

[0073] The financial NFT smart contract 730 can submit the payment card transaction (step 3), for example, via an oracle, and the payment result can be sent back to the online merchant 725 (step 4).

[0074] In the exemplary merchant COF NFT payment for the Web3 use case, there are multiple options for transferring value. In some cases, the output that invokes a smart contract function within the financial NFT to effect the value transfer adds a smart contract transaction containing a hashlock to be picked by the Financial NFT Service 740 (acting as the listener). The "output" is processed on existing payment card rails, and a successful outcome unlocks the transfer of value to the online merchant 725.

[0075] In some cases, the output that triggers the smart contract function within the financial NFT to effect the transfer of value can be a transaction hash containing a one-time use, timed cryptogram for TUR, which can be exchanged with a payment network / issuer oracle and optionally undergo existing tokenization security measures such as OTP verification / 3DS before a real-time exchange between fiat and crypto occurs to the online merchant's 725 address.

[0076] Referring to FIG. 8, to initiate the signal flow for a payment made using a COF of a financial NFT in a Web2 use case, a user 810 can initiate a checkout with an online merchant 825, where the online merchant 825 is a Web2-native merchant (step 1). The user 810 can select a click-to-pay / financial NFT from a list of stored NFTs and confirm the payment. The online merchant 825 can sign and submit a payment transaction using its private key (step 2). Payment transaction details can include the financial NFT identifier, authentication reference, and / or transaction amount. The financial NFT smart contract 830 can request detokenization, for example, via an oracle (step 3). The detokenized payment card details can then be sent back to the online merchant 825 (step 4). The online merchant 825 can then process the payment as a traditional payment card transaction.

[0077] There are multiple options for transferring value in payment for the COF of the exemplary financial NFT in the Web2 use case. In some cases, the output that triggers a smart contract function within the financial NFT to transfer value adds a smart contract transaction containing a hashlock that is picked up by the Financial NFT Service 840 (acting as a listener). In this case, the output is processed on the existing payment card rails. Upon successful completion, the transfer of value to the online merchant 825 is unlocked.

[0078] In some cases, the output that triggers the smart contract function within the financial NFT to effect the transfer of value can be a transaction hash containing a one-time use timed cryptogram for TUR, which can be exchanged at a payment network / issuer oracle. In some cases, existing tokenization security measures such as OTP verification / 3DS are applied before the real-time exchange between fiat and crypto occurs to the online merchant's 825 address.

[0079] In the exemplary use case, the transaction risk of the value transfer resides with the issuer because the issuer authorizes the transaction on existing payment card rails.

[0080] In the COF use case, only the online merchant 825 is required to sign each payment transaction, and the user 810 is required to sign the tokenization process.

[0081] 9-11 illustrate example operating environments and signal flows for use cases of P2P payment transactions using financial NFTs according to embodiments of the present invention. FIG. 9 relates to a fiat-to-cryptocurrency use case, FIG. 10 relates to a fiat-to-cryptocurrency use case, and FIG. 11 relates to a crypto-to-cryptocurrency use case.

[0082] 9-11, an example operating environment may include a user (e.g., first user 910, first user 1010, and first user 1110), a crypto wallet (e.g., crypto wallet 920, crypto wallet 1020, and crypto wallet 1120), one or more financial NFT services (e.g., financial NFT service 940, financial NFT service 1040, and financial NFT service 1140), and a financial NFT smart contract (e.g., financial NFT smart contract 930, financial NFT smart contract 1030, and financial NFT smart contract 1130).

[0083] Prior to the first step of each signal flow in Figures 9-11, a user may add a payment card to a crypto wallet, which may involve tokenization (e.g., digitization as described in connection with Figure 3), resulting in a financial NFT containing TUR.

[0084] Referring to FIG. 9, to initiate a signal flow for a P2P payment between fiat currencies in a financial NFT use case, a first user 910 can select a financial NFT as the funding source and can enter a second user's (not shown) receiving NFT identification and transaction amount (step 1). The first user 910 can provide a digital signature to initiate the P2P payment transaction (step 2). A crypto wallet 920 can submit a request for the P2P payment to a financial NFT smart contract 930 (step 3). The financial NFT smart contract 930 can submit payment card transaction details to a financial NFT service 940, e.g., via an oracle (step 4). The results of the P2P payment can then be sent back to the crypto wallet 920 (step 5).

[0085] Referring to FIG. 10 , to initiate a signal flow for a P2P payment between fiat and cryptocurrencies in a financial NFT use case, a first user 1010 can select a financial NFT as the funding source and can enter a receiving crypto wallet address of a second user (not shown) and the P2P payment transaction amount (step 1). The first user 1010 can provide a digital signature to initiate the P2P payment transaction (step 2). The crypto wallet 1020 can submit a request for the P2P payment to the financial NFT smart contract 1030 (step 3). The financial NFT smart contract 1030 can submit payment card transaction information to the financial NFT service 1040, e.g., via an oracle (step 4). The results of the P2P payment can then be sent back to the crypto wallet 1020 (step 5).

[0086] Referring to FIG. 11 , to initiate a signal flow for a P2P payment between cryptocurrencies in a financial NFT use case, a first user 1010 can select a crypto balance as the funding source and can enter a second user's (not shown) receiving NFT identity and transaction amount (step 1). The first user 1010 can provide a digital signature to initiate the P2P payment transaction (step 2). The crypto wallet 1020 can submit a P2P payment request to the financial NFT smart contract 930 (step 3). The financial NFT smart contract 930 can receive the crypto payment (step 4). The financial NFT smart contract 1030 can submit payment card transaction information, for example, via an oracle (step 5). The results of the P2P payment can then be sent back to the crypto wallet 1020 (step 6).

[0087] 12-14 illustrate an example operating environment and signal flow for associating financial NFTs to enable value-added service use cases, according to embodiments of the present invention.

[0088] Referring to Figure 12, a user can associate a card (hashed PAN) as a financial NFT with a crypto wallet 1220 in a financial NFT smart contract 1230 (step 1). The financial NFT smart contract 1230 associates the payment card with a crypto wallet address. The user can then purchase a ticket as an NFT from a seller (step 2).

[0089] When the user is ready to use the ticket, they can tap their payment card or crypto wallet on a card reader 1240, such as a gantry (step 3). The card reader 1240 can ask the financial NFT smart contract 1230 for an NFT ticket associated with the payment card by providing the hashed PAN and ticket contract address (step 4). The financial NFT smart contract 1230 looks up tickets owned by the wallet address in crypto wallet 1220 (step 5). The financial NFT smart contract 1230 then returns a list of tickets owned by the cardholder to the card reader 1240, which can match them against the list of tickets and grant entry (step 6).

[0090] Referring to Figure 13, a user can associate a card (hashed PAN) as a financial NFT with a crypto wallet 1320 in a financial NFT smart contract 1330 (step 1). The financial NFT smart contract 1330 is for associating a payment card with a crypto wallet address. The user can then purchase a ticket as an NFT from a seller (step 2).

[0091] When the user is ready to use the ticket, they can tap their crypto wallet on a card reader 1340, such as a gantry (step 3). The card reader 1340 can ask the ticket NFT smart contract 1350 for an NFT ticket associated with the payment card by providing a hashed PAN (step 4). The ticket NFT contract calls the financial NFT smart contract 1330 with the hashed PAN to find the associated wallet address (step 5). The financial NFT smart contract 1330 looks up ticket NFTs owned by the crypto wallet 1320 wallet address returned in step 5 and returns a list of tickets owned by the cardholder (step 6). The card reader 1340 can then match the ticket and grant entry.

[0092] Referring to Figure 14, a user can associate a card (hashed PAN) as a financial NFT with a crypto wallet 1420 in a financial NFT smart contract 1430 (step 1). The financial NFT smart contract 1430 associates the payment card with a crypto wallet address. The user can then purchase a ticket as an NFT from a seller (step 2).

[0093] When the user is ready to use the ticket, they can tap their crypto wallet 1420 on a card reader 1440, such as a gantry (step 3). The card reader 1440 can call the financial NFT smart contract 1430 with the hashed PAN to find the associated wallet address (step 4). The card reader 1440 can then ask the ticket NFT smart contract 1450 for the NFT ticket owned by the wallet address of the crypto wallet 1420 to validate the ticket and grant entry (step 5).

[0094] Figure 15 shows an exemplary sequence diagram of an onboarding flow for onboarding a payment card to make payments in the metaverse environment, and Figure 16 shows an exemplary sequence diagram of a payment flow for making payments in the metaverse environment, according to an embodiment of the present invention. By making financial NFTs the payment token, users can easily onboard their cards to the blockchain and utilize them whenever needed.

[0095] Referring to FIG. 15 , a user 1500 may request 1510 that their card be onboarded to the metaverse blockchain. The request is sent to an issuer 1502 providing the user wallet. The issuer 1502 may send 1515 the request to the payment network 1504 for NFT issuance. The payment network 1504 may create 1520 a new NFT smart contract, mint the NFT on the respective blockchain network 1506, and return the newly minted NFT as a payment token. The blockchain network 1506 may then return 1525 the new financial NFT to the payment network 1504; the payment network 1504 may transfer 1530 the financial NFT to the user wallet provided by the issuer 1502. If no association between the card and the respective blockchain's financial NFT is found, the payment network 1504 may mint a new financial NFT payment token on that blockchain. This token is then stored in a user wallet provided by the issuer 1502.

[0096] Referring to FIG. 16 , a user 1600 can redeem 1620 the financial NFT at a merchant application 1602 in the metaverse world by presenting the token ID to the merchant application 1602. The merchant application 1602 can then contact an acquirer 1604 to request payment 1622. The acquirer 1604 can then contact a payment network 1608 to request payment 1624 using the financial NFT's payment token. The payment network 1608 can route the request to the issuer 1606, asking the issuer 1606 to transfer 1626, 1628 the financial NFT's payment token in the user's wallet to a payment network escrow account 1610. The payment network escrow account 1610 can pass 1630 the financial NFT data to the payment network 1608, which can then process 1632 the validation of the financial NFT.

[0097] Once verification is complete, the payment network 1608 returns the verification result to the issuer 1606 and issues a refund request (1634), so that the financial NFT payment token can be transferred (1636) from the payment network escrow account 1610 to a user wallet provided by the issuer 1606.

[0098] Based on the verification results, the issuer 1606 makes a respective decision to release the funds. If the financial NFT is verified, the issuer 1606 can release 1640 the funds to the acquirer 1604, and the acquirer 1604 can notify 1642 the merchant application 1602 of a successful transaction. If the financial NFT cannot be verified, the issuer 1606 can communicate 1650 that the transaction failed to the acquirer 1604, and the acquirer 1604 can notify 1652 the merchant application 1602 of the failed transaction.

[0099] Figures 17-19 illustrate example scenarios according to embodiments of the present invention. Figure 17 illustrates an example scenario for tokenizing a payment card for Web3 and metaverse transactions. Figure 18 illustrates an example scenario for bidding on an NFT using a tokenized payment card. Figure 19 illustrates an example scenario for transferring an NFT from a seller to a winning bidder user.

[0100] Referring to FIG. 17, a bidder (Account 3) wishes to bid on an NFT using a tokenized payment card. The user tokenizes the payment card before bidding. In the illustrated example, the bidder adds the payment card to a crypto wallet. Tokenization may be performed, for example, using the digitization described in connection with FIG. 3, resulting in a financial NFT containing TUR.

[0101] Referring to Figure 18, if a bidder (Account 3) tokenizes a payment card, the bidder can place a bid using the tokenized payment card. In the illustrated example, the bidder placed a bid of 0.4 MATIC for the Buddha statue NFT using a financial NFT.

[0102] 19, on the auction end date, the seller (account 1) ends the auction, after which the Buddha statue NFT is transferred from the seller (account 1) to the highest bidder. In the illustrated example, bidder (account 3) is the highest bidder, and the Buddha statue NFT is transferred from the seller (account 1) to bidder (account 3).

[0103] FIG. 20 illustrates components of a computing system that may be used in certain embodiments described in this disclosure. Referring to FIG. 20, system 2000 can be implemented on a single computing device or distributed across multiple computing devices or subsystems that cooperate in executing program instructions. System 2000 can include one or more blade server devices, standalone server devices, PCs, routers, hubs, switches, bridges, firewall devices, intrusion detection devices, mainframe computers, NAS devices, and other types of computing devices. The system hardware can be configured according to any suitable computer architecture, such as a symmetric multi-processing (SMP) architecture or a non-uniform memory access (NUMA) architecture.

[0104] System 2000 can include a processing system 2010, which can include one or more processors and / or other circuitry that reads and executes software 2020 from a storage system 2030. Processing system 2010 can be implemented in a single processing device or can be distributed across multiple processing devices or subsystems that cooperate in executing program instructions.

[0105] The storage system 2030 may include any computer-readable storage medium readable by the processing system 2010 and capable of storing the software 2020. The storage system 2030 may be implemented as a single storage device or across multiple storage devices or subsystems that are co-located or distributed with one another. The storage system 2030 may include additional elements, such as a controller that may communicate with the processing system 2010. The storage system 2030 may also include storage devices and / or subsystems in which data is stored. The system 2000 may access one or more storage resources to access information and perform any processing directed by the software 2020.

[0106] Software 2020, including routines for performing processing, may be implemented in program instructions that, among other functions, when executed by system 2000 generally or system 2010 specifically, cause system 2000 or processing system 2010 to operate as described. For example, software 2020 may include, but is not limited to, instructions for smart contract 230 and method 250.

[0107] In implementations in which system 2000 includes multiple computing devices, the server may include one or more communication networks that facilitate communication between the computing devices. For example, the one or more communication networks may include a LAN or WAN that facilitates communication between the computing devices. One or more direct communication links may be included between the computing devices. Also, in some cases, the computing devices may be deployed in geographically dispersed locations. In other cases, multiple computing devices may be deployed in a single geographic location, such as a server farm or an office.

[0108] A communications interface 2040 may be included, which provides communications connections and devices to enable communication between the system 2000 and other computing systems (not shown) over a communications network or collection of networks (not shown) or wirelessly.

[0109] In some embodiments, the system 2000 may provide one or more virtual machines.

[0110] Alternatively or additionally, the functionality of the methods and processes of the present disclosure may be implemented, at least in part, by one or more hardware modules (or logic components). For example, hardware modules may include, but are not limited to, application specific integrated circuits (ASICs), field programmable gate arrays (FPGAs), system-on-a-chip (SoC) systems, complex programmable logic devices (CPLDs), and other programmable logic devices now known or later developed. When a hardware module is activated, the hardware module performs the functions, methods, and processes contained within the hardware module.

[0111] It should be noted that in any case, in this disclosure, the terms "storage medium," "computer-readable storage medium," or "computer-readable storage medium" do not consist of a transitory carrier wave or propagating signal. Instead, "storage" medium refers to a non-transitory medium.

[0112] Although the subject matter may be described in language specific to structural features and / or operations, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or operations described above. Rather, the specific features and operations described above are disclosed as example embodiments of implementing the claims, and other equivalent features and operations are intended to be within the scope of the claims.

Claims

1. receiving, at a smart contract, a request to create a financial NFT from a user's non-custodial wallet, the request to create the financial NFT including encrypted payment card details for the user's payment card; sending a confirmation request to obtain confirmation for the payment card associated with the encrypted payment card details; receiving the confirmation for the payment card, a hashed PAN, and a token unique reference for the payment card at the smart contract; minting a financial NFT corresponding to the payment card in the smart contract, the financial NFT having a financial NFT identifier and the token unique reference; storing in the smart contract a mapping between the financial NFT identifier, the hashed personal account number (PAN), the token unique reference, and a consumer wallet address of the non-custodial wallet; transmitting the financial NFT identifier to the non-custodial wallet.

2. 2. The method of claim 1, wherein sending the confirmation request to obtain confirmation for the payment card associated with the encrypted payment card details comprises sending the confirmation request via an oracle to a financial NFT service.

3. The method of claim 1 further comprising: receiving, at the smart contract, a request for a payment function of the financial NFT, the request including the user's digital signature, a Web3 merchant's public address, and an amount of blockchain value for the transaction; receiving a payment request from the Web3 merchant at the smart contract, the payment request including card transaction details; and transmitting details of the card transaction to a financial NFT service.

4. The method of claim 1 further comprising: receiving a payment request from a Web2 merchant via the smart contract; sending a detokenization request to a financial NFT service requesting that the financial NFT be detokenized.

5. The method of claim 1 further comprising: receiving an authorization request from the non-custodial wallet of the user at the smart contract, the authorization request requesting authorization of the financial NFT with an online merchant; authorizing the financial NFT with the online merchant; storing, in the smart contract, approved financial NFT information including the financial NFT identifier, an approval reference, and a wallet address of the online merchant.

6. The method of claim 5 further comprising: The method includes sending the approved financial NFT information to a metaverse merchant, the online merchant being an online merchant on a metaverse device.

7. The method of claim 5 further comprising: receiving a payment request from the online merchant at the smart contract, the payment request invoking a payment function of the financial NFT, the payment request including transaction details including the financial NFT identifier, the authorization reference, and a transaction amount; and submitting the payment card transaction to a financial NFT service.

8. 8. The method of claim 7, wherein submitting the payment card transaction to the financial NFT service includes adding a smart contract transaction that includes a hash lock.

9. 8. The method of claim 7, wherein submitting the payment request to the financial NFT service includes outputting a transaction hash that includes a single-use, timed cryptogram for the token unique reference.

10. The method of claim 1 further comprising: receiving a request for merchant card-on-file (COF) NFT creation from a merchant at the smart contract, the request for merchant COF NFT creation including a merchant private key, a merchant public address, and the financial NFT identifier; receiving a user private key from the non-custodial wallet; minting a merchant COF NFT having a merchant COF NFT identifier, a merchant identifier, the hashed PAN, and the token unique reference, wherein the merchant COF NFT is owned by the merchant.

11. The method of claim 10 further comprising: receiving a payment request from the merchant, the payment request invoking a payment function of the merchant COF's NFT, the payment request including the merchant public address, the merchant private key, and a transaction amount; and submitting the payment request to a financial NFT service.

12. 12. The method of claim 11, wherein submitting the payment request to the financial NFT service includes adding a transaction of a smart contract that includes a hash lock.

13. 12. The method of claim 11, wherein submitting the payment request to the financial NFT service includes outputting a transaction hash that includes a single-use, timed cryptogram for the token unique reference.

14. One or more computer-readable storage media having instructions stored thereon that, when executed by a processing system, cause the processing system to: receiving, at a smart contract, a request to create a financial NFT from a user's non-custodial wallet, the request to create the financial NFT including encrypted payment card details for the user's payment card; sending a confirmation request to obtain confirmation for the payment card associated with the encrypted payment card details; receiving the confirmation for the payment card, a hashed PAN, and a token unique reference for the payment card at the smart contract; minting a financial NFT corresponding to the payment card in the smart contract, the financial NFT having a financial NFT identifier and the token unique reference; storing in the smart contract a mapping between the financial NFT identifier, the hashed personal account number (PAN), the token unique reference, and a consumer wallet address of the non-custodial wallet; and transmitting the financial NFT identifier to the non-custodial wallet.

15. a processing system; one or more storage media; instructions stored on the one or more storage media that, when executed by the processing system, cause the processing system to at least: receiving, at a smart contract, a request to create a financial NFT from a user's non-custodial wallet, the request to create the financial NFT including encrypted payment card details for the user's payment card; sending a confirmation request to obtain confirmation for the payment card associated with the encrypted payment card details; receiving the confirmation for the payment card, a hashed PAN, and a token unique reference for the payment card at the smart contract; minting a financial NFT corresponding to the payment card in the smart contract, the financial NFT having a financial NFT identifier and the token unique reference; storing in the smart contract a mapping between the financial NFT identifier, the hashed personal account number (PAN), the token unique reference, and a consumer wallet address of the non-custodial wallet; and transmitting the financial NFT identifier to the non-custodial wallet.

Images