Techniques for managing transaction tokens to facilitate reconciliation processes

Abstract

According to some implementation schemes, techniques for managing transaction tokens to facilitate reconciliation processes are disclosed. One technique can be executed by a transaction framework implemented on a computing device and includes the following steps: (1) receiving a first request to execute a transaction from a software application executing on the computing device; (2) providing a second request to a management entity to generate a transaction token for the transaction; (3) receiving the transaction token from the management entity; (4) displaying a user interface (UI) indicating that the transaction will be executed independently of the management entity; (5) receiving selections of options for approving the transaction via the UI; and (6) providing the transaction token to the software application or a developer entity associated with the software application, such that, when the transaction is executed, the transaction token enables the execution of the reconciliation process.

Description

Technical Field

[0001] The described implementation scheme relates overall to technologies for tracking transactions. More specifically, the described implementation scheme provides technologies for managing transaction tokens that enable reconciliation processes. Background Technology

[0002] In recent years, there has been a surge in software applications designed to run on computing devices such as desktop computers, laptops, tablets, mobile phones, and wearable devices. This increase is primarily attributed to computing devices running operating systems, which enable the development of “third-party applications” for these devices and their installation on them (alongside various “native” applications typically provided with the operating system). This approach offers numerous benefits, notably enabling a vast number of developers worldwide to exercise their creativity through the powerful application programming interfaces (APIs) available via the aforementioned operating systems.

[0003] Different methods can be used to enable users to install third-party software applications on their computing devices. For example, one method involves an environment that is largely unrestricted, allowing developers to write software applications that virtually access every corner of the operating system / computing device where they will ultimately be installed. Under this method, users are typically also able to freely download and install software applications from any developer and / or distributor. On the one hand, this method provides developers and users with a considerable level of flexibility, as they can participate in a largely unrestricted operating environment and transaction (e.g., payment) environment. However, this method has security flaws because faulty, malicious, and other malicious software applications are prevalent and are often installed by unsuspecting users.

[0004] To mitigate the aforementioned drawbacks, an alternative approach involves implementing a more restricted environment compared to the unrestricted environment described above. Specifically, this restricted environment typically involves a software application store implemented by an entity that is (usually) also associated with the operating system and / or computing device on which the software application will ultimately be installed. In this approach, developers need to register with the software application store as a first line of review. Subsequently, developers submit their proposed software application to the software application store for analysis regarding its compliance with various operational requirements, constituting a second line of review. Finally, when the software application is approved for distribution through the software application store, users are allowed to download the software application to their computing devices. Users are also allowed to perform software application-related transactions through the software application store, such as purchases and subscriptions. Therefore, this approach offers the following benefits: significantly enhanced security compared to the unrestricted environment described above, and a streamlined billing process that customers trust and are familiar with.

[0005] Regardless of the method or environment used, maintaining a comprehensive representation of transactions occurring in relation to a software application can be beneficial to customers, developers, and others. Therefore, what is needed are technologies that enable the formation and maintenance of a comprehensive representation of transactions, especially when transaction flows resemble the unrestricted environments described above. Summary of the Invention

[0006] The described implementation scheme relates overall to technologies for tracking transactions. More specifically, the described implementation scheme provides technologies for managing transaction tokens that enable reconciliation processes.

[0007] One implementation describes a method for managing transaction tokens to facilitate a reconciliation process. According to some implementations, the method may be implemented by a transaction framework on a computing device and includes the following steps: (1) receiving a first request to execute a transaction from a software application running on the computing device; (2) providing a second request to a management entity to generate a transaction token for the transaction; (3) receiving the transaction token from the management entity; (4) displaying a user interface (UI) indicating that the transaction will be executed independently of the management entity, wherein the UI includes a first option for approving the transaction and a second option for canceling the transaction; (5) receiving a selection of the first option for approving the transaction via the UI; and (6) providing the transaction token to the software application or a developer entity associated with the software application, such that, when the transaction is executed, the transaction token enables the execution of the reconciliation process.

[0008] Another implementation describes an alternative method for managing transaction tokens to facilitate the reconciliation process. According to some implementations, the method can be implemented by a management entity and includes the following steps: (1) receiving a request from a transaction framework implemented on a computing device to generate a transaction token for a transaction that will be executed at least in part by a software application running on the computing device; (2) verifying the software application and the developer entity associated with the software application; (3) generating the transaction token; (4) providing the transaction token to the transaction framework; (5) receiving (1) the transaction token and (2) the transaction result associated with the transaction; and (6) performing the reconciliation process based on the transaction token and the transaction result.

[0009] Another implementation describes an alternative method for managing transaction tokens to facilitate the reconciliation process. According to some implementations, the method can be implemented by a software application running on a computing device and includes the following steps: (1) receiving a first request to execute a transaction; (2) providing a second request to execute the transaction to a transaction framework implemented on the computing device; (3) displaying a user interface (UI) under the instructions of the transaction framework, the UI indicating that the transaction will be executed independently of a management entity associated with the computing device, wherein the UI includes a first option for approving the transaction and a second option for canceling the transaction; (4) receiving a transaction token from the transaction framework, wherein: the transaction token is provided in conjunction with the selection of the first option for approving the transaction received via the UI, and the transaction token corresponds to the transaction; and (5) providing the transaction token to a developer entity associated with the software application to enable the developer entity to execute the transaction, wherein when the transaction is executed, the transaction token enables the execution of the reconciliation process.

[0010] Another implementation describes an alternative method for managing transaction tokens to facilitate the reconciliation process. According to some implementations, the method can be implemented by a software application running on a computing device and includes the following steps: (1) receiving a first request to execute a transaction; (2) providing a second request to execute the transaction to a transaction framework implemented on the computing device; (3) displaying a user interface (UI) under the instructions of the transaction framework, the UI indicating that the transaction will be executed independently of a management entity associated with the computing device, wherein the UI includes a first option for approving the transaction and a second option for canceling the transaction; (4) receiving a selection for the first option for approving the transaction, wherein the transaction framework provides a transaction token to a developer entity, and the transaction token corresponds to the transaction; (5) loading a web browser application under the instructions of the transaction framework; (6) causing the web browser application to load a website corresponding to the developer entity associated with the software application; and (7) causing the developer entity to execute the transaction via the web browser application, wherein when the transaction is executed, the transaction token enables the execution of the reconciliation process.

[0011] Other embodiments include a non-transitory computer-readable storage medium configured to store instructions that, when executed by a processor included in a computing device, cause the computing device to implement the methods and techniques described in this disclosure. Still other embodiments include a hardware computing device including a processor configured to cause the hardware computing device to implement the methods and techniques described in this disclosure.

[0012] Other aspects and advantages of the technology will become apparent from the following detailed description, which is based on the accompanying drawings illustrating the principles of the described embodiments by way of example.

[0013] The content of this invention is provided merely to outline some exemplary embodiments in order to provide a basic understanding of some aspects of the subject matter described herein. Therefore, it should be understood that the features described above are merely illustrative and should not be construed as narrowing the scope or substance of the subject matter described herein in any way. Other features, aspects, and advantages of the subject matter described herein will become apparent from the following detailed description, drawings, and claims. Attached Figure Description

[0014] The accompanying drawings are for illustrative purposes and are intended only to provide examples of possible structures and arrangements of the disclosed apparatus and methods for providing wireless computing devices. These drawings are in no way intended to limit any changes in form and detail that may be made to the embodiments by those skilled in the art without departing from the spirit and scope of the embodiments. The embodiments will be readily understood from the following detailed description taken in conjunction with the accompanying drawings, wherein like reference numerals denote like structural elements.

[0015] Figure 1 Block diagrams illustrating different components of a system configured to implement the various technologies described herein, according to some implementation schemes.

[0016] Figures 2A to 2B A sequence diagram illustrating example technologies for managing transaction tokens according to some implementation schemes, which enable the execution of reconciliation processes.

[0017] Figure 2C A sequence diagram illustrating the techniques used to perform the reconciliation process according to some implementation schemes is shown.

[0018] Figure 3 A conceptual diagram illustrating an example user interface that may be displayed when an in-app transaction is executed on a computing device, according to some implementation schemes of a software application.

[0019] Figures 4A to 4B A conceptual diagram illustrating a sample user interface that may be displayed when an outlink transaction is executed on a computing device, according to some implementation schemes.

[0020] Figure 5 Methods for managing transaction tokens to facilitate reconciliation processes, according to some implementation schemes, are illustrated. Specifically, the method involves steps that can be performed by a transaction framework implemented on a computing device.

[0021] Figure 6 Examples of methods for managing transaction tokens to facilitate the reconciliation process, according to some implementation schemes, are illustrated. Specifically, the method involves steps that can be performed by a management entity.

[0022] Figure 7 Examples of methods for managing transaction tokens to facilitate reconciliation processes, according to some implementation schemes, are illustrated. Specifically, the method involves steps for executing in-app transactions, which can be performed by a software application running on a computing device.

[0023] Figure 8 Examples of methods for managing transaction tokens to facilitate reconciliation processes, according to some implementation schemes, are illustrated. Specifically, the method involves steps for executing external link transactions, which can be performed by software applications and web browser applications running on computing devices.

[0024] Figure 9 Detailed views of computing devices that can be used to implement the various technologies described herein, according to some implementation schemes, are illustrated. Detailed Implementation

[0025] Representative applications of the apparatus and methods according to the embodiments currently described are provided in this section. These examples are provided only to add context and aid in understanding the described embodiments. It will therefore be apparent to those skilled in the art that the embodiments currently described can be practiced without some or all of these specific details. In other instances, well-known process steps have not been described in detail to avoid unnecessarily obscuring the embodiments currently described. Other applications are possible, such that the following examples should not be considered limiting.

[0026] In the following detailed description, reference is made to the accompanying drawings, which form part of this specification, and specific embodiments according to the described embodiments are illustrated by way of example in the drawings. While these embodiments are described in sufficient detail to enable those skilled in the art to practice the described embodiments, it should be understood that these examples are not limiting; other embodiments are permitted for use, and modifications may be made without departing from the spirit and scope of the described embodiments.

[0027] The described implementation scheme relates overall to technologies for tracking transactions. More specifically, the described implementation scheme provides technologies for managing transaction tokens that enable reconciliation processes.

[0028] These and other implementation schemes are referenced below. Figures 1 to 9 Discussions have been conducted; however, those skilled in the art will readily understand that the detailed descriptions given herein with respect to the accompanying drawings are for illustrative purposes only and should not be construed as restrictive.

[0029] Figure 1 Block diagrams are shown of different components of a system 100 that can implement the various technologies described herein, according to some implementation schemes. For example... Figure 1 As shown, system 100 may include one or more computing devices 102, one or more developer entities 110, one or more payment processing entities 116, and management entities 118.

[0030] like Figure 1 As shown, multiple software applications 108 may be installed on a given computing device 102, and the computing device 102 may implement a user account framework 104 and a transaction framework 106. According to some embodiments, the user account framework 104 may represent an application programming interface (API) that enables one or more user accounts to be associated with the computing device 102 (e.g., to log in to the computing device). For example, when a user of the given computing device 102 enters credentials for their user account (e.g., a unique username and password) into the computing device 102, the user account framework 104 may provide the credentials to a user account manager 120 (which is implemented on a management entity 118 and described in more detail below).

[0031] When User Account Manager 120 receives credentials, it can refer to user accounts known to it (i.e., those registered with it) to determine if the credentials are valid. User Account Manager 120 can then indicate the validity of the credentials to User Account Framework 104. When the credentials are valid, User Account Framework 104 can store the credentials and use them to access services provided by Management Entity 118. When the credentials are invalid, the user can proceed until valid credentials are provided. In any case, when User Account Framework 104 stores valid credentials, it can periodically interface with User Account Manager 120 to determine whether access to the aforementioned services should remain intact. For example, User Account Framework 104 / User Account Manager 120 can periodically request authentication to ensure that the user account is actively "logged in" to computing device 102.

[0032] As described above, computing device 102 can be configured to implement transaction framework 106, which can also represent an API. According to some implementations, transaction framework 106 can be accessed by software application 108 to enable various functionalities. Specifically, when software application 108 is ready to participate in a transaction with a user of software application 108 / computing device 102, a given software application 108 can interface with transaction framework 106. Transaction framework 106 can then interface with reconciliation manager 122 (which is implemented on management entity 118 and described in more detail below) and request reconciliation manager 122 to generate / provide a transaction-specific transaction token 124. Transaction framework 106 can then store the transaction token 124 received from reconciliation manager 122. Subsequently, in conjunction with transaction execution, transaction token 124 can be provided to software application 108, developer website 114 associated with developer entity 110, and developer transaction manager 112 associated with developer entity 110. Figure 1 Other entities not illustrated herein, or some combination thereof. The transaction token 124 can then be used by at least one of the aforementioned entities to perform the reconciliation process described herein.

[0033] According to some implementation plans, such as Figure 1 As shown, a given developer entity 110 may collectively represent one or more parties involved in the development, management, and release of software application 108. For example, developer entity 110 may collectively represent a company, an individual developer, etc., and one or more computing devices utilized by such parties. As described herein, developer entity 110 may implement developer transaction manager 112, and optionally, developer website 114. According to some implementations, developer transaction manager 112 may be configured to facilitate transactions of software application 108 associated with developer entity 110. Specifically, developer transaction manager 112 may receive transaction token 124, request execution of a transaction corresponding to transaction token 124, and then interface with payment processing entity 116 to facilitate the transaction.

[0034] According to several implementation schemes, different methods can be used to enable transaction processing based on a given transaction token 124 / corresponding transaction request. Specifically, a first method (referred to herein as "in-app" purchase) involves software application 108 (itself) receiving transaction token 124 from transaction framework 106 and then providing transaction token 124 / corresponding transaction request to developer transaction manager 112 for processing (e.g., using payment processing entity 116). A second method (referred herein as "external link" purchase) involves software application 108 / transaction framework 106 causing a web browser application to load developer website 114 (e.g., a payment webpage), and then providing the transaction request to developer website 114 for processing. The second method also involves developer website 114 receiving transaction token 124 from transaction framework 106. Subsequently, developer website 114 and developer transaction manager 112 can process the transaction (e.g., using payment processing entity 116). It should be noted that the foregoing examples are not intended to be limiting, and the methods described herein can include the transfer of any amount, type, form, etc., of information at any granularity between entities of any quantity, type, form, etc., to process transactions, consistent with the scope of this disclosure. In any case, at the end of a transaction, the developer transaction manager 112 can update the transaction token 124 to reflect whether the transaction was successful or failed, etc., and can provide the transaction result to the software application 108 (and, in the case of an external link purchase scenario, to the web browser application).

[0035] Additionally, the developer transaction manager 112 can be configured to interface with the reconciliation manager 122 to perform the reconciliation process. The developer transaction manager 112 may interface with the reconciliation manager 122 when conditions of any quantity, type, form, etc., occur, such as periodically, when a threshold number of transactions are successfully processed, etc. In any case, the developer transaction manager 112 may provide the reconciliation manager 122 with a transaction token 124 for successfully processed transactions. Then, and as described in more detail herein, the reconciliation manager 122 may interface with the payment processing entity 116 to facilitate additional transactions corresponding to the transaction token 124 (e.g., commission payments, rewards, etc. based on the transaction corresponding to the transaction token 124). The reconciliation manager 122 may then provide the developer transaction manager 112 with reports at least in part based on these additional transactions.

[0036] like Figure 1As shown, a given payment processing entity 116 may collectively represent one or more parties involved in processing a payment (also referred to herein as a transaction). For example, parties may include payment gateways, financial institutions, etc., which are communicatively coupled to each other and configured to process payments between different entities. In one example, payment processing entity 116 may process a payment made by a user of computing device 102 to developer entity 110. In another example, payment processing entity 116 may process a payment made by developer entity 110 to management entity 118 (described in more detail below). It should be noted that the foregoing examples are not intended to be limiting, and the payments described herein can include any amount, type, form, etc., at any granularity, consistent with the scope of this disclosure.

[0037] According to some implementation schemes, management entity 118 may collectively represent one or more entities configured to interact with computing device 102, developer entity 110, payment processing entity 116, etc. Figure 1 As shown, management entity 118 may implement user account manager 120 (described above and in more detail below), developer account manager 121, and reconciliation manager 122 (described above and in more detail below). According to some implementations, developer account manager 121 may be configured to maintain developer accounts known to developer account manager 121. A given developer account may include, for example, credentials for the developer account (e.g., a unique username and password). In this way, reconciliation manager 122 may associate transaction token 124 with the developer account to enable appropriate verification to be performed when executing the transaction token 124 generation process, reconciliation process, etc., as described herein.

[0038] According to some implementation schemes, and although not in Figure 1 As illustrated, management entity 118 can be configured to implement a virtual software application store that receives software application 108 from developer entity 110 and interfaces with computing device 102 to manage the distribution, installation, updates, deletion, etc., of software application 108. According to another approach, software application 108 can be installed on computing device 102 independently of the virtual software application store (referred to herein as "independently installed software application 108"). In either case, the reconciliation process described herein can be performed where appropriate.

[0039] It should be understood that, for the sake of simplicity, Figure 1 The various components of the illustrated computing device are given at a high level. For example, although Figure 1Not illustrated herein, but it should be understood that various computing devices may include common hardware / software components capable of implementing the software entities described above. For example, each computing device may include one or more processors that cooperate with one or more volatile memories (e.g., dynamic random access memory (DRAM)) and one or more storage devices (e.g., hard disk drives, solid-state drives (SSDs), etc.) to enable the execution of the various software entities described herein. Furthermore, each computing device may include communication components that enable the computing devices to send information to each other.

[0040] The following text combines Figure 9 A more detailed explanation of these hardware components is provided. Furthermore, it should be understood that, without departing from the scope of this disclosure, the computing device may include additional entities capable of implementing the various techniques described herein. Additionally, it should be understood that, without departing from the scope of this disclosure, the entities described herein may be combined or divided into additional entities. It should also be understood that, without departing from the scope of this disclosure, the various entities described herein may be implemented using software-based or hardware-based methods.

[0041] therefore, Figure 1 An overview is provided of how system 100, according to some implementation schemes, can implement the various techniques described herein. This will now be discussed below in conjunction with Figures 2 to... Figure 9 Provide a more detailed breakdown of the ways in which these technologies can be implemented.

[0042] Figures 2A to 2B A sequence diagram illustrating example technologies for managing transaction tokens 124 according to some implementation schemes is shown, which enable the execution of reconciliation processes. For example... Figure 2A As shown, at step 202, the user account framework 104 (implemented on computing device 102) and the user account manager 120 (implemented by management entity 118) periodically verify user accounts logged into computing device 102 (and known to user account manager 120) (e.g., as described above in conjunction with...). Figure 1 (As described).

[0043] At step 204, the software application 108 executing on computing device 102 sends a request to transaction framework 106 to execute a transaction. The software application 108 may send this request in numerous scenarios, such as when a user of the software application 108 attempts to execute a transaction associated with the software application 108, for example, purchasing a license to use the software application 108, purchasing goods or services offered through the software application 108, etc. It should be noted that the foregoing examples are not intended to be limiting, and that, consistent with the scope of this disclosure, the software application 108 may execute step 204 individually or repeatedly at any granularity in response to scenarios of any quantity, type, form, etc.

[0044] At step 206, transaction framework 106 interacts with user account framework 104 to verify the user account. As described above in conjunction with step 202, user account framework 104 maintains whether the user account is actively (i.e., effectively) logged into computing device 102. In this way, transaction framework 106 can act as an initial barrier that prevents requests for transaction token 124 from being made to reconciliation manager 122 when the user account is not actively logged into computing device 102. When such blocking occurs, user account framework 104 can request the user to perform steps to make the user account actively logged into computing device 102 (e.g., by providing login credentials for the user account (e.g., via the login user interface (UI)), by performing security verification, etc.). It should be noted that the foregoing examples are not intended to be limiting, and these login steps can include processes of any amount, type, form, etc., at any granularity, consistent with the scope of this disclosure.

[0045] At step 208, transaction framework 106 sends a request to reconciliation manager 122, which executes on management entity 118, to generate transaction token 124. According to some embodiments, the request may include a session identifier associated with the request. The session identifier may represent a unique identifier for the request generated using a method understood by both transaction framework 106 and reconciliation manager 122. The session identifier can advantageously enable both transaction framework 106 and reconciliation manager 122 to organize and maintain communication related to the request. In some embodiments, a private encryption key may be used to digitally sign the session identifier, wherein user account manager 120 possesses a corresponding public encryption key (of the private encryption key) that can be used to verify the digital signature. In this way, reconciliation manager 122 may interface with user account manager 120 to identify whether the digital signature included in the session identifier corresponds to a user account known to user account manager 120 / management entity 118, which user account is confirmed by user account manager 120 to be actively logged into computing device 102, etc. It should be understood that symmetric encryption keys can also be used to perform the aforementioned encryption, verification, and other processes. It should be noted that the foregoing examples are not intended to be limiting, and that session identifiers can include information of any quantity, type, form, etc., at any granularity level, consistent with the scope of this disclosure.

[0046] According to some implementations, the request may also include a unique identifier associated with software application 108. According to some implementations, reconciliation manager 122 may provide the unique identifier associated with software application 108 to developer account manager 121. Developer account manager 121 may then use the unique identifier to identify developer entity 110 associated with software application 108 (and known to developer account manager 121 / management entity 118). If software application 108 and / or developer entity 110 are not identified, or if either of them is flagged as ineligible to issue a request for transaction token 124, an appropriate rejection may be sent back to transaction framework 106 (which issues the request for transaction token 124 at step 208). It should be noted that the foregoing examples are not intended to be limiting, and the unique identifier may include information of any quantity, type, form, etc., at any granularity, consistent with the scope of this disclosure. For example, the unique identifier may include both the unique identifier of software application 108 and the unique identifier of developer entity 110, the request may include the unique identifier of developer entity 110 (in addition to the unique identifier of software application 108), and so on.

[0047] According to some implementations, the request may also include transaction type information (which is related to the transaction mentioned in step 204). For example, transaction type information may indicate whether the transaction will occur through software application 108 (i.e., in-app transaction), through at least one webpage loaded in a web browser application running on computing device 102 (i.e., external link redirection transaction), and so on. It should be noted that the foregoing examples are not intended to be limiting, and transaction type information can include any amount, type, form, etc., of information at any level of granularity, consistent with the scope of this disclosure.

[0048] According to some implementations, the request may also include storefront information, which includes location, currency, tax, and commission information associated with software application 108, computing device 102, and transactions (mentioned in step 204). For example, location information may indicate the geographic area in which computing device 102 is operating, the geographic area in which developer entity 110 is operating, and so on. Currency information may indicate the type of currency to be used to execute the transaction, including fiat currency, electronic currency, etc. Tax information may indicate the type and rate of tax to be collected with the transaction. Commission information may indicate the type and rate of commission to be collected after the transaction has been successfully executed (e.g., by reconciliation manager 122).

[0049] In short, it should be noted that the token generation request (issued at step 208) may also include pricing information associated with the transaction (mentioned in step 204). According to this method, the transaction token 124 (generated in response to the token generation request) may include pricing information. In this respect, when processing a transaction, and subsequently when performing a reconciliation process on the transaction, the transaction token 124 includes relevant pricing information required to perform the reconciliation process (e.g., calculating the commission payable to the reconciliation manager 122 based on the pricing information). In an alternative method, pricing information may be excluded from the transaction token 124. In this respect, when processing a transaction, and subsequently when performing a reconciliation process on the transaction, the pricing information corresponding to the transaction token 124 may be provided together with the transaction token 124 (provided to the reconciliation manager 122). This method can be advantageous because it allows the transaction token 124 to remain useful even when considering the expected transaction metrics (e.g., price, amount, etc.) between the generation of the transaction token 124 and the completion of the transaction. It should be noted that the foregoing examples are not intended to be limiting, and that pricing information may be stored, communicated, etc., in any quantity, type, form, etc., at any level of granularity, consistent with the scope of this disclosure.

[0050] At step 210, the reconciliation manager 122 authorizes the developer entity 110 associated with the software application 108 (e.g., by looking up / verifying the developer entity 110 using a unique identifier associated with the software application 108 / developer entity 110). Step 210 helps improve overall security by ensuring that the reconciliation manager 122 does not generate transaction tokens 124 for unauthorized software application 108 / developer entity 110.

[0051] At step 212, the reconciliation manager 122 generates and digitally signs a transaction token 124. According to some embodiments, the transaction token 124 may include information included in the token generation request (issued at step 208), information derived from the information included in the token generation request, other information obtained in association with the token generation request, and so on. According to some embodiments, the reconciliation manager 122 may use a private encryption key to digitally sign the transaction token 124, wherein one or more of the transaction framework 106, software application 108, developer entity 110, etc., have access to the corresponding public encryption key (of the private encryption key) that can be used to verify the digital signature. It should be understood that symmetric encryption keys can also be used to perform the aforementioned encryption, verification, and other processes. It should be noted that the foregoing examples are not intended to be limiting, and the transaction token 124 may include information of any amount, type, form, etc., at any granularity, consistent with the scope of this disclosure. In any case, at step 214, the reconciliation manager 122 provides the transaction token 124 to the transaction framework 106, and at step 216, the transaction framework 106 stores the transaction token 124.

[0052] At optional step 218, if transaction token 124 is invalidated (e.g., transaction token 124 is corrupted, timeout occurs, etc.), transaction framework 106 and reconciliation manager 122 may work together to optionally regenerate transaction token 124. Specifically, if an invalid transaction token 124 is regenerated, reconciliation manager 122 and transaction framework 106 may perform relevant / appropriate updates to re-verify transaction token 124. Alternatively, if the invalid transaction token 124 is replaced by a new transaction token 124, reconciliation manager 122 and transaction framework 106 may perform relevant / appropriate updates (e.g., by performing steps similar to those described below under user cancellation scenario 224).

[0053] At step 220, the transaction framework 106 instructs the software application 108 to display details associated with the transaction. As previously described herein, the transaction framework 106 may be implemented as an API accessed by the software application 108. In this regard, according to one example method, the transaction framework 106 may command the software application 108 to display details (as associated with the transaction) within the software application 108 (e.g., via a notification UI displayed within the software application 108). According to another example method, the transaction framework 106 may cause the overlay to be displayed independently of the software application 108 (e.g., by commanding an operating system (OS) implemented on the computing device 102). It should be noted that the foregoing examples are not intended to be limiting, and any amount, type, form, etc., of user interface can be used to display details on the computing device 102 at any level of granularity, consistent with the scope of this disclosure.

[0054] At step 222, the software application 108 / transaction framework 106 displays a UI including transaction details. An example implementation of the UI is exemplified as follows: Figure 3 User interface 304 and Figure 4A The user interface returned a 404 error. Figure 3 and Figure 4A As shown, the UI may include options for learning more about the transaction, continuing (i.e., approving) the transaction, or canceling the transaction (details of which are provided below). Figure 3 and Figures 4A to 4B (Describe it).

[0055] therefore, Figure 2A Example 224 illustrates a user cancellation scenario, which includes a series of steps that can be executed when a user requests cancellation of a transaction via the UI. Alternatively, if the user approves the transaction (at step 232), the following steps can be executed... Figure 2BThe remaining steps are illustrated (and described below). At step 226, the software application 108 / transaction framework 106 receives cancellation from the user via the UI. At step 228, the transaction framework 106 and the reconciliation manager 122 process the cancellation of transaction token 124. Specifically, the transaction framework 106 cancels transaction token 124 (received from the reconciliation manager 122 at step 214) (e.g., deletes the transaction token, invalidates the transaction token, etc.) and issues a request to the reconciliation manager 122 to cancel transaction token 124 (e.g., deletes the transaction token, invalidates the transaction token, etc.). Subsequently, at step 230, the reconciliation manager 122 cancels the transaction token (e.g., deletes the transaction token, invalidates the transaction token, etc.).

[0056] In short, it should be noted that one or more steps 220 to 232 may be omitted from the techniques described herein without departing from the scope of this disclosure. For example, the configuration of the reconciliation manager 122, the transaction framework 106, the OS implemented on the computing device 102, etc., may be updated such that when a transaction token 124 is received / a transaction is about to be executed, the information / UI discussed above in conjunction with steps 220 to 232 is not presented on the computing device 102. This configuration can be implemented at any granularity; for example, a user may choose to receive a notification when a transaction is about to be executed, but choose not to approve / cancel the transaction every time a notification is displayed. It should be noted that the foregoing examples are not intended to be limiting, and the techniques described herein may be adapted to user preferences, the level of trust between the management entity 118 and the developer entity 110 / software application 108, etc., consistent with the scope of this disclosure.

[0057] Figure 2B Examples of different steps that may be performed depending on the type of transaction in progress (e.g., as indicated in the transaction type information discussed herein). Specifically, in-app transaction method 240 includes a series of steps that may be performed when a transaction is to be executed within the software application 108 itself (referred to herein as an "in-app" transaction). Alternatively, external link redirection transaction method 260 includes a series of steps that may be performed when a transaction is to be executed via a webpage loaded into a web browser application (referred to herein as an "external link redirection" transaction), which is embedded within, overlaid on, etc., of the software application 108.

[0058] like Figure 2BAs shown, the in-app transaction method 240 involves a first step 242, in which the transaction framework 106 provides a transaction token 124 to the software application 108. Optionally, the transaction framework 106 may provide the transaction token 124 to a developer website 114, a developer transaction manager 112, etc. (as an alternative or supplement to providing the transaction token 124 to the software application 108). At step 244, the software application 108 provides the transaction token 124 and a request to execute the transaction to the developer transaction manager 112 (as associated with developer entity 110). Step 244 may occur, for example, in response to a user selecting an option to execute the transaction via the UI of the software application 108. The request to execute the transaction may include, for example, the price, quantity, etc., of the goods / services associated with the transaction, billing address information, delivery address information, payment information, etc. It should be noted that the foregoing examples are not intended to be limiting, and the request to execute the transaction can include information of any quantity, type, form, etc., at any granularity, consistent with the scope of this disclosure.

[0059] At step 246, the developer transaction manager 112 executes the transaction. Step 246 may involve, for example, the developer transaction manager 112 interfacing with at least one payment processing entity 116 to efficiently process the transaction. At step 248, the developer transaction manager 112 associates the result of the transaction (i.e., the transaction outcome) with the transaction token 124. Specifically, if the transaction is successful, the transaction outcome may indicate that the transaction was successful, pricing information associated with the transaction, etc. If the transaction is unsuccessful, the transaction outcome may indicate that the transaction was unsuccessful, information about why the transaction was unsuccessful, etc. It should be noted that the foregoing examples are not intended to be limiting, and the transaction outcome associated with the transaction token 124 may include information of any quantity, type, form, etc., at any granularity, consistent with the scope of this disclosure.

[0060] At step 250, the developer transaction manager 112 also provides the transaction result to the software application 108. According to some embodiments, the transaction result provided to the software application 108 may include information similar to, derived from, or otherwise closely related to the transaction, information included in the transaction result associated with the transaction token 124. For example, the transaction result provided to the software application 108 may include information about whether the transaction was successful or failed, order identifier information, order processing information, shipping tracking information, and so on. It should be noted that the foregoing examples are not intended to be limiting, and the transaction result provided to the software application 108 may include information of any quantity, type, form, etc., at any granularity, consistent with the scope of this disclosure.

[0061] like Figure 2BAs shown, the external link redirection transaction method 260 may differ from the in-app transaction method 240 in several ways. Specifically, the external link redirection transaction method 260 involves a first step 262, in which the transaction framework 106 provides a transaction token 124 to the developer website 114 (associated with developer entity 110). Optionally, the transaction framework 106 may provide the transaction token 124 to the software application 108, the developer transaction manager 112, etc. (as an alternative or supplement to providing the transaction token 124 to the developer website 114), and the developer website 114 may also provide the transaction token 124 to the developer transaction manager 112, and so on.

[0062] At step 264, transaction framework 106 redirects software application 108 to developer website 114. As described herein, transaction framework 106 may enable software application 108 to load an embedded web browser application, enable an OS implemented on computing device 102 to load the web browser application (e.g., which is overlaid on software application 108), and so on. In any case, step 268 involves software application 108, transaction framework 106, and developer website 114 working together to load / display developer website 114 on computing device 102. According to some embodiments, software application 108 may provide transaction framework 106 with a Uniform Resource Locator (URL) corresponding to developer website 114, wherein transaction framework 106 then provides the URL to the aforementioned web browser application (so that developer website 114 is loaded within the web browser application). According to some embodiments, the URL may include parameters that enable developer website 114 to reflect a transaction (e.g., product / service information, pricing information, payment information, billing address information, delivery address information, etc.).

[0063] At step 270, the software application 108 / web browser application provides a request to the developer website 114 to execute a transaction. For example, step 270 may occur in response to a user selecting an option to execute a transaction via the UI of the developer website 114. At step 272, the developer website 114 and the developer transaction manager 112 execute the transaction. Step 272 may involve, for example, the developer website 114, the developer transaction manager 112, etc., interfacing with at least one payment processing entity 116 to execute the transaction. At step 274, the developer transaction manager 112 associates the result of the transaction (i.e., the transaction outcome) with the transaction token 124 (e.g., consistent with the technique described above in conjunction with step 248). At step 276, the developer website 114 provides the transaction outcome to the software application 108 / web browser application (e.g., consistent with the technique described above in conjunction with step 250).

[0064] therefore, Figures 2A to 2BTechnology for managing transaction tokens, according to several implementation schemes, is provided, which enables the execution of reconciliation processes. Additionally, Figure 2C A sequence diagram illustrating the technologies used to perform the reconciliation process according to some implementation schemes is shown. For example... Figure 2C As shown, the reconciliation process may include step 280, in which the developer transaction manager 112 provides the reconciliation manager 122 with one or more transaction tokens 124 associated with completed transactions. The developer transaction manager 112 may execute step 280 in response to the satisfaction of different conditions. For example, the developer transaction manager 112 may execute step 280 whenever a transaction associated with a transaction token 124 is successfully completed. In another example, the developer transaction manager 112 may execute step 280 after a threshold number of transactions associated with transaction token 124 have been successfully completed. In yet another example, the developer transaction manager 112 may execute step 280 periodically (e.g., at the end of a day, week, month, etc.). It should be noted that the foregoing examples are not intended to be limiting, and these conditions can include conditions of any quantity, type, form, etc., at any granularity, consistent with the scope of this disclosure. In any case, and as previously described herein, transaction token 124 may include pricing (and other) information related to the reconciliation process, or alternatively, developer transaction manager 112 may store associated information for transaction token 124, wherein such associated information includes pricing information. Therefore, at step 280, the information sent by developer transaction manager 112 to reconciliation manager 122 includes transaction token 124, and, where appropriate, the aforementioned associated information, to enable efficient execution of the reconciliation process.

[0065] At step 282, the reconciliation manager 122 verifies one or more transaction tokens 124. For example, this verification can be performed by verifying a digital signature initially established by the reconciliation manager 122 (and / or by verifying a digital signature provided by another entity trusted by the reconciliation manager 122 that can be verified by the reconciliation manager). At step 284, the reconciliation manager 122 executes at least one transaction based on one or more transaction tokens 124. For example, given a transaction token 124 instructing developer entity 110 to issue an invoice to a customer for a specific product, service, etc., the reconciliation manager 122 can calculate the corresponding commission fee payable to management entity 118. In another example, given a transaction token 124 instructing developer entity 110 to refund a customer for a specific product, service, etc., the reconciliation manager 122 can identify the original commission fee charged to developer entity 110 and arrange an appropriate refund of the commission fee. It should be noted that the foregoing examples are not intended to be limiting, and the transactions executed by the reconciliation manager 122 can be transactions of any amount, type, form, etc., at any granularity, consistent with the scope of this disclosure. Additionally, it should be noted that the reconciliation manager 122 may store a set of rules for each developer entity 110, software application 108, etc., to effectively identify how the reconciliation process should be performed for a given set of transaction tokens 124. Alternatively (or additionally), one or more rules may be embedded in the transaction tokens 124 so that the appropriate rules can be immediately identified and executed when the reconciliation process is performed.

[0066] At step 286, the reconciliation manager 122 generates a report reflecting one or more transaction tokens 124 and at least one transaction. The report may include, for example, information derived from the transaction token 124, information associated with the transaction token 124 (when provided by the developer entity 110), and information associated with the reconciliation process performed in connection with the transaction token 124. It should be noted that the foregoing examples are not intended to be limiting, and the report may include information of any amount, type, form, etc., at any granularity, consistent with the scope of this disclosure. At step 288, the reconciliation manager 122 provides the report to the developer transaction manager 112.

[0067] therefore, Figure 2C A sequence diagram illustrating the technologies used to perform the reconciliation process according to some implementation schemes is shown. Additionally, Figure 3 and Figures 4A to 4B Conceptual diagrams are provided for user interfaces that can be displayed in conjunction with the techniques described herein, according to some implementation schemes. Specifically, Figure 3 A conceptual diagram 300 illustrates an example user interface that may be displayed when an in-app transaction is executed on a computing device 102, according to some implementation schemes of software application 108. Figure 3As shown, when a user is about to execute an in-app transaction through software application 108, the user interface 302 of software application 108 can be displayed. When the user selects an option to execute the transaction, the user interface 304 of software application 108 is displayed, which informs the user that software application 108 is about to execute a transaction that the user should be aware of. When the user selects an option to continue the transaction, the user interface 306 of software application 108 is displayed, which shows the user the result of the transaction.

[0068] Figures 4A to 4B A conceptual diagram 400 illustrates an example user interface that may be displayed when an external link transaction is executed on computing device 102, according to some implementation schemes. For example... Figure 4A As shown, when a user is about to execute an external link redirection transaction through software application 108, the user interface 402 of software application 108 can be displayed. When the user selects an option to execute the transaction, the user interface 404 of software application 108 is displayed, which informs the user that software application 108 is about to execute a transaction that the user should be aware of. When the user selects an option to continue the transaction, a web browser application is loaded, and the user interface 406 of the web browser application is displayed, which includes details of the transaction to be executed.

[0069] When the user selects an option to continue the transaction, the web browser application's user interface 408 is displayed. Figure 4B (As illustrated in the example), this user interface indicates that a transaction is being processed. When the transaction is processed, the web browser application's user interface 410 is displayed, indicating that the transaction has been successfully processed. The web browser application's user interface 410 also indicates that the web browser application will close automatically, and then the user interface of the software application 108 will be displayed again. Subsequently, when the web browser application is hidden, the software application 108's user interface 412 is displayed, which shows the user the result of the transaction.

[0070] Figure 5 An example of method 500 for managing transaction tokens to facilitate reconciliation processes, according to some implementation schemes, is illustrated. Specifically, method 500 involves steps that can be performed by a transaction framework 106 implemented on a computing device. Figure 5 As shown, method 500 begins at step 502, in which the transaction framework 106 receives a first request to execute a transaction from a software application executing on a computing device (e.g., as described above in conjunction with...). Figure 2A (As described).

[0071] At step 504, the transaction framework 106 provides the management entity with a second request to generate a transaction token for the transaction (e.g., as described above in conjunction with...). Figure 2A(As described above). At step 506, the transaction framework 106 receives a transaction token from the management entity (e.g., as described above in conjunction with...). Figure 2A (As described above). At step 508, the transaction framework 106 displays a user interface (UI) indicating that the transaction will be executed independently of the management entity (or makes the UI displayed), wherein the UI includes a first option for approving the transaction and a second option for canceling the transaction (e.g., as described above in conjunction with...). Figure 2A (As described).

[0072] At step 510, the transaction framework 106 receives a selection of a first option for approving the transaction via the UI (e.g., as described above in conjunction with...). Figure 2A (As described above). At step 512, transaction framework 106 provides a transaction token to the software application or the developer entity associated with the software application, such that when a transaction is executed, the transaction token enables the execution of a reconciliation process (e.g., as described above in conjunction with...). Figure 2C (As described).

[0073] Figure 6 An example of method 600 for managing transaction tokens to facilitate the reconciliation process, according to some implementation schemes, is illustrated. Specifically, method 600 involves steps that can be performed by management entity 118. For example... Figure 6 As shown, method 600 begins at step 602, in which the management entity 118 receives a request from a transaction framework implemented on a computing device to generate a transaction token for a transaction that will be executed at least in part by a software application running on the computing device (e.g., as described above in conjunction with...). Figure 2A (As described).

[0074] At step 604, management entity 118 verifies the software application and the developer entity associated with the software application (e.g., as described above in conjunction with...). Figure 2A (As described above). At step 606, management entity 118 generates a transaction token (e.g., as described above in conjunction with...). Figure 2A (As described above). At step 608, the management entity 118 provides a transaction token to the transaction framework (e.g., as described above in conjunction with...). Figure 2A (As described).

[0075] At step 610, the management entity 118 receives (1) a transaction token and (2) a transaction result associated with the transaction (e.g., as described above in conjunction with...). Figure 2C (As described above). At step 612, management entity 118 performs a reconciliation process based on the transaction token and transaction result (e.g., as described above in conjunction with...). Figure 2C (As described).

[0076] Figure 7An example of method 700 for managing transaction tokens to facilitate reconciliation processes, according to some implementation schemes, is illustrated. Specifically, method 700 involves steps for executing in-app transactions, which can be performed by a software application 108 running on a computing device. Figure 7 As shown, method 700 begins at step 702, in which software application 108 executing on a computing device receives a first request to execute a transaction (e.g., as described above in conjunction with...). Figure 2A (As described).

[0077] At step 704, software application 108 provides a second request to the transaction framework implemented on the computing device to execute the transaction (e.g., as described above in conjunction with...). Figure 2A (As described above). At step 706, the software application 108 displays a user interface (UI) under the instructions of the transaction framework. The user interface (UI) indicates that the transaction will be executed independently of the management entity associated with the computing device, wherein the UI includes a first option for approving the transaction and a second option for canceling the transaction (e.g., as described above in conjunction with...). Figure 2A (As described).

[0078] At step 708, software application 108 receives a transaction token from the transaction framework, wherein: the transaction token is provided in conjunction with a selection of a first option for approving a transaction received via the UI, and the transaction token corresponds to the transaction (e.g., as described above in conjunction with...). Figures 2A to 2B (As described above). At step 710, software application 108 provides a transaction token to the developer entity associated with the software application, enabling the developer entity to execute a transaction, such that when the transaction is executed, the transaction token enables the execution of a reconciliation process (e.g., as described above in conjunction with...). Figure 2C (As described).

[0079] Figure 8 An example is illustrated of a method 800 for managing transaction tokens to facilitate the reconciliation process, according to some implementation schemes. Specifically, method 800 involves steps for executing an external link transaction, which can be executed by a software application 108 and a web browser application running on a computing device. Figure 8 As shown, method 800 begins at step 802, in which software application 108 receives a first request to execute a transaction (e.g., as described above in conjunction with...). Figure 2A (As described).

[0080] At step 804, software application 108 provides a second request to the transaction framework implemented on the computing device to execute the transaction (e.g., as described above in conjunction with...). Figure 2A(As described above). At step 806, the software application 108 displays a user interface (UI) under the instructions of the transaction framework. The user interface (UI) indicates that the transaction will be executed independently of the management entity associated with the computing device, wherein the UI includes a first option for approving the transaction and a second option for canceling the transaction (e.g., as described above in conjunction with...). Figure 2A (As described).

[0081] At step 808, software application 108 receives a selection of a first option for approving a transaction, wherein the transaction framework provides a transaction token to the developer entity, and the transaction token corresponds to the transaction (e.g., as described above in conjunction with...). Figures 2A to 2B (As described above). At step 810, software application 108 loads a web browser application under the instructions of the transaction framework (e.g., as described above in conjunction with...). Figure 2B (As described).

[0082] At step 812, software application 108 causes a web browser application to load a website corresponding to the developer entity associated with the software application (e.g., as described above in conjunction with...). Figure 2B (As described above). At step 814, software application 108 causes the developer entity to execute a transaction via a web browser application, such that when the transaction is executed, the transaction token enables the execution of a reconciliation process (e.g., as described above in conjunction with...). Figure 2C (As described).

[0083] Figure 9 A detailed view of a computing device 900, according to some implementation schemes, that can be used to implement the various components described herein is illustrated. Specifically, the detailed view illustrates various components that may be included in computing device 102, developer entity 110, and management entity 118.

[0084] like Figure 9As shown, computing device 900 may include a processor 902 representing a microprocessor or controller for controlling the overall operation of computing device 900. Computing device 900 may also include a user input device 908 that allows a user of computing device 900 to interact with it. For example, user input device 908 may take various forms, such as buttons, keypads, dial pads, touchscreens, audio input interfaces, visual / image capture input interfaces, input in the form of sensor data, etc. Furthermore, computing device 900 may include a display 910 (screen display) that can be controlled by processor 902 to display information to a user. Data bus 916 facilitates data transfer between at least storage device 940, processor 902, and controller 913. Controller 913 can be used to interface with and control different devices via equipment control bus 914. Computing device 900 may also include a network / bus interface 911 coupled to data link 912. In the case of wireless connectivity, network / bus interface 911 may include a wireless transceiver.

[0085] The computing device 900 also includes a storage device 940, which may include a single disk or multiple disks (e.g., an SSD), and includes a storage management module for managing one or more partitions within the storage device 940. In some embodiments, the storage device 940 may include flash memory, semiconductor (solid-state) memory, etc. The computing device 900 may also include random access memory (RAM) 920 and read-only memory (ROM) 922. ROM 922 may store programs, utilities, or processes to be executed in a non-volatile manner. RAM 920 may provide volatile data storage and store instructions related to the operation of the computing device described herein.

[0086] Various aspects, embodiments, specific implementations, or features of the described embodiments may be used individually or in any combination. Various aspects of the described embodiments may be implemented by software, hardware, or a combination of hardware and software. The described embodiments may also be embodied in computer-readable code on a computer-readable medium. A computer-readable medium is any data storage device that can store data that can be read by a computer system. Examples of computer-readable media include read-only memory, random access memory, CD-ROM, DVD, magnetic tape, hard disk drive, solid-state drive, and optical data storage devices. Computer-readable media may also be distributed across a network-coupled computer system, enabling the computer-readable code to be stored and executed in a distributed manner.

[0087] For illustrative purposes, the foregoing description uses specific names to provide a thorough understanding of the described embodiments. However, it will be apparent to those skilled in the art that specific details are not required to practice the described embodiments. Therefore, the foregoing description of specific embodiments is presented for illustrative and descriptive purposes. The foregoing description is not intended to be exhaustive or to limit the described embodiments to the precise forms disclosed. It will be apparent to those skilled in the art that many modifications and variations are possible in light of the teachings above.

[0088] As described herein, one aspect of the present invention is the collection and use of data available from various sources to improve user experience. This disclosure contemplates that, in some instances, such collected data may include personal information that uniquely identifies or can be used to contact or locate specific individuals. Such personal information may include demographic data, location-based data, telephone numbers, email addresses, home addresses, data or records related to a user's health or fitness level (e.g., vital sign measurements, medication information, exercise information), date of birth, smart home activities, or any other identifying information or personal information. This disclosure recognizes that the use of such personal information in the present invention can be used to benefit users.

[0089] This disclosure anticipates that entities responsible for the collection, analysis, disclosure, transmission, storage, or other use of such personal information data will comply with robust privacy policies and / or privacy measures. Specifically, such entities should implement and adhere to privacy policies and measures that are recognized as meeting or exceeding industry or governmental requirements for maintaining the privacy and security of personal information data. Such policies should be easily accessible to users and should be updated as the collection and / or use of data changes. Personal information from users should be collected for legitimate and reasonable entity purposes and should not be shared or sold outside of these legitimate purposes. Furthermore, such collection / sharing should be conducted only after receiving informed consent from users. Additionally, such entities should consider taking any necessary steps to protect and safeguard the right to access such personal information data and ensure that other entities with access to such personal information data comply with the privacy policies and procedures of other entities. Furthermore, such entities may subject themselves to third-party assessments to demonstrate their compliance with widely accepted privacy policies and privacy measures. Moreover, policies and measures should be appropriate to the specific types of personal information data collected and / or accessed, and should be compatible with applicable laws and standards, including considerations of specific jurisdictions. For example, in the United States, the collection or access to certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA); while in other countries, health data may be subject to other regulations and policies and should be handled accordingly. Therefore, different privacy measures should be advocated for different types of personal data in each country.

[0090] Regardless of the foregoing, this disclosure also contemplates implementation schemes for users to selectively block the use or access to personal information data. That is, this disclosure contemplates providing hardware and / or software components to prevent or block access to such personal information data. For example, the technology of this invention can be configured to allow users to opt-in or opt-out at any time during or after registering for the service. As another example, users can choose to provide only specific types of data that contribute to the technology described herein. In addition to providing "opt-in" and "opt-out" options, this disclosure also contemplates providing notifications related to access to or use of personal information. For example, users can be notified that their personal information data is accessible, and then reminded again before the personal information data is accessed.

[0091] Furthermore, the intent of this disclosure is that personal information data should be managed and processed in a manner that minimizes the risk of unintentional or unauthorized access or use. Once data is no longer needed, this risk can be minimized by restricting data collection and deleting data. Additionally, and where applicable, including in certain health-related applications, data deidentification can be used to protect user privacy. Deidentification can be facilitated, where appropriate, by removing specific identifiers (e.g., date of birth, etc.), controlling the amount or specificity of stored data (e.g., collecting location data at the city level rather than the address level), controlling how data is stored (e.g., aggregating data among users), and / or other methods.

[0092] Therefore, while this disclosure broadly covers the use of personal information data to implement one or more of the various disclosed embodiments, it is also contemplated that various embodiments can be implemented without access to such personal information data. That is, various embodiments of the present invention will not become inoperable due to the absence of all or part of such personal information data.

Claims

1. A method for managing transaction tokens to facilitate a reconciliation process, the method comprising: A transaction framework implemented on a computing device: Receive a first request to execute a transaction from a software application running on the computing device; Provide the management entity with a second request to generate a transaction token for the transaction; Receive the transaction token from the management entity; The user interface (UI) that indicates the transaction will be executed independently of the management entity is displayed, wherein the UI includes a first option for approving the transaction and a second option for canceling the transaction; Receive a selection of the first option for approving the transaction via the UI; as well as The transaction token is provided to the software application or a developer entity associated with the software application, wherein the transaction token enables the execution of a reconciliation process when the transaction is executed.

2. The method according to claim 1, further comprising: In response to receiving the first request to execute the transaction: Identify the user account associated with the computing device; Interact with the management entity to receive valid verification of the user account; and The verification is received from the management entity.

3. The method of claim 1, wherein the second request comprises: The session identifier associated with the second request, A unique identifier associated with the software application. Transaction type information, which defines whether the transaction will occur through the software application or through at least one webpage loaded in a web browser application running on the computing device. Store information, which includes location, currency, tax, and commission information associated with the software application, the computing device, the transaction, or some combination thereof.

4. The method according to claim 1, further comprising: In response to receiving a selection of the first option for approving the transaction via the UI, the UI is hidden.

5. The method according to claim 1, wherein the reconciliation process includes: Execute a second transaction based on the aforementioned transaction; as well as Provide the developer entity with a report that includes information associated with at least the second transaction.

6. The method of claim 1, wherein the transaction framework includes an application programming interface (API) communicatively coupled to: At least the software application and at least the management entity.

7. The method according to claim 1, further comprising: Before displaying the UI: Verify that the transaction token is valid.

8. A non-transitory computer-readable storage medium configured to store instructions that, when executed by at least one processor included in a computing device, cause the computing device to implement a transaction framework for managing transaction tokens to facilitate a reconciliation process by performing steps including: Receive a first request to execute a transaction from a software application running on the computing device; Provide the management entity with a second request to generate a transaction token for the transaction; Receive the transaction token from the management entity; The user interface (UI) that indicates the transaction will be executed independently of the management entity is displayed, wherein the UI includes a first option for approving the transaction and a second option for canceling the transaction; Receive a selection of the first option for approving the transaction via the UI; as well as The transaction token is provided to the software application or a developer entity associated with the software application, wherein the transaction token enables the execution of a reconciliation process when the transaction is executed.

9. The non-transitory computer-readable storage medium according to claim 8, wherein the step further comprises: In response to receiving the first request to execute the transaction: Identify the user account associated with the computing device; Interact with the management entity to receive valid verification of the user account; and The verification is received from the management entity.

10. The non-transitory computer-readable storage medium of claim 8, wherein the second request comprises: The session identifier associated with the second request, A unique identifier associated with the software application. Transaction type information, which defines whether the transaction will occur through the software application or through at least one webpage loaded in a web browser application running on the computing device. Store information, which includes location, currency, tax, and commission information associated with the software application, the computing device, the transaction, or some combination thereof.

11. The non-transitory computer-readable storage medium of claim 8, wherein the step further comprises: In response to receiving a selection of the first option for approving the transaction via the UI, the UI is hidden.

12. The non-transitory computer-readable storage medium of claim 8, wherein the reconciliation process comprises: Execute a second transaction based on the aforementioned transaction; as well as Provide the developer entity with a report that includes information associated with at least the second transaction.

13. The non-transitory computer-readable storage medium of claim 8, wherein the transaction framework includes an application programming interface (API) communicatively coupled to: At least the software application and at least the management entity.

14. The non-transitory computer-readable storage medium of claim 8, wherein the step further comprises: Before displaying the UI: Verify that the transaction token is valid.

15. A computing device configured to implement a transaction framework for managing transaction tokens to facilitate a reconciliation process, the computing device comprising: At least one processor; and At least one memory, the at least one memory storing instructions that, when executed by the at least one processor, cause the computing device to perform steps including the following operations: Receive a first request to execute a transaction from a software application running on the computing device; Provide the management entity with a second request to generate a transaction token for the transaction; Receive the transaction token from the management entity; The user interface (UI) that indicates the transaction will be executed independently of the management entity is displayed, wherein the UI includes a first option for approving the transaction and a second option for canceling the transaction; Receive a selection of the first option for approving the transaction via the UI; as well as The transaction token is provided to the software application or a developer entity associated with the software application, wherein the transaction token enables the execution of a reconciliation process when the transaction is executed.

16. The computing device of claim 15, wherein the step further comprises: In response to receiving the first request to execute the transaction: Identify the user account associated with the computing device; Interact with the management entity to receive valid verification of the user account; and The verification is received from the management entity.

17. The computing device of claim 15, wherein the second request comprises: The session identifier associated with the second request, A unique identifier associated with the software application. Transaction type information, which defines whether the transaction will occur through the software application or through at least one webpage loaded in a web browser application running on the computing device. Store information, which includes location, currency, tax, and commission information associated with the software application, the computing device, the transaction, or some combination thereof.

18. The computing device of claim 15, wherein the step further comprises: In response to receiving a selection of the first option for approving the transaction via the UI, the UI is hidden.

19. The computing device of claim 15, wherein the reconciliation process comprises: Execute a second transaction based on the aforementioned transaction; as well as Provide the developer entity with a report that includes information associated with at least the second transaction.

20. The computing device of claim 15, wherein the transaction framework includes an application programming interface (API) communicatively coupled to: At least the software application and at least the management entity.

Images