Digitization of payment cards for WEB 3.0 and meta universe transactions

Abstract

Systems and techniques are provided for digitization of payment cards for Web 3.0 ("Web3") and meta-universe transactions. The described systems and techniques allow for the use of non-homogenous tokens (NFTs) to represent payment tokens for making payments in Web3 and meta-universe environments. In fact, the described systems and techniques provide a financial NFT-enabled representation of a payment card account as a token in a blockchain network, which may then be used to facilitate Web3 payments through a real-time legal currency to cryptocurrency exchange.

Description

Background Art

[0001] Web 3.0 (Web3) and the Metaverse are becoming increasingly popular with heavy investments from the industry in the coming years. Currently, payments in Web3 / Metaverse rely on either Web3 / Metaverse specific tokens, either as cryptocurrency tokens or as other platform specific credits. This locks funds into a specific ecosystem and in the case of cryptocurrencies, prices fluctuate due to the volatility of cryptocurrencies. Even for payments in fiat currencies, users need to enter the payment method they want to pay with on each platform. Summary of the invention

[0002] Systems and technologies are provided for the digitization of payment cards for Web 3.0 ("Web3") and Metaverse transactions. The described systems and technologies allow the use of non-fungible tokens (NFTs) to represent payment tokens for making payments in Web3 and Metaverse environments. In fact, the described systems and technologies provide a financial NFT-enabled representation of a payment card account as a token in a blockchain network, which token can then be used to facilitate Web3 payments through real-time fiat-to-cryptocurrency exchange.

[0003] This summary is provided to introduce some concepts in a simplified form that are further described in the detailed description below. This summary is neither intended to identify key features or essential features of the claimed subject matter nor to be used to limit the scope of the claimed subject matter. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Figure 1 Illustrated is an example operating environment in which various embodiments of the invention may be practiced.

[0005] Figure 2A Illustrated is an example operating environment and signal flow for digitizing a payment card into a financial NFT for Web3 and Metaverse transactions in accordance with an embodiment of the present invention. Figure 2B Diagram illustrating the process of tokenizing a payment card in a smart contract.

[0006] Figure 3 An example operating environment and signal flow introduced by a merchant according to an embodiment of the present invention is illustrated.

[0007] Figure 4-Figure 8 The diagram illustrates an example operating environment and signal flow for a financial NFT person-to-merchant (P2M) payment transaction use case in accordance with an embodiment of the present invention. Figure 4 Illustrated use case of guest checkout using financial NFTs in Web3; Figure 5 Illustrated use case of guest checkout using financial NFTs in Web2; Fig. 6A Illustrated use case for adding a financial NFT card-on-file (COF) to a merchant or device; Figure 6B Diagram illustrating an example process for creating a merchant COF NFT. Figure 7 Illustrated illustration of the use case of using financial NFT COF for payment in Web3; Figure 8 Diagram illustrating the use case of using financial NFT COF for payment in Web2.

[0008] Figure 9-11 The diagram illustrates an example operating environment and signal flow for a financial NFT person-to-person (P2P) payment transaction use case in accordance with an embodiment of the present invention. Fig. 9 Diagram illustrating the fiat-to-fiat use case; Fig.10 Diagram illustrating the use case of fiat to crypto; Fig.11 Diagram illustrating crypto-to-crypto use cases.

[0009] Figure 12-14 The diagram illustrates an example operating environment and signal flow for associating financial NFTs to implement a value-added service use case in accordance with an embodiment of the present invention.

[0010] Fig.15 An example sequence diagram illustrating an onboarding process for onboarding a payment card for making payments within a Metaverse environment in accordance with an embodiment of the present invention.

[0011] Fig.16 An example sequence diagram illustrating a payment flow procedure for making payments within a Metaverse environment.

[0012] Figure 17-Figure 19 An example scenario is illustrated in accordance with an embodiment of the present invention. Fig.17 Illustrate an example scenario of payment card tokenization for Web3 and Metaverse transactions; Fig.18 Illustration of an example scenario for bidding on NFTs using a tokenized payment card; Fig.19 Diagram illustrating an example scenario of an NFT transfer from a seller to a winning bidder.

[0013] Fig. 20 The diagram illustrates components of a computing system that may be used in certain embodiments herein. DETAILED DESCRIPTION

[0014] Systems and technologies are provided for digitization of payment cards for Web 3.0 ("Web3") and Metaverse transactions. The described systems and technologies allow the use of non-fungible tokens (NFTs) to represent payment tokens for making payments in Web3 and Metaverse environments.

[0015] definition

[0016] “Cryptocurrency” (“crypto”) refers to digital currencies in which transactions are verified and records maintained by a decentralized system using cryptography, rather than by a centralized authority. Examples of cryptocurrencies include Bitcoin, Ethereum, Tether, Solana, and Dogecoin.

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

[0018] "Non-fungible tokens" ("NFTs") refer to digital tokens on a blockchain, each of which represents a different digital / physical asset. Each NFT is unique and cannot be exchanged for another version of itself.

[0019] As used herein, “Financial NFT” refers to a publicly verifiable and non-transferable NFT that represents a tokenized payment card. For example, each Financial NFT may be powered by an ERC-721 smart contract deployed on a supported blockchain. Each Financial NFT has multiple on-chain data elements, such as, but not limited to, a token ID: a unique identifier, a token URI: a link to metadata, a hashed primary account number (“PAN”): a one-way hash of the PAN, and a status: active / inactive / blocked. Token metadata may be stored in a peer-to-peer distributed file system, such as the InterPlanetary File System (IPFS), and may include data elements such as, but not limited to, a name, description, image, and a list of custom properties (in JSON format).

[0020] The sample code listing for financial NFTs includes:

[0021] {

[0022] "name": "****3821",

[0023] "description":"Payment Card,ending 3821",

[0024] "image":"ipfs: / / QmWtmlnLSADTBhjUVmr4Hj9QWBnnxjSkk78DEb3uBJdQ8w",

[0025] "attributes":[

[0026] {

[0027] "trait_type":"ownerAddress",

[0028] "value":"0x507222b2eA12829882210ab5fb6d4868199d835e"

[0029] },

[0030] {

[0031] "trait_type":"hashedPAN",

[0032] “value”:

[0033] "3145269513c69897a766b343be61736803a3f58904bc3c7c1ab51f5c72769b3a"

[0034] },

[0035] {

[0036] "trait_type":"tokenAPI",

[0037] "value":"https: / / card-nft.com / tokens"

[0038] } ]

[0040] }

[0041] Payments made with financial NFTs are recorded in the blockchain and are transparent. That is, payment cards are tokenized into financial NFTs and placed on the blockchain itself. Since the user owns the financial NFT, the user can generate a cryptographic token that can be used on existing payment card rails. Tokenization only provides a one-time token to Web3 / Metaverse merchants. As a result, financial NFTs are more secure because merchants do not have any payment data of the user.

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

[0043] “Minting NFTs” refers to the process of issuing digital assets on a blockchain.

[0044] “Smart contract” refers to a fixed piece of code in the application layer of the blockchain that directly and automatically controls the transfer of digital assets between parties under certain conditions.

[0045] The “metaverse” refers to a simulated digital environment using augmented reality (AR), virtual reality (VR) and blockchain.

[0046] "Web2 wallet" refers to a custodial digital wallet.

[0047] A "web3 wallet" or "cryptocurrency wallet" refers to a digital wallet that stores private keys used to access and manage cryptocurrencies and blockchain-based assets, such as 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. The private key is then used to generate a corresponding public key, which can be used to verify the authenticity of a transaction. By using these keys together, a web3 wallet is able to implement digital identities and 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.

[0048] "Private key" refers to the secret information used to prove ownership of digital assets. It is used to sign transactions sent to the blockchain and only the owner of the digital asset knows it.

[0049] The “public key” refers to the information used to prove that a transaction is signed by the owner of the digital asset. It is used to verify the authenticity of the transaction and can be shared publicly.

[0050] A "public address" can be derived from a public key and can be shared publicly, allowing others to send digital assets to a user's wallet. By providing a unique public address, web3 wallets are able to implement digital identity and prove ownership of digital assets in a secure and decentralized manner.

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

[0052] A "merchant" is a provider of goods or services in exchange for payment. Merchants may be physically present at the point of sale, or remotely located, such as in the case of online retailers.

[0053] An "acquirer" is a party that processes payments on behalf of a merchant in a payment card transaction. An acquirer can be a banking system or other institution associated with a merchant.

[0054] “Card Issuer” means the banking system or other institution that provides payment cards to cardholders.

[0055] The terms "user," "client," and "consumer" are used interchangeably herein.

[0056] An “oracle” is an application that obtains, verifies, and transmits external information (i.e., information stored outside the blockchain) to smart contracts running on the blockchain.

[0057] Current payment methods in the Web3 / Metaverse cryptocurrency world are limited to proprietary coins / tokens belonging to that Web3 / Metaverse blockchain. Even when using fiat currencies, the provider of the Web3 / Metaverse application is the party that holds the payment data. This limits users to a specific ecosystem. Advantageously, through the described systems and techniques, users can securely tokenize payment methods across multiple blockchains via financial NFTs and get a seamless in-game payment experience. Financial NFTs are unique and cannot be replicated in the Web3 / Metaverse cryptocurrency world. Therefore, using financial NFTs for payment will be very beneficial. For security purposes, users can revoke financial NFTs at any time.

[0058] Payments made with financial NFTs are recorded in the blockchain and are transparent. That is, payment cards are tokenized into financial NFTs and placed on the blockchain itself. Since the user owns the financial NFT, the user can generate a cryptographic token that can be used on existing payment card rails. Tokenization only provides a one-time token to Web3 / Metaverse merchants. Thus, financial NFTs provide higher security than current payment methods in the Web3 / Metaverse cryptocurrency world because merchants do not have any payment data of the user.

[0059] Currently, to use existing payment cards in the Web3 / Metaverse world, users must first go to an exchange to add the payment method to their cryptocurrency wallet. Only then can users pay via existing payment cards in the Web3 / Metaverse world. Furthermore, in the Web3 / Metaverse world where everything is decentralized, there is no standard for real-time exchange. In fact, current cryptocurrency exchanges are not integrated with Web3 / Metaverse payments. Advantageously, the described systems and techniques enable real-time payment card to cryptocurrency exchange for Web3 / Metaverse payments.

[0060] Figure 1 The diagram illustrates an example operating environment in which various embodiments of the present invention can be practiced. Figure 1 , an 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 a card issuer 145.

[0061] See also Figure 1, a user can communicate with the user wallet 105 to mint a financial NFT, which can be stored in the user wallet 105, as described in relation to Figure 2A-2B A user may communicate with a user wallet 105 to initiate an online transaction (e.g., with a Web3 / Metaverse merchant server 110), as described with respect to Figure 4-Figure 8 or initiate a transaction at the card reader 130, as described above. Figure 12-14 described.

[0062] The Web3 / Metaverse Merchant Server 110 can communicate with the Financial NFT Service 115 to, for example, introduce a merchant ID or merchant address mapping to add a list of registered merchants on the Financial NFT Smart Contract 120, such as regarding Figure 3 described.

[0063] Through the described use cases, it can be seen that payment cards typically used on payment network 140 can be transformed into financial NFTs for use in the Web3 / Metaverse.

[0064] The components (computing systems, storage resources, etc.) in the operating environment can run on a network (not shown) or communicate with each other through a network. The network can be, but is not limited to, a cellular network (e.g., a wireless phone), a point-to-point dial-up connection, a satellite network, the Internet, a local area network (LAN), a wide area network (WAN), a Wi-Fi network, an ad hoc network, or a combination thereof. Such networks are widely used to connect various types of network elements, such as hubs, bridges, routers, switches, servers, and gateways. The network can include one or more connected networks (e.g., a multi-network environment), including a public network such as the Internet, and / or a private network such as a secure enterprise private network. As will be appreciated by those skilled in the art, access to the network can be provided via one or more wired or wireless access networks.

[0065] In some cases, communication to and from the components may be performed via an application programming interface (API). An API is an interface implemented by a program code component or a hardware component (hereinafter referred to as an "API implementation component") that allows different program code components or hardware components (hereinafter referred to as "API calling components") to access and use one or more functions, methods, procedures, data structures, classes and / or other services provided by the API implementation component. An API may define one or more parameters passed between an API calling component and an API implementation component. An API is typically a set of programming instructions and standards for enabling two or more applications to communicate with each other, and is typically implemented on the Internet as a set of hypertext transfer protocol (HTTP) request messages and a specified format or structure of response messages in accordance with a REST (representational state transfer) or SOAP (simple object access protocol) architecture.

[0066] Figure 2A Illustrate an example operating environment and signal flow for digitizing a payment card into a financial NFT for Web3 and Metaverse transactions in accordance with an embodiment of the present invention. Figure 2A , an example operating environment may include a user 210, a cryptocurrency 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 The diagram illustrates the process of tokenizing a payment card at a smart contract (e.g., the Financial NFT smart contract 230).

[0067] The described digitization of payment cards is similar to "Click to Pay / Secure Remote Commerce (SRC)" and 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.

[0068] The described digitization / tokenization of payment cards is different from the current Web3 way of minting NFTs from previously deployed smart contracts. Figure 2A and Figure 2B , to begin the signal flow of digitizing a payment card into a financial NFT for Web3 and Metaverse transactions, a user 210 may add payment card details (e.g., credit card, debit card, etc.) to a cryptocurrency wallet 220 (e.g., non-custodial), as shown in step 1. In some cases, the user 210 electronically signs when entering the payment card details. The cryptocurrency wallet 220 may encrypt the payment card details and submit a financial NFT creation request to the financial NFT smart contract 230, as shown in step 2. In some cases, the payment card details are encrypted using the financial NFT public key.

[0069] Process 250 may occur at a smart contract on a blockchain (e.g., financial NFT smart contract 230). As described herein, references to smart contracts refer to both the code and the underlying hardware that executes the code.

[0070] At operation 252, the financial NFT smart contract 230 may receive a financial NFT creation request from the cryptocurrency wallet 220. The financial NFT creation request may include encrypted payment card details of the user's 210 payment card.

[0071] The financial NFT smart contract 230 can communicate with the financial NFT service 240, for example via an oracle, to verify the payment card details of the user 210, as shown in step 3. An oracle refers to an entity in a blockchain network that allows access to external data (e.g., a data feed). A smart contract (e.g., a financial NFT smart contract 230) can only access data within the blockchain network. However, the use of an oracle allows a smart contract to 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 may facilitate access to payment authorization results from a card payment network.

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

[0073] At operation 256 , the financial NFT smart contract 230 receives the verification of the payment card, the hashed PAN, and the TUR of the payment card from the financial NFT service 240 .

[0074] The financial NFT smart contract 230 can issue (e.g., mint) a financial NFT 235 and send the financial NFT identifier back to the cryptocurrency wallet 220, as shown in step 4.

[0075] At operation 258, the 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 a TUR. At operation 260, the financial NFT smart contract 230 may store a mapping of the financial NFT identifier, the hashed PAN, and / or the consumer wallet address of the cryptocurrency wallet 220. At operation 262, the financial NFT smart contract 230 may send the financial NFT identifier to the cryptocurrency wallet 220. Each financial NFT includes a unique NFT identifier, a hashed PAN corresponding to the payment card, and a TUR. The financial NFT is displayed on the blockchain as owned by the user.

[0076] Thus, a method is provided, which includes receiving (252) a financial NFT creation request from a user's non-custodial wallet at a smart contract, the financial NFT creation request including encrypted payment card details of the user's payment card; sending (254) a verification request to obtain verification of the payment card associated with the encrypted payment card details; receiving (256) the verification of the payment card, a hashed PAN, and a token-unique reference of the payment card at the smart contract; minting (258) a financial NFT corresponding to the payment card at the smart contract, the financial NFT having a financial NFT identifier (and a token-unique reference); storing (260) a mapping of the financial NFT identifier, a hashed personal account number (PAN), a token-unique reference, and a consumer wallet address of the non-custodial wallet at the smart contract; and sending (262) the financial NFT identifier to the non-custodial wallet.

[0077] Figure 3 The diagram illustrates an example operating environment and signal flow introduced by a merchant according to an embodiment of the present invention. Figure 3 , an 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 registered merchant list 345.

[0078] To start the signal flow introduced by the merchant, the merchant server 310 can log in and register with the financial NFT service 330 through the payment network API gateway 320, as shown in step 1. Then, as shown in step 2, the financial NFT service 330 can add the merchant's ID or wallet address mapping to the registered merchant list 345 in the financial NFT smart contract 340. In some cases, the financial NFT service 330 adds the merchant wallet address to the registered merchant list 345, as shown in optional step 3. In some cases, the merchant server 310 registers multiple wallet addresses for additional devices or additional sub-accounts. The device identification, sub-account identification and / or wallet address mapping are associated with the registered merchant list 345 in the financial NFT smart contract 340, as shown in step 4.

[0079] Figure 4-Figure 8 The diagram illustrates an example operating environment and signal flow for a financial NFT person-to-merchant (P2M) payment transaction use case in accordance with an embodiment of the present invention. Figure 4 Illustrated use case of guest checkout using financial NFTs in Web3; Figure 5 Illustrated use case of guest checkout using financial NFTs in Web2; Figure 6 illustrates the use case of adding a financial NFT Card on File (COF) to a merchant or device; Figure 7Illustrated illustration of the use case of using financial NFT COF for payment in Web3; Figure 8 Diagram illustrating the use case of using financial NFT COF for payment in Web2.

[0080] See also Figure 4-Figure 8 , an example operating environment may include users (e.g., user 410, user 510, user 610, user 710, and user 810), cryptocurrency wallets (e.g., cryptocurrency wallet 420, cryptocurrency wallet 520, and cryptocurrency wallet 620), online merchants (e.g., online merchant 425, online merchant 525, online merchant 725, online merchant 825), one or more financial NFT services (e.g., financial NFT service 440, financial NFT service 540, financial NFT server 740, and financial NFT service 840), and financial NFT smart contracts (e.g., financial NFT smart contract 430, financial NFT smart contract 530, financial NFT smart contract 630, financial NFT smart contract 730, and financial NFT smart contract 830).

[0081] exist Figure 4-Figure 8 Prior to the first step of each signal flow, a user can add a payment card (e.g., a financial NFT) to a cryptocurrency wallet (e.g., via Figure 2A and Figure 2B The process of tokenizing a payment card as described 250). The financial NFT includes a unique TUR.

[0082] See also Figure 4 , to start the signal flow for guest checkout using financial NFTs in the Web3 use case, user 410 starts checkout at the Web3 website / metaverse of online merchant 425, as shown in step 1. Online merchant 425 can be a Web3 native merchant or a merchant in the metaverse environment.

[0083] User 410 connects cryptocurrency wallet 420 (containing minted financial NFTs) to online merchant 425, as shown in step 2. To make a payment using the financial NFT, user 410 provides an electronic signature. The public address of the online merchant 425 and the amount of the blockchain value (e.g., cryptocurrency) are passed to the function in the financial NFT along with the electronic signature of user 410. The output is a transaction hash containing a single-use, time-limited password for TUR. The password can be exchanged with the oracle of the payment network / card issuer. In some cases, before the real-time exchange of fiat currency to cryptocurrency occurs for the address of the online merchant 425, the exchange involves existing tokenization security, such as one-time password verification (OTP) / 3D security verification (3DS).

[0084] The online merchant 425 may submit a payment request to the financial NFT smart contract 430, as shown in step 3. The payment request may include card transaction details. The financial NFT smart contract 430 may submit the card transaction details to the financial NFT service 440, as shown in step 4. In some cases, the financial NFT smart contract 430 submits the card transaction details to the financial NFT service 440 via an oracle. The payment result is sent back to the online merchant 425, as shown in step 5.

[0085] Advantageously, for the exemplary guest checkout utilizing financial NFTs in a Web3 use case, only user 410 needs to sign for each payment transaction.

[0086] See also Figure 5 , to begin the signal flow for guest checkout utilizing financial NFTs in the Web2 use case, user 510 initiates checkout at the Web2 website of online merchant 525, as shown in step 1. Online merchant 525 may be a Web2 native merchant and accept fiat currency, rather than cryptocurrency.

[0087] User 510 connects the cryptocurrency wallet 520 containing the minted financial NFT with the online merchant 525, as shown in step 2. To make a payment using the financial NFT, user 510 provides an electronic signature. The public address, currency code, and payment amount of the online merchant 525 can be passed to the function in the financial NFT along with the electronic signature of user 510.

[0088] The online merchant 525 may submit a payment request to the financial NFT smart contract 530, as shown in step 3. The financial NFT smart contract 530 may request de-tokenization of the financial NFT, for example via an oracle, as shown in step 4. The de-tokenized payment card details may be sent back to the online merchant 525, as shown in step 5. The online merchant 525 may then process the payment as a traditional payment card transaction.

[0089] In an exemplary guest checkout utilizing financial NFTs in a Web2 use case, there are multiple options for value transfer. In some cases, the output of calling a smart contract function in a financial NFT for a value transfer adds a smart contract transaction containing a hash lock that will be picked up by the financial NFT service 540 (acting as a listener listener). In this case, the output will be processed on the existing payment card rails. Based on a successful outcome, the value transfer to the merchant is unlocked.

[0090] In some cases, the output of calling a smart contract function in a financial NFT to transfer value may be a transaction hash containing a single-use time-limited password for TUR. TUR can be exchanged with an oracle of a payment network / card issuer. In some cases, existing tokenization security, such as OTP verification / 3DS, occurs before the real-time exchange of fiat currency to cryptocurrency occurs to the address of the online merchant 525.

[0091] In the exemplary guest checkout utilizing financial NFTs in the Web2 use case, the transaction risk of value transfer depends on the card issuer because the card issuer authenticates the transaction on the existing card track. For the exemplary guest checkout utilizing financial NFTs in the Web2 use case, only the user 510 needs to sign for each payment transaction.

[0092] See also Fig. 6A To add a financial NFT Card of Record (COF) to a merchant or device, a user can visit the online merchant’s Web3 / Metaverse website, add the financial NFT, and authorize the financial NFT to be used with the online merchant.

[0093] exist Fig. 6A In an exemplary use case, to begin the signal flow, a user 610 may sign to add a financial NFT to an online merchant device / metaverse device in a metaverse 640, as shown in step 1. The user may send an authorization request to the financial NFT smart contract 630 via a cryptocurrency wallet 620 requesting authorization of the financial NFT to the online merchant device / metaverse device, as shown in step 2. Authorizing the financial NFT may include storing authorized financial NFT information and an authorization reference at the financial NFT smart contract 630. The authorized financial NFT information may include a financial NFT identifier of the financial NFT and a wallet address of the merchant and / or merchant device. The authorized financial NFT information (e.g., the NFT identifier, the wallet address of the merchant / device, and the authorization reference) may be stored in the metaverse 640, as shown in step 3. Although Fig. 6A The illustrative example shows an online merchant on the Metaverse, but the merchant could be on Web3 or even Web2.

[0094] In some cases, such as Figure 6B As shown in the diagram, authorizing a financial NFT may include minting a new merchant COF NFT in the financial NFT smart contract 630.

[0095] Figure 6B The diagram illustrates an example process for creating a merchant COF NFT. In some cases, a merchant-specific financial NFT (i.e., a “merchant COF NFT”) may be created by creating a financial NFT corresponding to a payment card (e.g., as described in relation to Figure 2A The financial NFT 235) is minted by a smart contract.

[0096] See also Figure 6B , process 650 may begin when the financial NFT smart contract 630 receives (652) a merchant COF NFT request from a merchant (e.g., a merchant operating on a Web3 / metaverse website). In some cases, the merchant may request a COF NFT by calling an existing user-owned financial NFT (e.g., Figure 2A The merchant COF NFT request may include (and in some cases, require) the user's signature (e.g., the user's private key).

[0097] A merchant COF NFT request may include a merchant private key, a merchant public address (e.g., a merchant cryptocurrency wallet public address), and a financial NFT identifier. In some cases, a merchant may generate a merchant COF NFT request by calling a function on a user-owned financial NFT corresponding to a payment card, which requires the consumer to sign (e.g., using the user's private key). A merchant COF NFT may be signed by the user's private key and / or the merchant's private key (e.g., multi-signature).

[0098] The financial NFT smart contract 630 receives (654) the user private key from the cryptocurrency wallet 620. The user private key indicates to the financial NFT smart contract 630 that the user agrees to mint the merchant COF NFT, which will instruct the merchant to obtain permission to use the financial NFT indicated by the merchant COF NFT (e.g., via a TUR indication).

[0099] Once the financial NFT smart contract 630 receives the user private key, the financial NFT smart contract 630 can mint (656) a merchant COF NFT. The merchant COF NFT can include a merchant COF NFT identifier, a merchant identifier, a hash PAN (i.e., the user's primary account number), and a TUR. With the signatures of both the merchant and the user, the financial NFT smart contract 630 can use the information of the financial NFT stored in the financial NFT smart contract 630 (e.g., the user's hash PAN and TUR) to mint the merchant COF NFT. The merchant COF NFT appears on the blockchain as owned by the merchant and signed by the user (as opposed to the financial NFT that appears on the blockchain as owned by the user / payment card owner). Advantageously, minting a merchant COF NFT allows the merchant to call the merchant COF NFT as a "card on file" for transactions conducted by the user at that particular merchant. Thus, users will be able to use their merchant COF NFTs for quick checkout at Web3 / metaverse merchants (similar to how their payment cards are stored on file as if in the case of Web2 merchants).

[0100] See also Figure 7 , in order to use a financial NFT as a COF (or similarly, to use a merchant COF NFT), the online merchant 725 can call the "makePayment" function of the financial NFT COF by passing the public address of the online merchant 725 and the amount of the blockchain value (cryptocurrency), as well as the signature. This will generate a unique password that can be used in traditional card payment processing along with the TUR to complete the payment transaction via BankNet / ISO8583, for example.

[0101] To begin the signal flow of an exemplary financial NFT COF payment in a Web3 use case, user 710 may select a financial COF NFT (e.g., a merchant COF NFT) from a list of NFTs stored at an online merchant 725 and confirm payment, as shown in step 1. Online merchant 725 may sign using a private key and submit the transaction, as shown in step 2. In some cases, online merchant 725 is located within the metaverse. In some cases, online merchant 725 is located on Web3. Transaction details may include a financial NFT identifier, an authentication reference, and / or a transaction amount.

[0102] The financial NFT smart contract 730 may submit a payment card transaction, for example via an oracle, as shown in step 3. The payment result may then be sent back to the online merchant 725, as shown in step 4.

[0103] In the exemplary merchant COF NFT payment in the Web3 use case, there are multiple options for value transfer. In some cases, the output of calling a smart contract function in a financial NFT for a value transfer will add a smart contract transaction containing a hash lock that will be picked up by the financial NFT service 740 (acting as a listener listener). The "output" is processed on the existing payment card track and, depending on the successful result, unlocks the value transfer to the online merchant 725.

[0104] In some cases, the output of calling a smart contract function in a financial NFT to transfer value will be a transaction hash containing a single-use, time-limited cryptogram for TUR, which can be exchanged with an oracle at the payment network / issuer and can optionally involve existing tokenization security such as OTP verification / 3DS before a real-time exchange of fiat to crypto occurs to the address of the online merchant 725.

[0105] See also Figure 8, to begin the signal flow for payment utilizing a financial NFT COF in a Web2 use case, a user 810 may initiate checkout at an online merchant 825, where the online merchant 825 is a Web2 native merchant, as shown in step 1. The user 810 may select click to pay / financial NFT from a list of stored NFTs and confirm payment. The online merchant 825 may sign and submit the payment transaction using a private key, as shown in step 2. The payment transaction details may include a financial NFT identifier, an authentication reference, and / or a transaction amount. The financial NFT smart contract 830 may request detokenization, for example, via an oracle, as shown in step 3. The detokenized payment card details may then be sent back to the online merchant 825, as shown in step 4. The online merchant 825 may then process the payment as a traditional payment card transaction.

[0106] In the exemplary financial NFT COF payment in the Web2 use case, there are multiple options for value transfer. In some cases, the output of calling a smart contract function in a financial NFT for a value transfer will add a smart contract transaction containing a hash lock that will be picked up by the financial NFT service 840 (acting as a listener listener). In this case, the output will be processed on the existing payment card track. Based on the successful result, the value transfer to the online merchant 825 is unlocked.

[0107] In some cases, the output of calling a smart contract function in a financial NFT to transfer value will be a transaction hash containing a single-use time-limited password for TUR. TUR can be exchanged with an oracle of a payment network / card issuer. In some cases, existing tokenization security, such as OTP verification / 3DS, occurs before the real-time conversion of fiat currency to cryptocurrencies occurs to the address of the online merchant 825.

[0108] In the exemplary use case, the transaction risk of the value transfer lies with the card issuer, as the card issuer authenticates the transaction on existing payment card rails.

[0109] For the COF use case, only the online merchant 825 needs to sign for each payment transaction and the user 810 needs to sign during the tokenization process.

[0110] Figure 9-11 The diagram illustrates an example operating environment and signal flow for a financial NFT P2P payment transaction use case according to an embodiment of the present invention. Fig. 9 Diagram illustrating the fiat-to-fiat use case; Fig.10 Diagram illustrating the use case of fiat to crypto; Fig.11 Diagram illustrating crypto-to-crypto use cases.

[0111] See also Figure 9-11, an example operating environment may include users (e.g., first user 910, first user 1010, and first user 1110), cryptocurrency wallets (e.g., cryptocurrency wallet 920, cryptocurrency wallet 1020, and cryptocurrency wallet 1120), one or more financial NFT services (e.g., financial NFT service 940, financial NFT service 1040, and financial NFT service 1140), and financial NFT smart contracts (e.g., financial NFT smart contract 930, financial NFT smart contract 1030, and financial NFT smart contract 1130).

[0112] exist Figure 9-11 Before the first step of each signal flow, the user can add the payment card to the cryptocurrency wallet. Adding the payment card to the cryptocurrency wallet may involve tokenization (e.g., Figure 3 digitization of the description), and the result is a financial NFT containing TUR.

[0113] See also Fig. 9 , to begin the signal flow for the fiat-to-fiat P2P payment use case utilizing a financial NFT, a first user 910 may select a financial NFT as a source of funds and then enter the receiving NFT identifier of a second user (not shown) and the transaction amount, as shown in step 1. The first user 910 may provide an electronic signature to initiate the P2P payment transaction, as shown in step 2. The cryptocurrency wallet 920 may submit a P2P payment request to the financial NFT smart contract 930, as shown in step 3. The financial NFT smart contract 930 may submit payment card transaction details to the financial NFT service 940, for example via an oracle, as shown in step 4. The P2P payment result may then be sent back to the cryptocurrency wallet 920, as shown in step 5.

[0114] See also Fig.10 , to begin the signal flow for the fiat-to-cryptocurrency P2P payment use case utilizing a financial NFT, a first user 1010 may select financial NFT as a source of funds and then enter a receiving cryptocurrency wallet address of a second user (not shown) and the P2P payment transaction amount, as shown in step 1. The first user 1010 may provide an electronic signature to initiate the P2P payment transaction, as shown in step 2. The cryptocurrency wallet 1020 may submit a P2P payment request to the financial NFT smart contract 1030, as shown in step 3. The financial NFT smart contract 1030 may submit payment card transaction information to the financial NFT service 1040, for example via an oracle, as shown in step 4. The P2P payment result may then be sent back to the cryptocurrency wallet 1020, as shown in step 5.

[0115] See also Fig.11, to begin the signal flow for the cryptocurrency-to-cryptocurrency P2P payment use case utilizing a financial NFT, the first user 1010 may select a cryptocurrency balance as a funding source and then enter the receiving NFT identifier of the second user (not shown) and the transaction amount, as shown in step 1. The first user 1010 may provide an electronic signature to initiate the P2P payment transaction, as shown in step 2. The cryptocurrency wallet 1020 may submit a P2P payment request to the financial NFT smart contract 930, as shown in step 3. The financial NFT smart contract 930 may receive the cryptocurrency payment, as shown in step 4. The financial NFT smart contract 1030 may submit payment card transaction information, for example via an oracle, as shown in step 5. The P2P payment result may then be sent back to the cryptocurrency wallet 1020, as shown in step 6.

[0116] Figure 12-14 The diagram illustrates an example operating environment and signal flow for associating financial NFTs to implement a value-added service use case in accordance with an embodiment of the present invention.

[0117] See also Fig.12 , the user can associate the card (hash PAN) as a financial NFT with the cryptocurrency wallet 1220 in the financial NFT smart contract 1230, as shown in step 1. The financial NFT smart contract 1230 is used for payment card to cryptocurrency wallet address mapping. The user can then purchase tickets from merchants in the form of NFTs, as shown in step 2.

[0118] When the user is ready to use the ticket, the user can tap the payment card or cryptocurrency wallet on a card reader 1240, such as a door hanger, as shown in step 3. The card reader 1240 can ask the financial NFT smart contract 1230 for the NFT ticket mapped to the payment card by providing the hashed PAN and the ticket contract address, as shown in step 4. The financial NFT smart contract 1230 looks up the tickets owned by the wallet address of the cryptocurrency wallet 1220, as shown in step 5. The financial NFT smart contract 1230 can then return a list of tickets owned by the card owner to the card reader 1240, which can check the ticket list and allow entry, as shown in step 6.

[0119] See also Fig.13 , the user can associate the card (hash PAN) as a financial NFT with the cryptocurrency wallet 1320 in the financial NFT smart contract 1330, as shown in step 1. The financial NFT smart contract 1330 is used for payment card to cryptocurrency wallet address mapping. The user can then purchase tickets from merchants in the form of NFTs, as shown in step 2.

[0120] When the user is ready to use the ticket, the user can tap the cryptocurrency wallet on a card reader 1340, such as a door hanger, as shown in step 3. The card reader 1340 can ask the Ticket NFT smart contract 1350 for the NFT ticket mapped to the payment card by providing the hashed PAN, as shown in step 4. The Ticket NFT contract uses the hashed PAN to call the Financial NFT smart contract 1330 to find out the mapped wallet address, as shown in step 5. The Financial NFT smart contract 1330 finds out the Ticket NFT owned by the wallet address of the cryptocurrency wallet 1320 returned in step 5, and returns a list of tickets owned by the card owner, as shown in step 6. The card reader 1340 can then check the ticket and allow entry.

[0121] See also Fig.14 , the user can associate the card (hash PAN) as a financial NFT with the cryptocurrency wallet 1420 in the financial NFT smart contract 1430, as shown in step 1. The financial NFT smart contract 1430 is used for payment card to cryptocurrency wallet address mapping. The user can then purchase tickets from merchants in the form of NFTs, as shown in step 2.

[0122] When the user is ready to use the ticket, the user can tap the cryptocurrency wallet 1420 on a card reader 1440, such as a door hanger, as shown in step 3. The card reader 1440 can call the financial NFT smart contract 1430 with the hashed PAN to find out the mapped wallet address, as shown in step 4. The card reader 1440 can ask the ticket NFT smart contract 1450 for the NFT ticket owned by the wallet address of the cryptocurrency wallet 1420, and then verify the ticket and allow entry, as shown in step 5.

[0123] Fig.15 An example sequence diagram illustrating an introduction process of introducing a payment card for making payments within a Metaverse environment according to an embodiment of the present invention; Fig.16 An example sequence diagram illustrating the payment flow for making payments within the Metaverse environment. Utilizing financial NFTs as payment tokens, users can easily introduce their cards into the blockchain and use it when needed.

[0124] See also Fig.15, user 1500 can request (1510) to introduce their card into the Metaverse blockchain. The request is sent to the card issuer 1502, which hosts the user's wallet. The card issuer 1502 can send (1515) a request to the payment network 1504 for NFT issuance. The payment network 1504 can create (1520) a new NFT smart contract to mint the NFT on the corresponding blockchain network 1506 and return the newly minted NFT as a payment token. Here, the blockchain network 1506 can return (1525) the new financial NFT to the payment network 1504; and the payment network 1504 can transfer (1530) the financial NFT to the user wallet hosted by the card issuer 1502. If no mapping of the card to the financial NFT of the corresponding blockchain is found, the payment network 1504 can mint a new financial NFT payment token on the blockchain. The token is then saved in the user's wallet hosted by the card issuer 1502.

[0125] See also Fig.16 , user 1600 can checkout (1620) with the financial NFT at the merchant application 1602 in the metaverse world by indicating the token id to the merchant application 1602. The merchant application 1602 can then contact the acquirer 1604 to request (1622) payment. The acquirer 1604 can then contact the payment network 1608 to request (1624) payment using the financial NFT payment token. The payment network 1608 can route the request to the card issuer 1606 and request (1626) the card issuer 1606 to transfer (1628) the financial NFT payment token in the user's wallet to the payment network escrow account 1610. The payment network escrow account 1610 can pass (1630) the financial NFT data to the payment network 1608, and the payment network 1608 can process the financial NFT verification (1632).

[0126] Upon completion of the verification, the payment network 1608 may return the verification results to the issuer 1606 and then issue (1634) a refund request to transfer (1636) the financial NFT payment token from the payment network escrow account 1610 back to the user wallet hosted by the issuer 1606.

[0127] Based on the verification results, the card issuer 1606 makes a corresponding decision to release the funds. If the financial NFT is verified, the card issuer 1606 can release (1640) the funds to the acquirer 1604, and the acquirer 1614 can notify (1642) the merchant application 1602 of the successful transaction. If the financial NFT is not verified, the card issuer 1606 can communicate (1650) the transaction failure to the acquirer 1604, and the acquirer 1604 can notify (1652) the merchant application 1602 of the failed transaction.

[0128] Figure 17-Figure 19 An example scenario is illustrated in accordance with an embodiment of the present invention. Fig.17 Illustrate an example scenario of payment card tokenization for Web3 and Metaverse transactions; Fig.18 Illustration of an example scenario for bidding on NFTs using a tokenized payment card; Fig.19 Diagram illustrating an example scenario of an NFT transfer from a seller to a winning bidder.

[0129] See also Fig.17 , a bidder (Account 3) wants to bid on an NFT using a tokenized payment card. The user tokenizes the payment card before bidding. In the illustrative example, the bidder adds the payment card to a cryptocurrency wallet. Tokenization can be done, for example, using Figure 3 The digitization described is performed, and the result is a financial NFT containing TUR.

[0130] See also Fig.18 Once the bidder (account 3) tokenizes the payment card, the bidder can then bid using the tokenized payment card. In the illustrative example, the bidder bids 0.4 MATIC for the Buddha statue NFT using the financial NFT.

[0131] See also Fig.19 On the auction end day, 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 illustrative example, the bidder (account 3) has the highest bid, and the Buddha statue NFT is transferred from the seller (account 1) to the bidder (account 3).

[0132] Fig. 20 The diagram illustrates components of a computing system that may be used in certain embodiments described herein. Fig. 20 , system 2000 can be implemented within a single computing device, or can be distributed across multiple computing devices or subsystems that collaborate when executing program instructions. System 2000 may include one or more blade server devices, stand-alone server devices, personal computers, routers, hubs, switches, bridges, firewall devices, intrusion detection devices, mainframe computers, network attached storage devices, and other types of computing devices. System hardware can be configured according to any suitable computer architecture, such as a symmetric multiprocessing (SMP) architecture or a non-uniform memory access (NUMA) architecture.

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

[0134] The storage system 2030 may include any computer-readable storage medium that can be read by the processing system 2010 and that can store the software 2020. The storage system 2030 may be implemented as a single storage device, but may also be implemented across multiple storage devices or subsystems that are co-located or distributed relative to each other. The storage system 2030 may include additional elements that can communicate with the processing system 2010, such as a controller. The storage system 2030 may also include storage devices and / or subsystems on which data is stored. The system 2000 may access one or more storage resources in order to access information to perform any process indicated by the software 2020.

[0135] Software 2020, including routines for performing processes, may be implemented with program instructions and, among other functions, when executed by system 2000 in general, or processing system 2010 in particular, may instruct system 2000 or processing system 2010 to operate as described herein. For example, software 2020 may include, but is not limited to, instructions for smart contract 230 and method 250.

[0136] In embodiments where the 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 local area network or a wide area network that facilitates communication between the computing devices. One or more direct communication links may be included between the computing devices. Additionally, in some cases, the computing devices may be installed in geographically dispersed locations. In other cases, multiple computing devices may be installed in a single geographic location, such as a server farm or an office.

[0137] A communications interface 2040 may be included that provides communications connections and devices that allow communications between the system 2000 and other computing systems (not shown) over a communications network or collection of networks (not shown) or over the air.

[0138] In some embodiments, system 2000 may host one or more virtual machines.

[0139] Alternatively or additionally, the functions, methods, and processes described herein may be implemented at least in part by one or more hardware modules (or logic components). For example, a hardware module may include, but is not limited to, an application specific integrated circuit (ASIC) chip, a field programmable gate array (FPGA), a system on a chip (SoC) system, a complex programmable logic device (CPLD), and other programmable logic devices now known or developed later. When a hardware module is activated, the hardware module performs the functions, methods, and processes included in the hardware module.

[0140] It should be understood that the terms "storage medium", "computer-readable storage medium" or "computer-readable storage medium" used herein do not consist of transient carrier waves or propagation signals under any circumstances. Instead, "storage" media refers to non-transient media.

[0141] Although the subject matter has been described in language specific to structural features and / or actions, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Instead, the specific features and actions described above are disclosed as examples of implementing the claims, and other equivalent features and actions are intended to be within the scope of the claims.

Claims

1. A method comprising: Receiving, at a smart contract, a financial NFT creation request from a non-custodial wallet of a user, the financial NFT creation request including encrypted payment card details of a payment card of the user; sending a verification request to obtain verification of a payment card associated with the encrypted payment card details; Receiving at the smart contract the verification of the payment card, the hashed PAN, and the token unique reference of the payment card; Minting a financial NFT corresponding to the payment card at a smart contract, the financial NFT having a financial NFT identifier and the token unique reference; Storing at a smart contract a mapping of the financial NFT identifier, a hashed personal account number (PAN), a token unique reference, and a consumer wallet address of a non-custodial wallet; as well as Sending the financial NFT identifier to the non-custodial wallet.

2. The method according to claim 1, wherein: Sending a verification request to obtain verification of a payment card associated with the encrypted payment card details includes sending the verification request to a financial NFT service via an oracle.

3. The method according to claim 1, further comprising: Receive a payment function request for a financial NFT at the smart contract, including the user’s electronic signature, the Web3 merchant’s public address, and the blockchain value of the transaction; receiving, at the smart contract, a payment request from a Web3 merchant, wherein the payment request includes card transaction details; and Send the card transaction details to the financial NFT service.

4. The method according to claim 1, further comprising: Receive payment requests from Web2 merchants at the smart contract; as well as Send a detokenization request to the Financial NFT Service to detokenize the Financial NFT.

5. The method according to claim 1, further comprising: Receiving, at a smart contract, an authorization request from a non-custodial wallet of a user, the authorization request requesting authorization of a financial NFT to an online merchant; Licensing financial NFTs to online merchants; as well as Authorized financial NFT information is stored at the smart contract, including the financial NFT identifier, authorization reference, and wallet address of the online merchant.

6. The method according to claim 5, further comprising: Send the authorized financial NFT information to a Metaverse merchant, where the online merchant is an online merchant on a Metaverse device.

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

8. A method according to claim 7, wherein submitting the payment card transaction to the financial NFT service includes adding a smart contract transaction containing a hash lock.

9. A method according to claim 7, wherein submitting the payment request to the financial NFT service includes outputting a transaction hash, wherein the transaction hash includes a single-use time-limited password for uniquely referencing the token.

10. The method according to claim 1, further comprising: Receiving, at a smart contract, a merchant card-on-file (COF) NFT creation request from a merchant, the merchant COF NFT creation request including a merchant private key, a merchant public address, and a financial NFT identifier; Receive user private keys from a non-custodial wallet; as well as 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 according to claim 10, further comprising: Receive a payment request from a merchant, the payment request calling the payment function of the merchant COF NFT, wherein the payment request includes the merchant public address, the merchant private key and the transaction amount; as well as Submit the payment request to the financial NFT service.

12. A method as claimed in claim 11, wherein submitting the payment request to the financial NFT service includes adding a smart contract transaction containing a hash lock.

13. A method as claimed in claim 11, wherein submitting the payment request to the financial NFT service includes outputting a transaction hash, wherein the transaction hash includes a single-use time-limited password for uniquely referencing the token.

14. One or more computer-readable storage media having stored thereon instructions which, when executed by a processing system, direct the processing system to perform a method comprising: Receiving, at a smart contract, a financial NFT creation request from a non-custodial wallet of a user, the financial NFT creation request including encrypted payment card details of a payment card of the user; sending a verification request to obtain verification of a payment card associated with the encrypted payment card details; Receiving at the smart contract the verification of the payment card, the hashed PAN, and the token unique reference of the payment card; Minting a financial NFT corresponding to the payment card at a smart contract, the financial NFT having a financial NFT identifier and the token unique reference; Storing at a smart contract a mapping of the financial NFT identifier, a hashed personal account number (PAN), a token unique reference, and a consumer wallet address of a non-custodial wallet; as well as Sending the financial NFT identifier to the non-custodial wallet.

15. A system comprising: Processing systems; one or more storage media; and Instructions stored on the one or more storage media, which, when executed by the processing system, direct the processing system to at least: Receiving, at a smart contract, a financial NFT creation request from a non-custodial wallet of a user, the financial NFT creation request including encrypted payment card details of a payment card of the user; sending a verification request to obtain verification of a payment card associated with the encrypted payment card details; Receiving at the smart contract the verification of the payment card, the hashed PAN, and the token unique reference of the payment card; Minting a financial NFT corresponding to the payment card at a smart contract, the financial NFT having a financial NFT identifier and the token unique reference; Storing at a smart contract a mapping of the financial NFT identifier, a hashed personal account number (PAN), a token unique reference, and a consumer wallet address of a non-custodial wallet; as well as Sending the financial NFT identifier to the non-custodial wallet.

Images