Non-fungible tokens for payment

Abstract

Various embodiments are disclosed for providing a non-fungible token (NFT) as a mechanism for verifying ownership of a payment instrument, such as a stored-value payment instrument. First, a computing device may receive a purchase notification indicating that a first user has purchased the stored-value payment instrument. The computing device may then create a non-fungible token (NFT) on a distributed data store in response to receiving the purchase notification. The computing device may then associate a unique identifier of the NFT with the stored-value payment instrument. The computing device may then receive a first public key associated with the first user. The computing device may then update an owner identifier of the NFT with the first public key associated with the first user.

Description

[Technical field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to and the benefit of co-pending U.S. patent application Ser. No. 17 / 472,161, filed Sep. 10, 2021, and entitled “NON-FUNGIBLE TOKENS FOR PAYMENT INSTRUMENTS.” [Background technology]

[0002] Ownership of a payment instrument is often tied directly to the payment instrument itself. For example, the owner of a credit or debit card account is often included in the information for the account itself. However, some payment instruments are not directly associated with a particular individual. For example, gift cards, prepaid debit cards, and other stored-value payment instruments are often not associated with any particular individual such that they may be readily transferred between individuals (e.g., as a gift). As a result, it can be difficult to determine whether someone is an authorized owner or user of a given stored-value payment instrument. Summary of the Invention [Means for solving the problem]

[0003] Many aspects of the present disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the disclosure. Moreover, in the drawings, like reference numbers indicate corresponding parts throughout the several views. [Brief description of the drawings]

[0004] [Figure 1] FIG. 1 illustrates a network environment in accordance with various embodiments of the present disclosure. [Diagram 2]FIG. 2 is a sequence diagram illustrating an example of purchasing and transferring ownership of a stored-value payment instrument in the network environment of FIG. 1 according to various embodiments of the present disclosure. [Diagram 3] FIG. 3 is a sequence diagram illustrating a second example of purchasing and transferring ownership of a stored-value payment instrument in the network environment of FIG. 1 according to various embodiments of the present disclosure. [Figure 4] FIG. 4 is a flowchart illustrating one example of an issuer service for redemption of a stored-value payment instrument using an NFT in the network environment of FIG. 1 according to various embodiments of the present disclosure. [Diagram 5] FIG. 5 is a flowchart illustrating one example of the functionality of an issuer service for creating an NFT and linking the NFT to a stored-value payment instrument in the network environment of FIG. 1 according to various embodiments of the present disclosure. [Figure 6] FIG. 6 is a flowchart showing one example of the functionality of an issuer service for verifying ownership of an NFT in the network environment of FIG. 1 according to various embodiments of the present disclosure. [Figure 7] FIG. 7 is a flowchart illustrating one example of the functionality of an issuer service for revoking, destroying, or otherwise rendering an NFT non-transferable in the network environment of FIG. 1 in accordance with various embodiments of the present disclosure. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0005] Various techniques are disclosed for using non-fungible tokens (NFTs) to identify and verify the owner or authorized user of a bearer instrument, such as a stored-value payment instrument. An NFT may be created when a stored-value payment instrument is created and / or issued to a first user. The NFT may be directly associated with the stored-value payment instrument and the first user. Thus, a transfer of ownership of an NFT from a first user to a second user may serve as a transfer of ownership of the associated stored-value payment instrument. When a request to activate, redeem, or otherwise access or use a stored-value payment instrument is received, information in the request may be compared to information stored in the NFT to determine whether the request is being made by the actual owner of the NFT and thus the actual owner of the stored-value payment instrument.

[0006] As a result, various embodiments of the present disclosure provide improvements to payment processing systems by implementing additional features not previously available, including the ability to determine whether a request to activate, redeem, or otherwise access or use a stored-value payment instrument is from the current owner of the stored-value payment instrument or from an unauthorized party, thereby improving the security of stored-value payment instruments because an unauthorized party cannot activate, redeem, or otherwise access or use a stored-value payment instrument that they do not own.

[0007] The following description provides an overview of the system and its components, followed by a description of their operation. The following description illustrates examples of the operation of various components of the disclosure, but use of the following examples does not exclude other implementations that are consistent with the principles disclosed by the following examples.

[0008] 1, a network environment 100 according to various embodiments is shown. The network environment 100 can include a publisher computing environment 103, one or more client devices 106, and a distributed data store 109, which can communicate data with each other via a network 113.

[0009] The network 113 may include a wide area network (WAN), a local area network (LAN), a personal area network (PAN), or a combination thereof. These networks may include wired or wireless components, or a combination thereof. Wired networks may include Ethernet networks, cable networks, fiber optic networks, and telephone networks such as dial-up, digital subscriber line (DSL), and integrated services digital network (ISDN) networks. Wireless networks may include cellular networks, satellite networks, Institute of Electrical and Electronic Engineers (IEEE) 802.11 wireless networks (i.e., WI-FI), BLUETOOTH networks, microwave transmission networks, and other networks that rely on radio broadcasting. The network 113 may also include a combination of two or more networks 113. Examples of the network 113 may include the Internet, an intranet, an extranet, a virtual private network (VPN), and similar networks.

[0010] The publisher computing environment 103 may include one or more computing devices that include a processor, memory, and / or a network interface. For example, a computing device may be configured to perform operations on behalf of other computing devices or applications. As another example, such a computing device may host content and / or provide content to other computing devices in response to requests for the content.

[0011] Additionally, the issuer computing environment 103 may employ multiple computing devices that may be arranged in one or more server banks or computer banks or other configurations. Such computing devices may be located at a single location or may be distributed across many different geographic locations. For example, the issuer computing environment 103 may include multiple computing devices that may together comprise hosted computing resources, grid computing resources, or any other distributed computing configuration. In some cases, the issuer computing environment 103 may accommodate flexible computing resources, where the allocated processing power, network, storage, or other computing-related resources may change over time.

[0012] A variety of applications or other functions may run in the issuer computing environment 103. Components running in the computing issuer environment 103 include issuer services 116 and possibly other applications.

[0013] Additionally, the issuer data store 119 stores various data accessible to the issuer computing environment 103. The issuer data store 119 may represent multiple issuer data stores 119, which may include relational or non-relational databases, such as object-oriented databases, hierarchical databases, hash tables, or similar key-value data stores, and other data storage applications or data structures. Additionally, these databases, data storage applications, and / or data structures may be combined and used together to provide a single logical data store. Data stored in the issuer data store 119 is associated with the operation of various application or functional entities, as described below. This data may include one or more stored value payment instruments 123, and possibly other data.

[0014] A stored value payment instrument 123 may represent any payment instrument that has a preset or predefined monetary value associated with it that a user can use to pay a merchant in exchange for goods or services. This may include a prepaid currency account where a user purchases a stored value payment instrument 123 with an initial value. In some cases, a stored value payment instrument 123 may be replenishable, where a user may deposit additional funds within an account linked to the stored value payment instrument 123 to increase the amount of funds associated with the payment instrument itself. Examples of stored value payment instruments 123 include open loop gift or payment cards, closed loop gift or payment cards, prepaid debit cards, etc.

[0015] Thus, the stored value payment instrument 123 may include various data to enable the stored value payment instrument 123 to be used as a payment instrument or transferred between individuals. This data may include the payment information 126, NFT owner public key 129, status 133, and account balance 136 of the stored value payment instrument 123. Additional data or information may be stored in association with the stored value payment instrument 123 as needed for various implementations.

[0016] Payment information 126 may represent information that would enable the stored value payment instrument 123 to be used in a transaction. For example, if the stored value payment instrument 123 is an open loop gift card, an open loop payment card, or a prepaid debit card, this may include an account number, an expiration date, a card security code (CSC), a card verification value (CVV), a card verification code (CVC), a card identification number (CID), etc., for use in making a payment.

[0017] The NFT identifier 129 represents a unique identifier for each NFT 131 that uniquely identifies the NFT 131 with respect to other NFTs 131. The NFT identifier 129 can be formatted in a variety of formats depending on the standard to which the NFT 131 complies. Example NFT standards include the ETHREUM ERC-721 standard, the ETHREUM ERC-1155 standard, the FLOW blockchain NFT standard, etc. The NFT 131 can be used to determine ownership of the stored value payment instrument 123 or to transfer ownership between individuals, as discussed further.

[0018] Status 133 may represent the current state of stored-value payment instrument 133, which may be used to determine whether a transaction can be authorized, whether stored-value payment instrument 123 can be transferred, etc. Example values ​​for Status 133 may be "unsettled", "settled", "expired", "invalid", "revoked", etc.

[0019] The account balance 136 may represent the amount of funds currently available to the stored-value payment instrument 123. When the stored-value payment instrument 123 is used to make a purchase, the account balance 136 may decrease. Similarly, when the stored-value payment instrument 123 is replenished with additional funds, the account balance 136 may increase.

[0020] The issuer service 116 is executable to perform various functions, as discussed further herein. For example, the issuer service 116 is executable to create the stored-value payment instrument 123 in response to receipt of funds (e.g., when a gift card or prepaid debit card is purchased). The issuer service 116 is also executable to create an NFT 131 that can be used to uniquely identify the stored-value payment instrument 123 and associate the NFT 131 with the stored-value payment instrument 123. The issuer service 116 is also executable to verify ownership of the stored-value payment instrument 123 using the NFT 131 and to facilitate the eventual redemption of the stored-value payment instrument 123 for use in a future transaction.

[0021] Client device 106 represents a number of client devices that may be coupled to network 113. Client device 106 may include a processor-based system, such as a computer system. Such a computer system may be embodied in the form of a personal computer (e.g., a desktop computer, a laptop computer, or similar device), a mobile computing device (e.g., a personal digital assistant, a mobile phone, a smart phone, a web pad, a tablet computer system, a music player, a portable game console, an e-book reader, and similar devices), a media playback device (e.g., a media streaming device, a BluRay® player, a digital video disc (DVD) player, a set-top box, and similar devices), a video game console, or other device having similar functionality. Client device 106 may include one or more displays, such as a liquid crystal display (LCD), a gas plasma-based flat panel display, an organic light emitting diode (OLED) display, an electrophoretic ink ("E-ink") display, a projector, or other type of display device. In some cases, the display may be a component of the client device 106 or may be connectable to the client device 106 via a wired or wireless connection.

[0022] The client device 106 can be configured to run a variety of applications, such as a browser 139, a cryptocurrency wallet 141, or a digital wallet 142. The browser 139 can be used to interact with web pages provided by the issuer service 116, such as a web page that allows a user to purchase a stored value payment instrument 123. The cryptocurrency wallet 141 can be run to allow a user to manage their NFT owner public key 143, NFT owner private key 146, and any NFTs 131 currently owned by the user. The digital wallet 142 can be used to store transaction account information, such as payment information 126 for the stored value payment instrument 123, for use in payment transactions with merchants or other users. Examples of digital wallets 142 include APPLE PAY, GOOGLE PAY, SAMSUNG PAY, etc.

[0023] The NFT owner public key 143 represents a public key associated with the owner of the NFT 131. The NFT owner public key 143 can be used to uniquely identify the owner of the NFT 131. The NFT owner public key 143 can also be used to claim or verify ownership of the NFT 131 by the owner.

[0024] The NFT owner private keys 146 are the respective private keys for the NFT owner public keys 143. The NFT owner private keys 146 allow the owner of the NFT 131 to verify their ownership by generating a cryptographically secure signature that can be verified using the NFT owner public keys 143.

[0025] The distributed data store 109 represents a synchronized, eventually consistent data store that is spread across multiple nodes in different geographic or network locations. Each node in the distributed data store 109 may contain a replicated copy of the distributed data store 109, including all data stored in the distributed data store 109. Records of transactions involved in the distributed data store 109 may be shared or replicated using a peer-to-peer network that connects the individual nodes that form the distributed data store 109. After a transaction or record is recorded in the distributed data store 109, it may be replicated through the peer-to-peer network until the record is eventually recorded at all nodes. Various consensus methods may be used to ensure that data is reliably written to the distributed data store 109. In some implementations, data is immutable after it is written to the distributed data store 109. Examples of distributed ledgers may include various types of blockchains, distributed hash tables (DHTs), and similar data structures. The distributed data store 109 can store a variety of data, including one or more non-fungible tokens (NFTs) 131.

[0026] An NFT 131 represents a non-fungible unit of data stored in a distributed data store 109. Because an NFT 131 is non-fungible, it may be used for a variety of purposes where fungibility is not desirable. For example, an NFT 131 may be used to represent ownership of a non-fungible digital or physical item, such as an individual stored value payment instrument 123. Thus, in various implementations of the present disclosure, an NFT 131 may include an NFT identifier 129, an NFT owner public key 143, a redemption uniform resource locator (URL) 153, and / or a custom content URL 156. The NFT identifier 129 and the NFT owner public key 143 have been previously defined and described.

[0027] The redemption URL 153 may represent a URL or other address where the owner of the NFT 131 can redeem the stored-value payment 123 identified by the NFT 131. For example, the redemption URL 153 may represent the address of a website provided by the issuer service 116 where a user can activate, access, redeem, or otherwise obtain payment information 126 for the stored-value payment instrument 123.

[0028] Custom content URL 156 may represent a URL where one can find user-defined or user-specified content associated with NFT 131 or stored-value payment instrument 123. For example, if stored-value payment instrument 123 was purchased as a birthday gift, custom content URL 156 may represent where the recipient can find songs, photos, videos, notes, or other media for consumption.

[0029] 2A, a sequence diagram is shown illustrating one example of the operation of portions of network environment 100. The sequence diagram of FIG. 2A illustrates only one example of the many different types of functional configurations that may be employed to implement the operation of the illustrated portions of network environment 100. Alternatively, the flow chart of FIG. 2A may be viewed as illustrating one example of elements of a method implemented within network environment 100.

[0030] Beginning at block 201, a first user may make a purchase of a stored value payment instrument 123 using their client device 106a. For example, the first user may use a browser 139 on their client device 106a to go to a website provided by the issuer service 116 to purchase the stored value payment instrument 123. As part of the purchase process, the user may select an amount for a starting account balance 136 of the stored value payment instrument 123. As part of the purchase process, the user may also use their cryptocurrency wallet 141 on their client device 106a to provide their NFT owner public key 143 to the issuer service 116.

[0031] In some implementations, the first user may also provide custom or personalized content to the issuer service 116 at the time of purchase. For example, the first user may provide a custom content URL 156 that points to content or media (e.g., a video, an audio file, a photo, a web page, etc.) that may be included in the NFT 131. This may be done by the first user to personalize a gift (e.g., by presenting a custom content URL 156 to a recording of a family singing the song "Happy Birthday").

[0032] Alternatively, in some implementations, the first user may select or purchase custom content for inclusion in the NFT 131 during the purchase process. For example, the issuer service 116 may offer the first user the option to purchase a digital recording of a celebrity singing "Happy Birthday." As another example, the issuer service 116 may offer to purchase a limited edition or collectible digital artwork that the first user may purchase to have associated with the stored-value payment instrument 123.

[0033] In response to the purchase, the issuer service 116 may create or issue the stored-value payment instrument 123 in block 203. For example, the issuer service 116 may generate payment information 126 and save it as part of the record for the new stored-value payment instrument 123. The issuer service 123 may also set the account balance 136 to the value specified by the first user in block 201. Finally, the issuer service 123 may set the status 133 to an appropriate value (e.g., "not activated," "pending," etc.).

[0034] Further, the issuer service 116 may create the NFT 131 in block 206. The issuer service 116 may create the NFT 131 using a variety of techniques. For example, the distributed data store 109 may provide a function, interface, or other mechanism that the issuer service 116 may use to create the NFT 131. In some of these embodiments, the issuer service 116 may provide the redemption URL 153 and / or the custom content URL 156 as arguments or parameters of a function provided by the distributed data store 109. In other implementations, the issuer service 116 may update the NFT 131 after it is created to include the redemption URL 153 and / or the custom content URL 156.

[0035] Proceeding to block 209, the issuer service 116 may link the NFT 131 created in block 206 to the stored value payment instrument 123 purchased in block 201 and created in block 203. For example, the issuer service 116 may store the NFT identifier 129 of the NFT 131 created in block 206 as the NFT identifier 129 of the stored value payment instrument 123. As a result, the issuer service 116 may track ownership of the stored value payment instrument 123 based at least in part on the link between the NFT 131 and the stored value payment instrument 123.

[0036] Next, in block 211, the issuer service 116 can grant or transfer ownership of the NFT 131 to the first user. This can be done by updating the NFT owner public key 143 of the NFT 131 to match the first user's NFT owner public key 143. For example, as part of the purchase process in block 201, the first user may have provided their NFT owner public key 143 to the issuer service 116 using their cryptocurrency wallet 141 on their client device 106a. The issuer service 116 can then update the NFT 131 to include the NFT owner public key 143 received in block 201 as part of the purchase process in order to grant ownership of the NFT 131 to the first user.

[0037] Thereafter, in block 213, the first user may transfer ownership of the NFT 131 to the second user. For example, the first user may use the cryptocurrency wallet 141 on his / her client device 106a to update the NFT 131 to replace his / her NFT owner public key 143 with the second user's NFT owner public key 143. If the first user does not know or have the second user's NFT owner public key 143, the cryptocurrency wallet 141 may be implemented or configured to query the distributed data store 109, a key service, or an identity service or provider to obtain the second user's NFT owner public key 143.

[0038] At block 216, the second user may be notified of the transfer of the NFT 131. Although shown as occurring after the transfer, the notification may occur prior to the transfer at block 213 or simultaneously with the transfer of ownership at block 213. The notification may also occur by various mechanisms. In some implementations, the cryptocurrency wallet 141 running on the second user's client device 106b may detect the change in ownership of the NFT 131 and notify the second user that the second user is the new owner of the NFT 131. In other implementations, the first user may notify the second user directly using out-of-band communication (e.g., by emailing, calling, or otherwise informing the second user of the transfer). Other approaches for notifying the second user are encompassed by various embodiments of the present disclosure.

[0039] Then, in block 223, the second user can redeem the stored value payment instrument 123 linked to the NFT 131. For example, the second user can use his cryptocurrency wallet 141 running on his client device 106b to view the NFT 131 and obtain a redemption URL 153. The second user can then use a browser on his client device 106b to go to a redemption website presented by the issuer service 116 at the redemption URL 153. To redeem the stored value payment instrument 123, the second user can provide the NFT identifier 129 of the NFT 131 associated with the stored value payment instrument 123.

[0040] While going to the redemption website, the second user can prove his / her identity as the owner of the NFT 131. For example, the second user can use his / her cryptocurrency wallet 141 to sign a challenge provided by the redemption website with his / her NFT owner private key 146. The redemption website maintained by the issuer service 116 can then use the NFT owner public key 143 stored in the NFT 131 to verify the signature, thereby proving that the second user is the current owner of the NFT 131 associated with the stored-value payment instrument 123.

[0041] In response to the second user redeeming the stored-value payment instrument 123 at block 223, the issuer service 116 marks or otherwise renders the NFT 131 non-transferable. This may include invalidating or destroying the NFT 131. For example, if the NFT 131 is stored in the ETHEREUM blockchain network, the NFT owner public key 143 may be set equal to the value of an ETHEREUM dead address, thereby rendering the NFT 131 non-transferable. For other blockchain networks that offer burned token addresses, the issuer service 116 may set the value of the NFT owner public key 143 of the NFT 131 equal to the burned token address. This may be done as a fraud and security measure to protect the second user if the NFT 131 is stolen.

[0042] Proceeding to block 229, the issuer service 116 may provide the payment information 126 to the second user. For example, the issuer service 116 may search for a stored value payment instrument 123 having an NFT identifier 129 that matches the NFT identifier 129 of the NFT 131 submitted by the second user in block 223. The issuer service 116 may then encode the payment information 126 of the stored value payment instrument 123 in a web page that is sent to a browser 139 running on the second user's client device 106b. This causes the browser 139 to display the payment information 126 to the second user. Once displayed, the second user may save the payment information (e.g., in a digital wallet 142) for use in future transactions.

[0043] Referring now to Figure 3, a sequence diagram is shown illustrating one example of the operation of portions of network environment 100. The sequence diagram of Figure 3 illustrates only one example of the many different types of functional configurations that may be employed to implement the operation of the illustrated portions of network environment 100. Alternatively, the flow chart of Figure 3 may be viewed as illustrating example elements of a method that may be implemented within network environment 100.

[0044] Specifically, the sequence diagram of Figure 3 illustrates an alternative approach to that shown in Figure 2 for a first user to purchase a stored-value payment instrument 123 for a second user. For example, a first user may use the process described in the sequence diagram of Figure 3 to purchase a gift card as a gift for a friend, relative, or acquaintance. Thus, the process of Figure 3 differs from the process described in Figure 2, although some of the steps are performed in the same or similar manner as the steps described in Figure 2.

[0045] Starting at block 301, a first user may make a purchase of a stored-value payment instrument 123 using their client device 106a. For example, the first user may use a browser 139 on their client device 106a to go to a website provided by the issuer service 116 to purchase the stored-value payment instrument 123. As part of the purchase process, the user may select a starting account balance 136 amount for the stored-value payment instrument 123. As part of the purchase process, the user may also provide an NFT owner public key 143 of a second user as the intended recipient of the stored-value payment instrument 123.

[0046] In some implementations, the first user may also provide custom or personalized content to the issuer service 116 at the time of purchase. For example, the first user may provide a custom content URL 156 that points to content or media (e.g., a video, an audio file, a photo, a web page, etc.) that may be included in the NFT 131. This may be done by the first user to personalize a gift (e.g., by presenting a custom content URL 156 to a recording of a family singing the song "Happy Birthday").

[0047] Alternatively, in some implementations, the first user may select or purchase custom content for inclusion in the NFT 131 during the purchase process. For example, the issuer service 116 may offer the first user the option to purchase a digital recording of a celebrity singing "Happy Birthday." As another example, the issuer service 116 may offer to purchase a limited edition or collectible digital artwork that the first user may purchase to have associated with the stored-value payment instrument 123.

[0048] In response to the purchase, the issuer service 116 may create or issue the stored-value payment instrument 123 in block 303. For example, the issuer service 116 may generate payment information 126 and save it as part of the record for the new stored-value payment instrument 123. The issuer service 123 may also set the account balance 136 to the value specified by the first user in block 201. Finally, the issuer service 123 may set the status 133 to an appropriate value (e.g., "not activated," "pending," etc.).

[0049] Further, the issuer service 116 may create the NFT 131 at block 306. The issuer service 116 may create the NFT 131 using a variety of techniques. For example, the distributed data store 109 may provide functionality, interfaces, or other mechanisms that the issuer service 116 may use to create the NFT 131. In some such embodiments, the issuer service 116 may provide the redemption URL 153 and / or the custom content URL 156 as arguments or parameters of functionality provided by the distributed data store 109. In other implementations, the issuer service 116 may update the NFT 131 after it is created to include the redemption URL 153 and / or the custom content URL 156.

[0050] Proceeding to block 309, the issuer service 116 may link the NFT 131 created in block 306 to the stored value payment instrument 123 purchased in block 301 and created in block 303. For example, the issuer service 116 may store the NFT identifier 129 of the NFT 131 created in block 306 as the NFT identifier 129 of the stored value payment instrument 123. As a result, the issuer service 116 may track ownership of the stored value payment instrument 123 based at least in part on the link between the NFT 131 and the stored value payment instrument 123.

[0051] Next, in block 311, the issuer service 116 may grant or transfer ownership of the NFT 131 to the second user. This may be done by updating the NFT owner public key 143 of the NFT 131 to match the second user's NFT owner public key 143. As mentioned above, the second user's NFT owner public key 143 may have been previously provided by the first user's client device 106a in block 301.

[0052] At block 313, the second user may be notified of the creation of the NFT 131 associated with the stored-value payment instrument 123. Although illustrated as occurring after the granting at block 311, the notification may occur prior to the granting at block 311 or simultaneously with the granting at block 311. The notification may also be provided by various mechanisms. In some implementations, a cryptocurrency wallet 141 running on the second user's client device 106b may detect the change in ownership of the NFT 131 and notify the second user that the second user is the new owner of the NFT 131. In other implementations, the first user may notify the second user directly using out-of-band communication (e.g., by emailing, calling, or otherwise informing the second user of the transfer). If the first user provided the second user's contact information (e.g., an email address or mobile phone number) in block 301, the issuer service 116 may notify the second user directly (e.g., by sending an email or a Short Message Service (SMS) message to the second user). The message from the issuer service 116 may further include information such as the NFT identifier 129 and / or the redemption URL 153 to facilitate redemption of the stored-value payment instrument 123. Other techniques for notifying the second user are encompassed by various embodiments of the present disclosure.

[0053] Then, in block 316, the second user can redeem the stored value payment instrument 123 linked to the NFT 131. For example, the second user can use his cryptocurrency wallet 141 running on his client device 106b to view the NFT 131 and obtain the redemption URL 153. The second user can then use the browser on his client device 106b to go to the redemption website presented by the issuer service 116 at the redemption URL 153. Similarly, if the issuer service 116 sends the second user a notification including the redemption URL 153, the second user can directly access the redemption website using the browser 139 on his client device 106b. To redeem the stored value payment instrument 123, the second user can provide the NFT identifier 129 of the NFT 131 associated with the stored value payment instrument 123.

[0054] While going to the redemption website, the second user can prove his / her identity as the owner of the NFT 131. For example, the second user can use his / her cryptocurrency wallet 141 to sign a challenge provided by the redemption website with his / her NFT owner private key 146. The redemption website maintained by the issuer service 116 can then use the NFT owner public key 143 stored in the NFT 131 to verify the signature, thereby proving that the second user is the current owner of the NFT 131 associated with the stored-value payment instrument 123.

[0055] In response to the second user redeeming the stored-value payment instrument 123 at block 319, the issuer service 116 may mark or otherwise render the NFT 131 non-transferable. This may include invalidating or destroying the NFT 131. For example, if the NFT 131 was stored in the ETHEREUM blockchain network, the NFT owner public key 143 may be set equal to the value of an ETHEREUM dead address, rendering the NFT 131 non-transferable. For other blockchain networks that offer burned token addresses, the issuer service 116 may set the value of the NFT owner public key 143 of the NFT 131 equal to the burned token address. This may be done for fraud and security measures to protect the second user if the NFT 131 is stolen.

[0056] Proceeding to block 323, the issuer service 116 may provide the payment information 126 to the second user. For example, the issuer service 116 may search for a stored value payment instrument 123 having an NFT identifier 129 that matches the NFT identifier 129 of the NFT 131 submitted by the second user in block 316. The issuer service 116 may then encode the payment information 126 of the stored value payment instrument 123 in a web page that is sent to a browser 139 running on the second user's client device 106b. This causes the browser 139 to display the payment information 126 to the second user. Once displayed, the second user may save the payment information (e.g., in a digital wallet 142) for use in future transactions.

[0057] 4, a flow chart is shown illustrating one example of the operation of a portion of the issuer service 116 for redeeming a stored-value payment instrument 123 using an NFT 131. The flow chart of FIG. 4 illustrates only one example of many different types of functional configurations that may be employed to implement the operation of the illustrated portion of the issuer service 116. Alternatively, the flow chart of FIG. 4 may be viewed as illustrating example elements of a method implemented within the network environment 100.

[0058] Starting at block 403, the issuer service 116 may receive a redemption request sent from a client device 106 using the redemption URL 153 specified in the NFT 131. For example, a user of the client device 106 may use a browser 139 to access a website at the redemption URL 153 to access, activate, or otherwise redeem a stored-value payment instrument 123 associated with the NFT 131. As part of the redemption request, the user may include the NFT identifier 129 and / or the NFT owner public key 143 of the NFT 131 associated with the stored-value payment instrument 123.

[0059] Next, in block 406, the issuer service 116 can verify that the user submitting the redemption request is the owner of the NFT 131 based at least in part on the NFT owner public key 143. This process is further described in the flowchart of FIG.

[0060] Proceeding to block 409, the issuer service 116 may search for a stored-value payment instrument 123 in response to verifying that the user submitting the redemption request is the owner of the NFT 131. For example, the issuer service 116 may search for a stored-value payment instrument 123 having an NFT identifier 129 that matches the NFT identifier 129 provided in block 403.

[0061] Thereafter, in block 413, the payment information 126 for the stored-value payment instrument 123 may be provided to the client device 106 that made the redemption request in block 403. For example, the issuer service 116 may encode the payment information 126 for the stored-value payment instrument 123 in a web page that is sent to a browser 139 running on the user's client device 106.

[0062] 5, a flow chart is shown illustrating one example of a portion of the operation of the issuer service 116 to create an NFT 131 and link it to a stored-value payment instrument 123. The flow chart of FIG. 5 illustrates only one example of many different types of functional configurations that can be employed to implement the described portion of the operation of the issuer service 116. Alternatively, the flow chart of FIG. 5 can be viewed as illustrating example elements of a method implemented within the network environment 100.

[0063] Starting at block 503, the issuer service 116 may obtain a custom content URL 156. In some implementations, the custom content URL 156 may be provided by a user of a client device 106 when the user purchases a stored-value payment instrument 123, as described above in FIGs. 2 and 3. In other implementations, the custom content URL 156 may be provided by a third-party service in response to a purchase of an NFT 131 and custom content to associate with the stored-value payment instrument 123. The custom content URL 156 may also be generated by the issuer service 116 itself, such as when a user purchasing the stored-value payment instrument 116 also purchases or selects custom content presented as a selection by the issuer via the issuer service 116 as part of the process of purchasing the stored-value payment instrument 123.

[0064] Then, in block 506, the issuer service 116 may obtain ownership information reflecting the original owner of the stored-value payment instrument 123. As previously described in Figures 2 and 3, this may be either information of the purchase of the stored-value payment instrument 123 or information of the recipient of the stored-value payment instrument 123. This ownership information may include, for example, the NFT owner public key 143 of the owner of the stored-value payment instrument 123.

[0065] Next, in block 509, the issuer service 116 may create the NFT 131. Once created, the issuer service 116 may update the NFT 131 to include the NFT owner public key 143 obtained in block 506 and the custom content URL 156 obtained in block 503. The issuer service 116 may also insert a redemption URL 153 that allows the user to redeem or otherwise access the payment information 126 on the stored-value payment instrument 123.

[0066] Proceeding to block 513, the issuer service 116 may link the NFT 131 created in block 509 to the purchased stored-value payment instrument 123. For example, the issuer service 116 may store the NFT identifier 129 of the NFT 131 in a record of the stored-value payment instrument 123, thereby allowing the issuer service 116 to later look up and identify the stored-value payment instrument 123 in response to presenting the NFT 131.

[0067] 6, a flow chart is shown illustrating one example of the operation of a portion of the issuer service 116 to verify ownership of an NFT 131, and therefore the ownership of a stored-value payment instrument 123 linked to the NFT 131. The flow chart of FIG. 6 illustrates only one example of many different types of functional configurations that can be employed to implement the operations of the described portions of the issuer service 116. Alternatively, the flow chart of FIG. 6 can be viewed as illustrating one example of elements of a method implemented within the network environment 100.

[0068] Beginning at block 603, the issuer service 116 may send a challenge to the user's client device 106. The challenge may be any data, such as a randomly generated token (e.g., a randomly generated 32-bit, 64-bit, or 128-bit value, etc.). The randomly generated token may be used both to avoid disclosing any financial or payment information related to the stored-value payment instrument 123 and to prevent replay attacks that attempt to fraudulently reuse a signed token.

[0069] In response, in block 606, the issuer service 116 may receive a signed version of the challenge from the client device 106. For example, the client device 106 may sign the challenge with the NFT owner private key 146 of the respective NFT owner public key 143 associated with the NFT 131 in response to receiving the challenge. The signed challenge may then be provided by the client device 106 to the issuer service 116.

[0070] In block 609, the issuer service 116 may then use the NFT owner public key 143 to verify or verify the signature of the challenge received in block 606. If the issuer service 116 determines that the signature was generated by the NFT owner private key 146, the issuer service 116 may conclude that the owner or user of the client device 106 is the owner of the NFT 131. As a result, the issuer service 116 may also conclude that the owner or user of the client device 106 is the owner or authorized user of the stored value payment instrument 123.

[0071] 7, a flow chart is shown illustrating one example of a portion of the operation of the issuer service 116 to revoke, destroy, or otherwise render the NFT 131 non-transferable. The flow chart of FIG. 7 illustrates only one example of many different types of functional configurations that may be employed to implement the described portion of the operation of the issuer service 116. Alternatively, the flow chart of FIG. 7 may be viewed as illustrating example elements of a method implemented within the network environment 100.

[0072] Beginning at block 703, the issuer system 116 may determine whether a trigger event has occurred that requires the NFT 131 to be destroyed, invalidated, or otherwise rendered non-transferable. For example, the issuer system 116 may determine that the stored-value payment instrument 123 associated with the NFT 131 has been redeemed by a user. As another example, the issuer system 116 may determine that the stored-value payment instrument 123 has expired. In response, the issuer system 116 may determine that the stored-value payment instrument 123 is no longer usable or transferable.

[0073] In response, at block 706, the issuer system 116 may destroy, revoke, or otherwise render the NFT 131 non-transferable. This may be done using a variety of mechanisms. In some implementations, the NFT 131 may be hosted on a blockchain network that provides a burned token address, such as the ETHEREUM blockchain network. Any tokens identified as owned by the burned token address are destroyed and deemed unable to be further transferred. In other implementations, the NFT 131 may provide an irreversible bit that indicates whether the NFT 131 is allowed to be transferred. Once the irreversible bit is set to indicate that the NFT 131 is no longer transferable, any further attempts to transfer the NFT 131 to other users of the distributed data store 109 will fail. The irreversible bit in these implementations is considered irreversible because once the value of the bit is changed to indicate that the NFT 131 is no longer transferable, the value of the bit cannot be changed back.

[0074] In addition to rendering the NFT 131 non-transferable, the issuer system 116 may additionally or alternatively sever the association between the NFT 131 and the stored-value payment instrument 123. For example, the issuer system 116 may remove the NFT identifier 129 from the record of the stored-value payment instrument 123 stored in the issuer data store 119. As a result, the issuer service 116 will not recognize the NFT 131 as indicating ownership or control of the stored-value payment instrument 123, even if the NFT 131 is later transferred to another party.

[0075] The several software components mentioned above are stored in the memory of the respective computing device and are executable by the processor of the respective computing device. In this respect, the term "executable" refers to a program file in a format that can ultimately be executed by the processor. An example of an executable program can be machine code in a format that can be loaded into a random access portion of memory and executed by the processor, source code that can be expressed in a suitable format such as object code that can be loaded into a random access portion of memory and executed by the processor, or a compiled program that can be converted into source code that can be interpreted by another executable program to generate instructions in the random access portion of memory that are executed by the processor. An executable program can be stored in any portion or component of memory, including random access memory (RAM), read-only memory (ROM), hard drive, solid state drive, universal serial bus (USB) flash drive, memory card, optical disk such as a compact disk (CD) or digital versatile disk (DVD), floppy disk, magnetic tape, or other memory component.

[0076] Memory includes both volatile and non-volatile memory and data storage components. A volatile component is a component that does not retain a data value when power is lost. A non-volatile component is a component that retains data when power is lost. Thus, memory may include random access memory (RAM), read-only memory (ROM), a hard disk drive, a solid state drive, a USB flash drive, a memory card accessed through a memory card reader, a floppy disk accessed through an associated floppy disk drive, an optical disk accessed through an optical disk drive, a magnetic tape accessed through a suitable tape drive, or other memory components, or a combination of any two or more of these memory components. Additionally, RAM may include devices such as static random access memory (SRAM), dynamic random access memory (DRAM), or magnetic random access memory (MRAM). ROM may include programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or other similar memory devices.

[0077] The applications and systems described herein may be embodied in software or code executed by the general purpose hardware described above, but alternatively, the same may be embodied in dedicated hardware or a combination of software / general purpose hardware and dedicated hardware. When embodied in dedicated hardware, each may be implemented as a circuit or state machine employing any one or combination of several technologies. These technologies may include, but are not limited to, discrete logic circuits having logic gates for implementing various logic functions upon application of one or more data signals, application specific integrated circuits (ASICs) having appropriate logic gates, field programmable gate arrays (FPGAs), or other components, etc. Such technologies are generally well known to those skilled in the art and therefore will not be described in detail herein.

[0078] The flow charts and sequence diagrams illustrate the functions and operations of some implementations of various embodiments of the present disclosure. When embodied in software, each block may represent a module, segment, or portion of code that includes program instructions for implementing the specified logical functions. The program instructions may be embodied in the form of source code, including human-readable statements written in a programming language, or machine code, including numerical instructions recognizable by a suitable execution system, such as a processor of a computer system. The machine code may be transformed from the source code through various processes. For example, the machine code may be generated from the source code using a compiler before executing the corresponding application. As another example, the machine code may be generated from the source code upon execution by an interpreter. Other approaches may also be used. When embodied in hardware, each block may represent a circuit or several interconnected circuits for implementing one or more specified logical functions.

[0079] Although the flowcharts and sequence diagrams show a particular order of execution, it is understood that the order of execution may differ from that shown. For example, the order of execution of two or more blocks may be scrambled relative to the order shown. Also, two or more blocks shown in succession may be executed in parallel or with partial parallelism. Furthermore, in some embodiments, one or more of the blocks shown in the flowcharts and sequence diagrams may be skipped or omitted. Furthermore, any number of counters, state variables, alert semaphores, or messages may be added to the logical flows described herein for purposes such as to enhance utility, accounting, performance measurement, or to provide troubleshooting assistance. All such variations are understood to be within the scope of this disclosure.

[0080] Also, any logic or application described herein, including software or code, can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system, such as a processor of a computer system or other system. In this sense, logic can include statements, including instructions and declarations, that can be fetched from a computer-readable medium and executed by an instruction execution system. In the context of this disclosure, a "computer-readable medium" can be any medium that can contain, store, or maintain the logic or application described herein for use by or in connection with an instruction execution system. Also, a collection of distributed computer-readable media located across multiple computing devices (e.g., a storage area network or a distributed or clustered file system or database) can be collectively considered to be a single non-transitory computer-readable medium.

[0081] The computer-readable medium may include any one of many physical media, such as magnetic, optical, or semiconductor media. More specific examples of suitable computer-readable media include, but are not limited to, magnetic tape, magnetic floppy diskette, magnetic hard drive, memory card, solid state drive, USB flash drive, or optical disk. The computer-readable medium may also be random access memory (RAM), including static random access memory (SRAM) and dynamic random access memory (DRAM), or magnetic random access memory (MRAM). The computer-readable medium may also be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or other types of memory devices.

[0082] Additionally, any logic or application described herein may be implemented and structured in a variety of ways. For example, one or more applications described herein may be implemented as modules or components of a single application. Additionally, one or more applications described herein may execute on a shared or separate computing device or a combination thereof. For example, multiple applications described herein may execute on the same computing device or on multiple computing devices within the same computing environment.

[0083] Unless otherwise expressly indicated, disjunctive language, such as the phrase "at least one of X, Y, or Z," is otherwise understood in the context in which it is commonly used to express that an item, term, etc. can be either X, Y, or Z, or any combination thereof (e.g., X; Y; Z; X or Y; X or Z; Y or Z; X, Y, or Z, etc.). Thus, such disjunctive language is generally not intended to, and should not, imply that a particular embodiment requires at least one of X, at least one of Y, or at least one of Z, each being present.

[0084] Exemplary embodiments of the present disclosure are described, by way of example, in the following sections, which set forth examples of various embodiments of the present disclosure, although the claims of other embodiments may also be supported by the various embodiments of the present disclosure.

[0085] Item 1 - A system including a computing device including a processor and a memory, and machine-readable instructions stored in the memory, which, when executed by the processor, cause the computing device to at least receive a purchase notification indicating a first user has purchased a stored-value payment instrument, and in response to receiving the purchase notification, create a non-fungible token (NFT) on a distributed data store, associate a unique identifier of the NFT with the stored-value payment instrument, receive a public key associated with the first user, and update an owner identifier of the NFT with the public key associated with the first user.

[0086] 2 - The system of claim 1, wherein the machine-readable instructions further cause the computing device to add at least a redemption uniform resource locator (URL) that identifies a website where the NFT can be redeemed for a stored value payment instrument.

[0087] 3 - The system of claim 2, wherein the machine-readable instructions further cause the computing device to at least receive a redemption request from the second user via the website identified by the redemption URL, verify that the second user is authorized to redeem the stored-value payment instrument associated with the NFT, and in response to verifying that the second user is authorized to redeem the stored-value payment instrument associated with the NFT, provide account information for the stored-value payment instrument to the second user.

[0088] 4 - The system of claim 3, wherein the machine-readable instructions further cause the computing device to at least invalidate the NFT in response to account information for the stored value payment instrument being provided to the second user.

[0089] 5 - The system of claim 4, wherein the machine-readable instructions that cause the computing device to invalidate the NFT further cause the computing device to update at least an owner identifier of the NFT with the burned token address.

[0090] Clause 6 - The system of clause 4 or clause 5, wherein the machine-readable instructions that cause the computing device to invalidate the NFT further cause the computing device to at least disassociate the unique identifier of the NFT and the stored value payment instrument.

[0091] Clause 7 - The system of any one of clauses 1 to 7, wherein the machine-readable instructions further cause the computing device to at least receive from the first user a custom content uniform resource locator (URL) representing an address where the user-selected content is located, and add the custom content URL to the NFT.

[0092] Item 8 - A method including receiving a purchase notification indicating a first user has purchased a stored-value payment instrument; and in response to receiving the purchase notification, creating a non-fungible token (NFT) on a distributed data store, associating a unique identifier of the NFT with the stored-value payment instrument, receiving a first public key associated with the first user, and updating an owner identifier of the NFT with the first public key associated with the first user.

[0093] Item 9 - The method of item 8, further comprising adding a redemption uniform resource locator (URL) that identifies a website where the NFT can be redeemed for a stored value payment instrument.

[0094] Clause 10 - The method of clause 9, further comprising receiving a redemption request from the second user via a website identified by the redemption URL, verifying that the second user is authorized to redeem the stored-value payment instrument associated with the NFT, and providing stored-value payment instrument account information to the second user in response to verifying that the second user is authorized to redeem the stored-value payment instrument associated with the NFT.

[0095] Item 11 - The method of item 10, further comprising invalidating the NFT in response to the stored value payment instrument account information being provided to the second user.

[0096] Clause 12 - The method of clause 11, wherein invalidating the NFT further includes updating an owner identifier of the NFT with the burned token address.

[0097] Clause 13 - The method of any one of clauses 8 to 12, wherein invalidating the NFT further comprises disassociating the unique identifier of the NFT from the stored value payment instrument.

[0098] Clause 14 - The method of any one of clauses 8 to 13, further comprising receiving a custom content uniform resource locator (URL) from the first user, the custom content URL representing an address at which the user-selected content is located, and adding the custom content URL to the NFT.

[0099] Clause 15 - A non-transitory computer-readable medium containing machine-readable instructions that, when executed by a processor of a computing device, cause the computing device to at least receive a purchase notification indicating a first user has purchased a stored-value payment instrument; in response to receiving the purchase notification, create a non-fungible token (NFT) on a distributed data store, associate a unique identifier of the NFT with the stored-value payment instrument, receive a first public key associated with the first user, and update an owner identifier of the NFT with the first public key associated with the first user.

[0100] Item 16 - The non-transitory computer-readable medium of item 15, further comprising machine-readable instructions that cause the computing device to append at least a redemption uniform resource locator (URL) that identifies a website where the NFT can be redeemed for a stored value payment instrument.

[0101] Clause 17 - The transient computer readable medium of clause 16, further comprising machine readable instructions that cause the computing device to at least receive a redemption request from the second user via the website identified by the redemption URL, verify that the second user is authorized to redeem the stored value payment instrument associated with the NFT, and in response to verifying that the second user is authorized to redeem the stored value payment instrument associated with the NFT, provide the second user with account information for the stored value payment instrument.

[0102] Item 18 - The non-transitory computer-readable medium of item 17, further comprising machine-readable instructions that cause the computing device to at least invalidate the NFT in response to account information for the stored value payment instrument being provided to a second user.

[0103] Clause 19 - The non-transitory computer-readable medium of clause 18, wherein the machine-readable instructions that cause the computing device to invalidate the NFT further cause the computing device to update at least an owner identifier of the NFT with the burned token address.

[0104] Clause 20 - A non-transitory computer-readable medium as described in clause 18 or clause 19, wherein the machine-readable instructions that cause the computing device to invalidate the NFT further cause the computing device to at least disassociate the unique identifier of the NFT and the stored value payment instrument.

[0105] It should be emphasized that the above-described embodiments of the present disclosure are merely possible examples of implementations described to clearly understand the principles of the present disclosure. Many variations and modifications can be made to the above-described embodiments without substantially departing from the spirit and principles of the present disclosure. All such variations and modifications are intended to be included herein within the scope of the present disclosure and protected by the following claims.

Claims

1. a computing device including a processor and a memory; and machine-readable instructions stored in the memory, the machine-readable instructions, when executed by the processor, causing the computing device to perform at least: receiving a purchase notification indicating that a first user has purchased a stored-value payment instrument; creating a non-fungible token (NFT) having a unique identifier on a distributed data store by providing a redemption uniform resource locator (URL) identifying a website for redemption of the stored-value payment instrument to a function associated with the distributed data store in response to receiving the purchase notification, the function being configured to generate the NFT to include the redemption URL; associating the unique identifier of the NFT with the stored-value payment instrument; receiving a first public key associated with the first user; updating an owner identifier of the NFT with the first public key associated with the first user; transferring ownership of the NFT associated with the stored-value payment instrument to a second user by updating the owner identifier of the NFT with a second public key associated with a second user based at least in part on a request from a first client device of the first user; receiving the unique identifier of the NFT from a second client device of the second user for redemption of the stored-value payment instrument, the unique identifier being received by the website associated with the redemption URL; rendering the NFT non-transferable based at least in part on the second client device of the second user redeeming the stored-value payment instrument; and after rendering the NFT non-transferable, encoding payment information for the stored-value payment instrument in a web page that is provided to the second client device.

2. The machine-readable instructions further include instructions for causing the computing device to: identifying the second client device of the second user accessing the website associated with the redemption URL; receiving a redemption request from the second user via the website identified by the redemption URL, the redemption request including a signature generated by the second client device; 2. The system of claim 1, further comprising: verifying that the second user is authorized to redeem the stored-value payment instrument associated with the NFT, where verifying the second user includes verifying the signature using the second public key.

3. The system of claim 2, wherein making the NFT non-transferable further causes the computing device to update the owner identifier of the NFT to a non-transferable NFT value.

4. The system of claim 3, wherein the non-transferable NFT value is at least one of a burned token address or a dead address for the NFT's blockchain network.

5. 4. The system of claim 3, wherein the machine-readable instructions that cause the computing device to render the NFT non-transferable further cause the computing device to at least disassociate the unique identifier of the NFT and the stored-value payment instrument.

6. The machine-readable instructions further include at least one instruction for transmitting to the computing device: receiving a custom content Uniform Resource Locator (URL) from the first user that represents an address at which user-selected content resides; and adding the custom content URL to the NFT.

7. Receiving a purchase notification indicating that a first user has purchased a stored-value payment instrument; creating a non-fungible token (NFT) having a unique identifier on a distributed data store by providing a redemption uniform resource locator (URL) identifying a website for redemption of the stored-value payment instrument to a function associated with the distributed data store in response to receiving the purchase notification, the function being configured to generate the NFT to include the redemption URL; associating the unique identifier of the NFT with the stored-value payment instrument; receiving a first public key associated with the first user; updating an owner identifier of the NFT with the first public key associated with the first user; transferring the NFT to the second user by updating the owner identifier of the NFT with a second public key associated with a second user based at least in part on a request from a first client device of the first user; receiving the unique identifier of the NFT from a second client device of the second user for redemption of the stored-value payment instrument; rendering the NFT non-transferable based at least in part on receiving the unique identifier from the second client device for redemption of the stored-value payment instrument; and after rendering the NFT non-transferable, encoding payment information for the stored-value payment instrument in a web page provided to the second client device.

8. A method for identifying a second client device of a second user accessing the website associated with the redemption URL; receiving a redemption request from the second user via the website identified by the redemption URL; 8. The method of claim 7, further comprising verifying that the second user is authorized to redeem the stored-value payment instrument associated with the NFT.

9. The method of claim 8 , wherein rendering the NFT non-transferable further comprises updating the owner identifier of the NFT to a non-transferable NFT value.

10. The method of claim 9, wherein the non-transferable NFT value is at least one of a burned token address or a dead address for the NFT's blockchain network.

11. The method of claim 9, wherein rendering the NFT non-transferable further comprises disassociating the unique identifier of the NFT from the stored-value payment instrument.

12. A method for providing a content server comprising: receiving, from the first user, a custom content uniform resource locator (URL) representing an address at which user-selected content can be found; and The method of claim 7 , further comprising: adding the custom content URL to the NFT.

13. A non-transitory computer-readable medium comprising machine-readable instructions that, when executed by a processor of a computing device, cause the computing device to perform at least: receiving a purchase notification indicating that a first user has purchased a stored-value payment instrument; creating a non-fungible token (NFT) on a distributed data store in response to receiving the purchase notification by providing a redemption uniform resource locator (URL) identifying a website for redemption of the stored-value payment instrument to a function associated with the distributed data store, the function being configured to generate the NFT to include the redemption URL; associating a unique identifier of the NFT with the stored-value payment instrument; receiving a first public key associated with the first user; updating an owner identifier of the NFT with the first public key associated with the first user; transferring the NFT to the second user by updating the owner identifier of the NFT with a second public key associated with a second user based at least in part on a request from a first client device of the first user; rendering the NFT non-transferable based at least in part on a second client device of the second user accessing the website associated with the redemption URL; and after rendering the NFT non-transferable, encoding payment information for the stored-value payment instrument in a web page that is provided to the second client device.

14. The machine-readable instructions further comprising: identifying the second client device of the second user accessing the website associated with the redemption URL; receiving a redemption request from the second user via the website identified by the redemption URL; and verifying that the second user is authorized to redeem the stored-value payment instrument associated with the NFT.

15. The non-transitory computer-readable medium of claim 14, wherein making the NFT non-transferable further causes the computing device to update the owner identifier of the NFT to a non-transferable NFT value.

16. The non-transitory computer-readable medium of claim 15, wherein the non-transferable NFT value is a burned token address or a dead address for the NFT's blockchain network.

17. The non-transitory computer-readable medium of claim 15, wherein the machine-readable instructions that cause the computing device to render the NFT non-transferable further cause the computing device to at least disassociate the unique identifier of the NFT and the stored-value payment instrument.

18. The method of claim 17, further comprising: transferring the ownership of the NFT associated with the stored-value payment instrument to the computing device. receiving the second public key associated with the second user from a cryptocurrency wallet of the first user; and sending a notification of the transfer of the NFT to the second client device based at least in part on the updating of the owner identifier of the NFT with the second public key associated with the second user.

19. Transferring the stored-value payment instrument comprises: receiving the second public key associated with the second user from a cryptocurrency wallet of the first user; 10. The method of claim 8, further comprising: sending a notification of the transfer of the NFT to the second client device based at least in part on updating the owner identifier of the NFT with the second public key associated with the second user.

Images