CN110942393A - Transaction processing method and device based on main and sub accounts and electronic equipment - Google Patents
Transaction processing method and device based on main and sub accounts and electronic equipment Download PDFInfo
- Publication number
- CN110942393A CN110942393A CN201911096829.5A CN201911096829A CN110942393A CN 110942393 A CN110942393 A CN 110942393A CN 201911096829 A CN201911096829 A CN 201911096829A CN 110942393 A CN110942393 A CN 110942393A
- Authority
- CN
- China
- Prior art keywords
- account
- transaction
- sub
- main
- user
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/06—Asset management; Financial planning or analysis
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/22—Payment schemes or models
- G06Q20/227—Payment schemes or models characterised in that multiple accounts are available, e.g. to the payer
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
- G06Q40/04—Trading; Exchange, e.g. stocks, commodities, derivatives or currency exchange
Landscapes
- Business, Economics & Management (AREA)
- Engineering & Computer Science (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Theoretical Computer Science (AREA)
- Development Economics (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- Strategic Management (AREA)
- Economics (AREA)
- Marketing (AREA)
- Technology Law (AREA)
- Entrepreneurship & Innovation (AREA)
- Operations Research (AREA)
- Human Resources & Organizations (AREA)
- Game Theory and Decision Science (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
One or more embodiments of the present specification provide a transaction processing method and apparatus based on a main sub-account, and an electronic device; the user account comprises a main account and a plurality of sub-accounts, and the transaction total amount maintained by the main account is the sum of the transaction total amounts respectively maintained by the sub-accounts; the method comprises the following steps: receiving a transaction request initiated by a user through a client; the transaction request comprises a transaction amount, a main account identifier of a main account of the user and a sub-account identifier of a sub-account; responding to the transaction request, and verifying a main account corresponding to the main account identification and a sub account corresponding to the sub account identification; if the main account and the sub-account pass the verification, synchronously updating the transaction total amount maintained by the main account based on the transaction amount, and asynchronously updating the transaction total amount maintained by the sub-account based on the transaction amount; and if the synchronous updating of the primary account is completed, sending a notification message that the transaction is successful to the client.
Description
Technical Field
One or more embodiments of the present disclosure relate to the technical field of computer applications, and in particular, to a transaction processing method and apparatus based on a main account and a sub account, and an electronic device.
Background
The affiliate can be connected with a plurality of financial institutions, and the securities such as stocks, funds and the like issued by the financial institutions in the financial market are integrated into financial products to be provided for users. The user may open a user account at the affiliate and use the user account to purchase the appropriate portfolio to invest in through the financial product. Generally, the affiliate needs to perform accounting based on the user account of the user, that is, to store the association relationship between the transaction information of the securities, such as the total transaction amount and the transaction details of the user, and the user account of the user, so as to distinguish the transaction information of different users.
Disclosure of Invention
The specification provides a transaction processing method based on a main account and a sub account; the user account comprises a main account and a plurality of sub-accounts, and the transaction total amount maintained by the main account is the sum of the transaction total amounts respectively maintained by the sub-accounts; the method comprises the following steps:
receiving a transaction request initiated by a user through a client; the transaction request comprises a transaction amount, a main account identifier of a main account of the user and a sub-account identifier of a sub-account;
in response to the transaction request, verifying a main account corresponding to the main account identification and a sub-account corresponding to the sub-account identification;
if the main account and the sub-account pass the verification, synchronously updating the transaction total amount maintained by the main account based on the transaction amount, and asynchronously updating the transaction total amount maintained by the sub-account based on the transaction amount;
and if the synchronous updating of the primary account is completed, sending a notification message of successful transaction to the client.
Optionally, the method further comprises:
and if the verification of the main account or the sub account is not passed, sending a notification message of transaction failure to the client.
Optionally, before the synchronously updating the transaction total maintained by the primary account based on the transaction amount and the asynchronously updating the transaction total maintained by the secondary account based on the transaction amount, the method further comprises:
determining whether a transaction scene corresponding to the transaction request hits a preset asynchronous transaction scene;
and if the transaction scene hits the asynchronous transaction scene and the main account and the sub-account are verified to pass, synchronously updating the transaction total amount maintained by the main account based on the transaction amount, and asynchronously updating the transaction total amount maintained by the sub-account based on the transaction amount.
Optionally, the method further comprises:
if the transaction scene is not hit in the asynchronous transaction scene, and the main account and the sub-account are verified to pass, synchronously updating the transaction total amount respectively maintained by the main account and the sub-account based on the transaction amount;
and if the synchronous updating of the main account and the sub account is finished, sending a notification message of successful transaction to the client.
Optionally, the preset asynchronous transaction scenario includes: a fund subscription scenario, a fund redemption scenario.
The specification also provides a transaction processing device based on the main and sub accounts; the user account comprises a main account and a plurality of sub-accounts, and the transaction total amount maintained by the main account is the sum of the transaction total amounts respectively maintained by the sub-accounts; the device comprises:
the receiving module is used for receiving a transaction request initiated by a user through a client; the transaction request comprises a transaction amount, a main account identifier of a main account of the user and a sub-account identifier of a sub-account;
the verification module is used for responding to the transaction request and verifying a main account corresponding to the main account identification and a sub account corresponding to the sub account identification;
the first updating module is used for synchronously updating the transaction total amount maintained by the main account based on the transaction amount and asynchronously updating the transaction total amount maintained by the sub account based on the transaction amount if the main account and the sub account are verified to pass;
and the first notification module is used for sending a notification message of successful transaction to the client if the synchronous updating of the primary account is completed.
Optionally, the apparatus further comprises:
and the second notification module is used for sending a notification message of transaction failure to the client if the verification of the main account or the sub-account is not passed.
Optionally, the apparatus further comprises:
the determining module is used for synchronously updating the transaction total amount maintained by the main account based on the transaction amount, and determining whether a transaction scene corresponding to the transaction request hits a preset asynchronous transaction scene before asynchronously updating the transaction total amount maintained by the sub-account based on the transaction amount;
the first update module:
and if the transaction scene hits the asynchronous transaction scene and the main account and the sub-account are verified to pass, synchronously updating the transaction total amount maintained by the main account based on the transaction amount, and asynchronously updating the transaction total amount maintained by the sub-account based on the transaction amount.
Optionally, the apparatus further comprises:
the second updating module is used for synchronously updating the transaction total amount respectively maintained by the main account and the sub-account based on the transaction amount if the transaction scene is not hit in the asynchronous transaction scene and the main account and the sub-account are verified;
and the third notification module is used for sending a notification message of successful transaction to the client if the synchronous updating of the main account and the sub account is completed.
Optionally, the preset asynchronous transaction scenario includes: a fund subscription scenario, a fund redemption scenario.
This specification also proposes an electronic device including:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the steps of the above method by executing the executable instructions.
The present specification also contemplates a computer-readable storage medium having stored thereon computer instructions which, when executed by a processor, implement the steps of the above-described method.
In the above technical solution, on one hand, when a transaction request initiated by a user and including a main account identifier and a sub-account identifier of the user is received, a main account corresponding to the main account identifier in the transaction request and a sub-account corresponding to the sub-account identifier in the transaction request are checked, and when both the main account and the sub-account pass the check, a total transaction amount maintained by the main account is updated synchronously based on a transaction amount in the transaction request, that is, the main account is updated immediately, and a total transaction amount maintained by the sub-account is updated asynchronously based on the transaction amount, that is, the sub-account is updated at any subsequent time. Because the verification of the sub-account is completed in advance, the sub-account can be directly updated subsequently without verifying the sub-account, and thus the success rate of asynchronous updating of the sub-account can be ensured.
On the other hand, when the synchronous updating of the primary account is completed, the user can be informed that the transaction is successful. By adopting the mode, compared with the mode that the user needs to be informed of the successful transaction after the update of the sub-account and the main account is completed in the related technology, the synchronous update of the sub-account can be avoided, so that the transaction duration can be shortened, and the user experience can be improved.
Drawings
FIG. 1 is a schematic view of a value document trading system;
FIG. 2 is a schematic illustration of a fund procurement interface;
FIG. 3A is a schematic illustration of a user account management interface;
FIG. 3B is a schematic view of another user account management interface;
FIG. 3C is a schematic diagram of yet another user account management interface
FIG. 4 is a flow diagram illustrating a method for processing transactions based on a primary sub-account in accordance with an exemplary embodiment of the present description;
FIG. 5 is a block diagram of the hardware of an electronic device in which a transaction processing device based on a primary sub-account is located according to an exemplary embodiment of the present disclosure;
FIG. 6 is a block diagram of a primary sub-account based transaction processing device, according to an exemplary embodiment of the present description.
Detailed Description
Reference will now be made in detail to the exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, like numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with one or more embodiments of the present specification. Rather, they are merely examples of apparatus and methods consistent with certain aspects of one or more embodiments of the specification, as detailed in the claims which follow.
The terminology used in the description herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the description. As used in this specification and the appended claims, the singular forms "a", "an", and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used herein to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information, without departing from the scope of the present specification. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
Referring to fig. 1, fig. 1 is a schematic diagram of a value document trading system.
As shown in fig. 1, the value sheet trading system may include: the system comprises a proxy agency service end, one or more user clients and one or more financial institution clients, wherein the one or more user clients and the one or more financial institution clients are connected with the proxy agency service end.
In practice, a financial institution may issue securities (e.g., funds, stocks, etc.) on a financial market. The affiliate can arrange the securities issued by each financial institution which is in butt joint with the affiliate, so that the related information (such as fund names, issuing institutions, annual rate of return and the like) of the securities can be displayed to the user for the user to select and buy the proper securities.
Typically, a user may open a user account at a affiliate. The affiliate can then perform appropriate transaction processing (e.g., purchase, redemption, freezing, thawing, etc. of securities) based on the user's user account in accordance with the user-initiated transaction request.
In order to distinguish various securities purchased by a user, when the user purchases a certain securities for the first time, a sub-account corresponding to the securities can be automatically created by a proxy mechanism under the user account of the user; subsequently, the affiliate may conduct transaction processing corresponding to the portfolio based on the sub-account. That is, at this time, the user account of the user may include a main account and a sub-account corresponding to the securities purchased by the user; the total transaction amount maintained by a sub-account may be the total amount of securities purchased by the user corresponding to the sub-account, and the total transaction amount maintained by the main account is the sum of the total transaction amounts maintained by all sub-accounts included in the user account.
Referring to FIG. 2, FIG. 2 is a schematic diagram of a fund procurement interface.
The affiliate may provide the fund subscription interface shown in fig. 2 to the user, that is, the affiliate service end sends the relevant data of the fund subscription interface to the user client installed on the terminal device used by the user, so that the user client can display the fund subscription interface to the user.
The fund subscription interface can display the relevant information of the fund issued by each financial institution interfaced with the affiliate. Taking the fund named "fund X" shown in the fund subscription interface as an example, the issuing organization of the fund is financial institution X, and the annual profitability of the fund is 3.65%.
The user may select an appropriate fund for fund subscription through the fund subscription interface, i.e. purchase the equivalent amount of the fund by paying a certain amount of money to the issuer of the fund.
In the related art, a user may first transfer a cash amount to an affiliate, and the affiliate service may add the cash amount to an account balance maintained by the user's primary account. Subsequently, the user can initiate a purchase applying request for a certain fund shown in the fund applying interface displayed on the user client side, and the purchase applying request is sent to the affiliate service side by the user client side. For example, the user may click a "buy" button corresponding to the fund in the fund subscription interface, input a subscription amount in a user interface that is skipped thereafter, and click an "confirm" button in the user interface; when the user client detects the click operation of the 'confirmation' button, a purchase request comprising the purchase amount, the main account identification (for example, the main account number) of the main account of the user and the sub-account identification (for example, the sub-account number) of the sub-account corresponding to the fund can be constructed and sent to the agency server.
When the affiliate service end receives the subscription request, on one hand, the transfer can be performed from the user account of the user to the financial institution account opened by the affiliate of the fund on the basis of the subscription amount in the subscription request, namely, the subscription amount is deducted from the account balance maintained by the main account of the user, and the subscription amount is added to the account balance of the financial institution account of the issuer of the fund; on the other hand, the subscription amount may be added to the total transaction amount maintained by the sub-account after the user's sub-account corresponding to the fund passes verification, while the subscription amount may be added to the total transaction amount maintained by the primary account after the user's primary account passes verification.
Referring to fig. 3A, 3B and 3C, fig. 3A is a schematic diagram of a user account management interface, fig. 3B is a schematic diagram of another user account management interface, and fig. 3C is a schematic diagram of another user account management interface.
The affiliate may provide the user with a user account management interface as shown in fig. 3A, 3B, and 3C. The user may view account balances, transaction totals for all funds purchased by the user, and information regarding various funds through the user account management interface, including: fund names, issuing agencies, annual rates of return, total amount traded, details of trades (e.g., time traded, amount traded, etc.), etc.; the total transaction amount of all funds purchased by the user is the total transaction amount maintained by the main account of the user, and the total transaction amount of a certain fund purchased by the user is the total transaction amount maintained by the sub-account corresponding to the fund.
Taking the user account management interface shown in fig. 3A as an example, under the user account of the user, the total transaction amount maintained by the sub-account 1 corresponding to the fund X is 1 ten thousand yuan, the total transaction amount maintained by the sub-account 2 corresponding to the fund Y is 2 ten thousand yuan, and the total transaction amount maintained by the main account is 3 ten thousand yuan. That is, the user purchases 1 ten thousand dollar fund X and 2 ten thousand dollar fund Y, and the total transaction amount of all the funds purchased by the user is 3 ten thousand dollars. In addition, the account balance of the user account of the user is 2 ten thousand yuan.
In the case indicated in fig. 3A, assuming that the user purchases 1 ten thousand dollars of fund Y, the affiliate service may update the total transaction amount maintained by the sub-account 1 to 3 ten thousand dollars after the sub-account 1 passes the verification, and update the total transaction amount maintained by the main account to 4 ten thousand dollars after the main account passes the verification, as shown in fig. 3B. In addition, the affiliate service end can update the account balance of the user account of the user to 1 ten thousand yuan.
Similar to the fund subscription process described above, a user may select a fund that is no longer needed for redemption via the user account management interface, i.e., a certain amount of money is returned to the user by the fund issuer, thereby causing the user to withdraw from investment in the equivalent fund.
In the related art, a user may initiate a redemption request for a fund presented therein through the user account management interface displayed on the user client, and the redemption request is sent by the user client to a affiliate server. For example, the user may click on a "redemption" button corresponding to a fund purchase record under a sub-account in the user account management interface corresponding to the fund; the user client, upon detecting a click operation on the "redemption" button, may construct a redemption request including the transaction amount (i.e., redemption amount) in the fund purchase record, the primary account identification of the user's primary account, and the sub-account identification of the sub-account corresponding to the fund, and send the redemption request to the affiliate server.
When the redemption request is received by the service end of the affiliate, on one hand, a sub-account of the user corresponding to the fund can be frozen and verified, after the sub-account is verified, the sub-account is unfrozen, the redemption amount in the redemption request is deducted from the total transaction amount maintained by the sub-account, meanwhile, the main account of the user is frozen and verified, after the main account is verified, the main account is unfrozen and the redemption amount is deducted from the total transaction amount maintained by the main account; alternatively, a transfer may be made from the issuer of the fund to the user account of the user at a financial institution account opened at the vouching institution based on the redemption amount.
In the case indicated in fig. 3B, assuming that the user redeems 1 ten thousand dollars of funds X, the affiliate service may update the total amount of transactions maintained by sub-account 1 to 0 after sub-account 1 is verified, and update the total amount of transactions maintained by the main account to 3 ten thousand dollars after the main account is verified, as shown in fig. 3C. In addition, the affiliate service end can update the account balance of the user account of the user to 2 ten thousand yuan.
In the related art, the affiliate needs to inform the user that the transaction is successful after the update of the transaction total maintained by the sub-account and the main account of the user, respectively, is completed. In this case, the duration of the transaction is longer, i.e., the time required for the user to confirm the transaction was successful is longer, and the user experience is poor.
In order to shorten the duration of a transaction and improve user experience, the present specification provides a technical solution for performing synchronous transaction processing based on a main account in a user account of a user and performing asynchronous transaction processing based on a sub account in the user account of the user.
In particular implementations, a user may initiate a transaction request via a user client, where the transaction request may include a transaction amount, and a primary account identification (e.g., a primary account number) of a primary account of the user and a sub-account identification (e.g., a sub-account number) of a sub-account.
The user client may send the transaction request to the affiliate server. The affiliate service end can respond to the transaction request and verify a main account corresponding to the main account identification and a sub account corresponding to the sub account identification.
If the main account and the sub-account both pass the verification, the service end of the affiliate can perform synchronous transaction processing based on the main account, that is, synchronously update the total transaction amount maintained by the main account based on the transaction amount in the transaction request, and perform asynchronous transaction processing based on the sub-account, that is, asynchronously update the total transaction amount maintained by the sub-account based on the transaction amount.
And when the synchronous updating of the main account is completed, the affiliate service end can send a notification message that the transaction is successful to the user client. The user client can inform the user of successful transaction by outputting prompt words or outputting acousto-optic signals and the like.
In the above technical solution, on one hand, when a transaction request initiated by a user and including a main account identifier and a sub-account identifier of the user is received, a main account corresponding to the main account identifier in the transaction request and a sub-account corresponding to the sub-account identifier in the transaction request are checked, and when both the main account and the sub-account pass the check, a total transaction amount maintained by the main account is updated synchronously based on a transaction amount in the transaction request, that is, the main account is updated immediately, and a total transaction amount maintained by the sub-account is updated asynchronously based on the transaction amount, that is, the sub-account is updated at any subsequent time. Because the verification of the sub-account is completed in advance, the sub-account can be directly updated subsequently without verifying the sub-account, and thus the success rate of asynchronous updating of the sub-account can be ensured.
On the other hand, when the synchronous updating of the primary account is completed, the user can be informed that the transaction is successful. By adopting the mode, compared with the mode that the user needs to be informed of the successful transaction after the update of the sub-account and the main account is completed in the related technology, the synchronous update of the sub-account can be avoided, so that the transaction duration can be shortened, and the user experience can be improved.
Referring to fig. 4, fig. 4 is a flowchart illustrating a transaction processing method based on a main sub-account according to an exemplary embodiment of the present disclosure.
The transaction processing method based on the main and sub accounts can be applied to the affiliate service end shown in FIG. 1, and comprises the following steps:
In this embodiment, as described in conjunction with fig. 1, the user account opened by the user at the affiliate may include a primary account and a plurality of sub-accounts; wherein the total transaction amount maintained by the main account is the sum of the total transaction amounts maintained by the sub-accounts respectively.
A user can initiate a transaction request aiming at one or more securities through a user client, and the user client sends the transaction request to a service end of an agency.
Specifically, the transaction request corresponds to an operation performed by the user on the securities. For example, assuming that the user performs a purchase operation on the securities, the transaction request may be a purchase request of the securities; assuming that the user performed a redemption operation on the value document, the transaction request may be a redemption request for the value document.
The transaction request may include a transaction amount corresponding to the securities, and a main account identifier (e.g., a main account number) of the main account of the user and a sub-account identifier (e.g., a sub-account number) of the sub-account of the user. Note that the sub-account is a sub-account corresponding to the securities.
When receiving the transaction request, the broker service end may, in response to the transaction request, first determine a corresponding main account and a corresponding sub-account based on the main account identifier and the sub-account identifier in the transaction request. Subsequently, the affiliate service end can verify the main account and the sub-account.
In practical application, the service end of the affiliate can carry out conventional verification processes such as transaction amount verification, transaction deadline verification and the like on the main account and the sub-account.
Taking the transaction request as a purchase request of securities as an example, the transaction amount check performed on the main account and the sub-account may be to check whether the transaction amount in the transaction request is smaller than the current saleable amount of the securities corresponding to the sub-account. If the transaction amount is less than the saleable amount, the service end of the agency can determine that the transaction amount of the main account and the sub account passes the verification.
The transaction term check performed on the main account and the sub-account may be to check whether or not the time when the transaction request is received is earlier than the latest selling time of the securities corresponding to the sub-account. If the time of receiving the transaction request is earlier than the latest selling time, the affiliate service end can determine that the transaction duration check of the main account and the sub account is passed.
For example, if the transaction request is a redemption request of securities, the transaction amount check performed on the main account and the sub-account may be to check whether the transaction amount in the transaction request is less than the total transaction amount maintained by the main account or the sub-account. If the transaction amount is less than the transaction total amount, the service end of the affiliate can determine that the transaction amount of the main account and the sub account passes the verification.
The transaction term check for the main account and the sub-account may be to check whether a time interval between the time of purchasing securities corresponding to the above-mentioned sub-account and the time of receiving the transaction request is earlier than a time interval for allowing redemption. If the time interval between the time of purchasing the securities and the time of receiving the transaction request is earlier than the time interval of allowing redemption, the agency service end can determine that the transaction term check of the main account and the sub-account is passed.
When all verification processes performed on the main account and the sub-account are successfully completed, the service end of the affiliate can determine that the main account and the sub-account are verified, so that the total transaction amount maintained by the main account can be synchronously updated based on the transaction amount in the transaction request, and the total transaction amount maintained by the sub-account can be asynchronously updated based on the transaction amount.
Specifically, on one hand, the service end of the affiliate can immediately update the transaction total amount maintained by the main account based on the transaction amount when the main account and the sub-account are determined to pass verification, so as to realize synchronous update of the main account; on the other hand, the service end of the affiliate can update the transaction total amount maintained by the sub-account based on the transaction amount at any time after the main account and the sub-account are determined to pass the verification, so as to realize asynchronous update of the sub-account.
It should be noted that, based on the transaction amount, updating the transaction total maintained by the primary account or the sub-account may include: adding the transaction amount to the transaction total; deducting the transaction amount from the transaction total; freezing the fund that is equivalent to the transaction amount and marking the transaction amount as frozen in the transaction total; and so on. The updating of the transaction total may also include other ways according to the actual situation, which is not limited in this specification.
In this case, when the synchronous update of the primary account is successfully completed, the affiliate service end may send a transaction success notification message to the user client, so that the user client notifies the user of the successful transaction by outputting prompt text or outputting an audible and visual signal.
Accordingly, in an embodiment shown, when any one of all verification processes performed on the primary account is not successfully completed, the affiliate service end may determine that the primary account fails to be verified; similarly, when any one of all verification processes performed on the sub-account is not completed successfully, the affiliate service end may determine that the sub-account is not verified. If the service end of the affiliate determines that the verification of the main account or the sub-account is not passed, a notification message of transaction failure can be sent to the user client, so that the user client informs the user of the transaction failure by outputting prompt words or outputting sound and light signals and the like.
In practical application, for transaction scenarios such as fund subscription and fund redemption, the total transaction amount is generally required to be updated in the transaction scenarios and the user is required to be informed when the transaction is successful, so that the total transaction amount maintained by the main account of the user can be updated synchronously, and the total transaction amount maintained by the sub-account of the user can be updated asynchronously, so that the duration of the transaction is shortened; for trading scenarios such as fund freezing and fund profit allocation, the user does not need to be informed whether the trading is successful or not in these trading scenarios, so that the total trading amount maintained by the main account and the sub-account of the user respectively can be updated synchronously.
In one illustrated embodiment, an asynchronous transaction scenario may be preset by a technician of the affiliate, which may include: a fund subscription scenario, a fund redemption scenario, etc.
Before updating the transaction total amount maintained by the user account, the affiliate service end may determine whether the transaction scenario corresponding to the transaction request hits the asynchronous transaction scenario.
Specifically, the transaction request may further include identification information for indicating a transaction scenario, where the identification information for indicating a transaction scenario may be different transaction scenario identifications set for different transaction scenarios, or may be unique attribute information of the transaction scenario. The affiliate server can determine a transaction scenario corresponding to the transaction request based on the identification information indicating the transaction scenario in the transaction request.
If the transaction scenario corresponding to the transaction request hits the asynchronous transaction scenario, and the service end of the affiliate determines that both the main account and the sub-account pass verification, the service end of the affiliate can further synchronously update the total transaction amount maintained by the main account based on the transaction amount in the transaction request, and asynchronously update the total transaction amount maintained by the sub-account based on the transaction amount.
It should be noted that there is no explicit timing relationship between the process of verifying the main account and the sub account by the affiliate service end and the process of determining whether the transaction scenario corresponding to the transaction request hits the asynchronous transaction scenario.
Accordingly, in an illustrated embodiment, if the transaction scenario corresponding to the transaction request does not hit the asynchronous transaction scenario, and the affiliate service determines that both the main account and the sub-account pass verification, the affiliate service may synchronously update the transaction total amount respectively maintained by the main account and the sub-account based on the transaction amount in the transaction request, that is, immediately update the transaction total amount respectively maintained by the main account and the sub-account based on the transaction amount when it is determined that both the main account and the sub-account pass verification.
In this case, when the synchronous update of the main account and the sub account is successfully completed, the affiliate service end needs to send a transaction success notification message to the user client, so that the user client informs the user of the successful transaction by outputting prompt words or outputting audible and visual signals.
In the above technical solution, on one hand, when a transaction request initiated by a user and including a main account identifier and a sub-account identifier of the user is received, a main account corresponding to the main account identifier in the transaction request and a sub-account corresponding to the sub-account identifier in the transaction request are checked, and when both the main account and the sub-account pass the check, a total transaction amount maintained by the main account is updated synchronously based on a transaction amount in the transaction request, that is, the main account is updated immediately, and a total transaction amount maintained by the sub-account is updated asynchronously based on the transaction amount, that is, the sub-account is updated at any subsequent time. Because the verification of the sub-account is completed in advance, the sub-account can be directly updated subsequently without verifying the sub-account, and thus the success rate of asynchronous updating of the sub-account can be ensured.
On the other hand, when the synchronous updating of the primary account is completed, the user can be informed that the transaction is successful. By adopting the mode, compared with the mode that the user needs to be informed of the successful transaction after the update of the sub-account and the main account is completed in the related technology, the synchronous update of the sub-account can be avoided, so that the transaction duration can be shortened, and the user experience can be improved.
Corresponding to the embodiment of the transaction processing method based on the main sub-account, the specification also provides an embodiment of a transaction processing device based on the main sub-account.
The embodiment of the transaction processing device based on the main sub-account can be applied to the electronic equipment. The device embodiments may be implemented by software, or by hardware, or by a combination of hardware and software. Taking a software implementation as an example, as a logical device, the device is formed by reading, by a processor of the electronic device where the device is located, a corresponding computer program instruction in the nonvolatile memory into the memory for operation. From a hardware aspect, as shown in fig. 5, the hardware structure diagram of the electronic device where the transaction processing apparatus based on the main and sub accounts is located in this specification is shown, except for the processor, the memory, the network interface, and the nonvolatile memory shown in fig. 5, the electronic device where the apparatus is located in the embodiment may also include other hardware according to an actual function of the transaction processing based on the main and sub accounts, which is not described again.
Referring to fig. 6, fig. 6 is a block diagram of a transaction processing device based on a main sub-account according to an exemplary embodiment of the present disclosure. The main sub-account based transaction processing arrangement 60 may be applied to the electronic device shown in fig. 5; the user account comprises a main account and a plurality of sub-accounts, and the transaction total amount maintained by the main account is the sum of the transaction total amounts respectively maintained by the sub-accounts; the main sub-account based transaction processing device 60 may include:
the receiving module 601 is used for receiving a transaction request initiated by a user through a client; the transaction request comprises a transaction amount, a main account identifier of a main account of the user and a sub-account identifier of a sub-account;
the verification module 602 is configured to verify a main account corresponding to the main account identifier and a sub account corresponding to the sub account identifier in response to the transaction request;
a first updating module 603, configured to, if both the main account and the sub-account pass the verification, synchronously update the total transaction amount maintained by the main account based on the transaction amount, and asynchronously update the total transaction amount maintained by the sub-account based on the transaction amount;
the first notification module 604 sends a notification message that the transaction is successful to the client if the synchronization update of the primary account is completed.
In this embodiment, the apparatus 60 may further include:
and a second notification module 605, configured to send a notification message that the transaction fails to be performed to the client if the primary account or the sub-account is not verified.
In this embodiment, the apparatus 60 may further include:
a determining module 606, configured to perform synchronous update on the transaction total amount maintained by the main account based on the transaction amount, and determine whether a transaction scenario corresponding to the transaction request hits a preset asynchronous transaction scenario before performing asynchronous update on the transaction total amount maintained by the sub-account based on the transaction amount;
the first update module 603:
and if the transaction scene hits the asynchronous transaction scene and the main account and the sub-account are verified to pass, synchronously updating the transaction total amount maintained by the main account based on the transaction amount, and asynchronously updating the transaction total amount maintained by the sub-account based on the transaction amount.
In this embodiment, the apparatus 60 may further include:
a second updating module 607, configured to, if the transaction scenario is not hit in the asynchronous transaction scenario and both the main account and the sub-account pass verification, synchronously update the transaction total amount respectively maintained by the main account and the sub-account based on the transaction amount;
the third notification module 608, if the synchronous update of the main account and the sub account is completed, sends a notification message that the transaction is successful to the client.
In this embodiment, the preset asynchronous transaction scenario may include: a fund subscription scenario, a fund redemption scenario.
The implementation process of the functions and actions of each module in the above device is specifically described in the implementation process of the corresponding step in the above method, and is not described herein again.
For the device embodiments, since they substantially correspond to the method embodiments, reference may be made to the partial description of the method embodiments for relevant points. The above-described embodiments of the apparatus are merely illustrative, wherein the modules described as separate parts may or may not be physically separate, and the parts displayed as modules may or may not be physical modules, may be located in one place, or may be distributed on a plurality of network modules. Some or all of the modules can be selected according to actual needs to achieve the purpose of the solution in the specification. One of ordinary skill in the art can understand and implement it without inventive effort.
The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. A typical implementation device is a computer, which may take the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email messaging device, game console, tablet computer, wearable device, or a combination of any of these devices.
In a typical configuration, a computer includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
Computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic disk storage, quantum memory, graphene-based storage media or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.
It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other like elements in a process, method, article, or apparatus that comprises the element.
The foregoing description has been directed to specific embodiments of this disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims may be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing may also be possible or may be advantageous.
The terminology used in the description of the one or more embodiments is for the purpose of describing the particular embodiments only and is not intended to be limiting of the description of the one or more embodiments. As used in one or more embodiments of the present specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in one or more embodiments of the present description to describe various information, such information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, first information may also be referred to as second information, and similarly, second information may also be referred to as first information, without departing from the scope of one or more embodiments herein. The word "if" as used herein may be interpreted as "at … …" or "when … …" or "in response to a determination", depending on the context.
The above description is only for the purpose of illustrating the preferred embodiments of the one or more embodiments of the present disclosure, and is not intended to limit the scope of the one or more embodiments of the present disclosure, and any modifications, equivalent substitutions, improvements, etc. made within the spirit and principle of the one or more embodiments of the present disclosure should be included in the scope of the one or more embodiments of the present disclosure.
Claims (12)
1. A transaction processing method based on a main sub-account; the user account comprises a main account and a plurality of sub-accounts, and the transaction total amount maintained by the main account is the sum of the transaction total amounts respectively maintained by the sub-accounts; the method comprises the following steps:
receiving a transaction request initiated by a user through a client; the transaction request comprises a transaction amount, a main account identifier of a main account of the user and a sub-account identifier of a sub-account;
in response to the transaction request, verifying a main account corresponding to the main account identification and a sub-account corresponding to the sub-account identification;
if the main account and the sub-account pass the verification, synchronously updating the transaction total amount maintained by the main account based on the transaction amount, and asynchronously updating the transaction total amount maintained by the sub-account based on the transaction amount;
and if the synchronous updating of the primary account is completed, sending a notification message of successful transaction to the client.
2. The method of claim 1, further comprising:
and if the verification of the main account or the sub account is not passed, sending a notification message of transaction failure to the client.
3. The method of claim 1, prior to the synchronously updating the transaction total maintained by the primary account based on the transaction amount and asynchronously updating the transaction total maintained by the secondary account based on the transaction amount, the method further comprising:
determining whether a transaction scene corresponding to the transaction request hits a preset asynchronous transaction scene;
and if the transaction scene hits the asynchronous transaction scene and the main account and the sub-account are verified to pass, synchronously updating the transaction total amount maintained by the main account based on the transaction amount, and asynchronously updating the transaction total amount maintained by the sub-account based on the transaction amount.
4. The method of claim 3, further comprising:
if the transaction scene is not hit in the asynchronous transaction scene, and the main account and the sub-account are verified to pass, synchronously updating the transaction total amount respectively maintained by the main account and the sub-account based on the transaction amount;
and if the synchronous updating of the main account and the sub account is finished, sending a notification message of successful transaction to the client.
5. The method of claim 1, the preset asynchronous transaction scenario comprising: a fund subscription scenario, a fund redemption scenario.
6. A transaction processing device based on a primary sub-account; the user account comprises a main account and a plurality of sub-accounts, and the transaction total amount maintained by the main account is the sum of the transaction total amounts respectively maintained by the sub-accounts; the device comprises:
the receiving module is used for receiving a transaction request initiated by a user through a client; the transaction request comprises a transaction amount, a main account identifier of a main account of the user and a sub-account identifier of a sub-account;
the verification module is used for responding to the transaction request and verifying a main account corresponding to the main account identification and a sub account corresponding to the sub account identification;
the first updating module is used for synchronously updating the transaction total amount maintained by the main account based on the transaction amount and asynchronously updating the transaction total amount maintained by the sub account based on the transaction amount if the main account and the sub account are verified to pass;
and the first notification module is used for sending a notification message of successful transaction to the client if the synchronous updating of the primary account is completed.
7. The apparatus of claim 6, the apparatus further comprising:
and the second notification module is used for sending a notification message of transaction failure to the client if the verification of the main account or the sub-account is not passed.
8. The apparatus of claim 6, the apparatus further comprising:
the determining module is used for synchronously updating the transaction total amount maintained by the main account based on the transaction amount, and determining whether a transaction scene corresponding to the transaction request hits a preset asynchronous transaction scene before asynchronously updating the transaction total amount maintained by the sub-account based on the transaction amount;
the first update module:
and if the transaction scene hits the asynchronous transaction scene and the main account and the sub-account are verified to pass, synchronously updating the transaction total amount maintained by the main account based on the transaction amount, and asynchronously updating the transaction total amount maintained by the sub-account based on the transaction amount.
9. The apparatus of claim 8, the apparatus further comprising:
the second updating module is used for synchronously updating the transaction total amount respectively maintained by the main account and the sub-account based on the transaction amount if the transaction scene is not hit in the asynchronous transaction scene and the main account and the sub-account are verified;
and the third notification module is used for sending a notification message of successful transaction to the client if the synchronous updating of the main account and the sub account is completed.
10. The apparatus of claim 1, the preset asynchronous transaction scenario comprising: a fund subscription scenario, a fund redemption scenario.
11. An electronic device, comprising:
a processor;
a memory for storing processor-executable instructions;
wherein the processor implements the method of any one of claims 1 to 5 by executing the executable instructions.
12. A computer readable storage medium having stored thereon computer instructions which, when executed by a processor, carry out the steps of the method according to any one of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911096829.5A CN110942393B (en) | 2019-11-11 | 2019-11-11 | Transaction processing method and device based on main account and sub account, and electronic equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911096829.5A CN110942393B (en) | 2019-11-11 | 2019-11-11 | Transaction processing method and device based on main account and sub account, and electronic equipment |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110942393A true CN110942393A (en) | 2020-03-31 |
| CN110942393B CN110942393B (en) | 2023-08-15 |
Family
ID=69907675
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911096829.5A Active CN110942393B (en) | 2019-11-11 | 2019-11-11 | Transaction processing method and device based on main account and sub account, and electronic equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110942393B (en) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111461692A (en) * | 2020-04-17 | 2020-07-28 | 支付宝(杭州)信息技术有限公司 | Data processing method and device |
| CN111866171A (en) * | 2020-07-30 | 2020-10-30 | 中国工商银行股份有限公司 | Message processing method and device, electronic equipment and medium |
| CN112464204A (en) * | 2020-11-27 | 2021-03-09 | 深圳市富途网络科技有限公司 | Account management method and related product |
Citations (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20020138375A1 (en) * | 2001-03-22 | 2002-09-26 | International Business Machines Corporation | System and method for synchronizing ledger accounts by company group |
| US20050071194A1 (en) * | 2003-09-30 | 2005-03-31 | Bormann Daniel S. | System and method for providing patient record synchronization in a healthcare setting |
| US7117172B1 (en) * | 1999-03-11 | 2006-10-03 | Corecard Software, Inc. | Methods and systems for managing financial accounts |
| CN101419699A (en) * | 2008-12-04 | 2009-04-29 | 中国工商银行股份有限公司 | Dynamic monitoring method and device for cash deposit data of bank |
| US20120109917A1 (en) * | 2010-10-27 | 2012-05-03 | Comeau Gregory P | System and method for synchronously updating a hierarchy bridge table |
| CN105743970A (en) * | 2015-12-31 | 2016-07-06 | 武汉传神信息技术有限公司 | Asynchronous data synchronization method for distributed systems |
| CN106469412A (en) * | 2015-08-17 | 2017-03-01 | 阿里巴巴集团控股有限公司 | Data processing method and device |
| CN106934025A (en) * | 2017-03-13 | 2017-07-07 | 广州爱九游信息技术有限公司 | A kind of account data management method, device and server |
| CN107230092A (en) * | 2016-03-24 | 2017-10-03 | 阿里巴巴集团控股有限公司 | Accounting processing method, device and server |
| CN107274162A (en) * | 2017-05-31 | 2017-10-20 | 深圳市长亮科技股份有限公司 | A kind of processing method of high transaction concurrency |
| US20180005229A1 (en) * | 2016-06-30 | 2018-01-04 | Square, Inc. | Physical, logical separation of balances of funds |
| CN108319691A (en) * | 2018-02-01 | 2018-07-24 | 宝付网络科技（上海）有限公司 | A kind of bookkeeping methods, billing and accounting system and payment system |
| CN109299222A (en) * | 2018-09-29 | 2019-02-01 | 阿里巴巴集团控股有限公司 | Verification of data method and device |
| CN109933593A (en) * | 2019-01-28 | 2019-06-25 | 阿里巴巴集团控股有限公司 | Asset data record method, device and equipment |
-
2019
- 2019-11-11 CN CN201911096829.5A patent/CN110942393B/en active Active
Patent Citations (14)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7117172B1 (en) * | 1999-03-11 | 2006-10-03 | Corecard Software, Inc. | Methods and systems for managing financial accounts |
| US20020138375A1 (en) * | 2001-03-22 | 2002-09-26 | International Business Machines Corporation | System and method for synchronizing ledger accounts by company group |
| US20050071194A1 (en) * | 2003-09-30 | 2005-03-31 | Bormann Daniel S. | System and method for providing patient record synchronization in a healthcare setting |
| CN101419699A (en) * | 2008-12-04 | 2009-04-29 | 中国工商银行股份有限公司 | Dynamic monitoring method and device for cash deposit data of bank |
| US20120109917A1 (en) * | 2010-10-27 | 2012-05-03 | Comeau Gregory P | System and method for synchronously updating a hierarchy bridge table |
| CN106469412A (en) * | 2015-08-17 | 2017-03-01 | 阿里巴巴集团控股有限公司 | Data processing method and device |
| CN105743970A (en) * | 2015-12-31 | 2016-07-06 | 武汉传神信息技术有限公司 | Asynchronous data synchronization method for distributed systems |
| CN107230092A (en) * | 2016-03-24 | 2017-10-03 | 阿里巴巴集团控股有限公司 | Accounting processing method, device and server |
| US20180005229A1 (en) * | 2016-06-30 | 2018-01-04 | Square, Inc. | Physical, logical separation of balances of funds |
| CN106934025A (en) * | 2017-03-13 | 2017-07-07 | 广州爱九游信息技术有限公司 | A kind of account data management method, device and server |
| CN107274162A (en) * | 2017-05-31 | 2017-10-20 | 深圳市长亮科技股份有限公司 | A kind of processing method of high transaction concurrency |
| CN108319691A (en) * | 2018-02-01 | 2018-07-24 | 宝付网络科技（上海）有限公司 | A kind of bookkeeping methods, billing and accounting system and payment system |
| CN109299222A (en) * | 2018-09-29 | 2019-02-01 | 阿里巴巴集团控股有限公司 | Verification of data method and device |
| CN109933593A (en) * | 2019-01-28 | 2019-06-25 | 阿里巴巴集团控股有限公司 | Asset data record method, device and equipment |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111461692A (en) * | 2020-04-17 | 2020-07-28 | 支付宝(杭州)信息技术有限公司 | Data processing method and device |
| CN111866171A (en) * | 2020-07-30 | 2020-10-30 | 中国工商银行股份有限公司 | Message processing method and device, electronic equipment and medium |
| CN111866171B (en) * | 2020-07-30 | 2023-08-22 | 中国工商银行股份有限公司 | Message processing method, device, electronic equipment and medium |
| CN112464204A (en) * | 2020-11-27 | 2021-03-09 | 深圳市富途网络科技有限公司 | Account management method and related product |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110942393B (en) | 2023-08-15 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7702584B2 (en) | Method and system to facilitate a payment in satisfaction of accumulated micropayment commitments to a vendor | |
| US20190164221A1 (en) | Incrementally Perfected Digital Asset Collateral Wallet | |
| US20150112781A1 (en) | Method and System for Processing of a Real-Time Rebate at Transaction Authorization | |
| AU2019257460A1 (en) | Method and system for processing of a real-time rebate at transaction authorization | |
| CN110942393B (en) | Transaction processing method and device based on main account and sub account, and electronic equipment | |
| US10332205B1 (en) | Bitcoin kiosk/ATM device and system and method of using the same | |
| US20150095206A1 (en) | Systems and methods for providing transaction completion alerts | |
| CN110852747B (en) | Order reconciliation system, method and device | |
| JP2017528822A (en) | Method and system for processing real-time rebate in transaction authorization | |
| US20120303519A1 (en) | User input of consumer spending transaction data for savings and donations programs | |
| US20230162196A1 (en) | Secure multi-factor tokenization-based sub-cryptocurrency payment platform | |
| US20190213679A1 (en) | System to effect cross-border payment | |
| CN113298512A (en) | Capital data information processing method and device and electronic equipment | |
| US11979402B2 (en) | Method, apparatus and computer program product for exchanging messages across a network | |
| WO2016032519A1 (en) | Before-the-fact budgeting | |
| CN114663240A (en) | Asset transaction data processing method and device | |
| US20190325438A1 (en) | System and method for completing a transaction initiated at a payment terminal | |
| US20200364784A1 (en) | System, Method, and Apparatus for Providing a Closed End Credit Account Associated with a Debit Account | |
| US11551175B1 (en) | Facilitating shareholder voting and associated proxy rights | |
| US20220327591A1 (en) | Automatically determining an acquisition threshold for an exchange item | |
| EP4390825A1 (en) | Method of allowing selectable currency within an account | |
| US20230222424A1 (en) | Facilitating shareholder voting and associated proxy rights | |
| US20220414790A1 (en) | Automatic tax account management | |
| JP6457131B1 (en) | Information processing apparatus, information processing method, and program | |
| KR20230105567A (en) | Method for using nft according to loan, device and recording medium for the same |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 40026778 Country of ref document: HK |
|
| GR01 | Patent grant | ||
| GR01 | Patent grant |