A method, device and equipment for managing shared accounts

Abstract

The embodiments of this specification disclose a method, device and equipment for managing a shared account. The scheme includes: receiving a request for a second user to join the shared account, wherein the first user corresponds to the first account, the second user corresponds to the second account, and the second user and the first user have a family relationship; when the medical insurance attributes of the second account and the first account are consistent, establishing an association relationship between the second user and the shared account, wherein the medical insurance attributes are used to characterize the medical insurance type and the medical insurance settlement location. The first user can create a shared account, and associate a second user with actual medical needs among family members to the shared account, establish a mutual assistance relationship in medical insurance among family members, and thus reduce the burden of medical expenses on the family unit.

Description

Technical Field

[0001] The present invention relates to the field of Internet technology, and in particular to a management method, device and equipment based on a shared account. Background Art

[0002] Medical insurance is a social insurance system established to reduce the disease risk of workers. Through the payment of employers and individuals, a medical insurance fund is established. After the user incurs medical expenses, the medical insurance agency will provide certain financial compensation to avoid or reduce the economic risks of workers. Current medical insurance is usually settled and compensated based on each user's personal account.

[0003] Based on this, a shared account management solution with lower risk for family medical burden is needed. Summary of the invention

[0004] One or more embodiments of the present specification provide a shared account management method, apparatus, device, and storage medium to solve the following technical problem: a shared account management solution with lower risk for family medical burden is needed.

[0005] To solve the above technical problems, one or more embodiments of this specification are implemented as follows:

[0006] In a first aspect, one or more embodiments of the present specification provide a shared account management method, which is applied to a shared account pre-created by a first user, the method comprising: receiving a joining request from a second user to join the shared account, wherein the first user corresponds to the first account, the second user corresponds to the second account, and the second user has a family relationship with the first user; when the medical insurance attributes of the second account are consistent with those of the first account, establishing an association relationship between the second user and the shared account, wherein the medical insurance attributes are used to characterize the medical insurance type and the medical insurance settlement location.

[0007] In a second aspect, one or more embodiments of the present specification provide a shared account management device, which is applied to a shared account pre-created by a first user, the device comprising: a receiving module, receiving a joining request from a second user to join the shared account, wherein the first user corresponds to the first account, the second user corresponds to the second account, and the second user has a family relationship with the first user; an establishing module, establishing an association relationship between the second user and the shared account when the medical insurance attributes of the second account are consistent with those of the first account, wherein the medical insurance attributes are used to characterize the medical insurance type and the medical insurance settlement location.

[0008] In a third aspect, one or more embodiments of this specification provide a shared account management device, including:

[0009] at least one processor; and,

[0010] a memory communicatively connected to the at least one processor; wherein,

[0011] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the shared account management method as described in the first aspect.

[0012] In a fourth aspect, one or more embodiments of the present specification provide a non-volatile computer storage medium storing computer executable instructions, wherein the computer executable instructions are configured to: receive a request from a second user to join the shared account, wherein the first user corresponds to the first account, the second user corresponds to the second account, and the second user has a family relationship with the first user; when the medical insurance attributes of the second account are consistent with those of the first account, establish an association relationship between the second user and the shared account, wherein the medical insurance attributes are used to characterize the medical insurance type and the medical insurance settlement location.

[0013] In a fifth aspect, an embodiment of the present specification also provides a payment method, which is applied to a third-party payment platform, and the method includes: receiving a medical insurance payment request regarding a user, wherein the medical insurance payment request is generated by a merchant end scanning a digital object unique identifier of a shared account provided by the user; determining the medical insurance settlement institution corresponding to the shared account, and sending the medical insurance payment request to the medical insurance settlement institution so that the medical insurance accounting structure performs a pre-settlement on the medical insurance payment request; receiving a pre-settlement identifier determined by the medical insurance settlement institution and its corresponding second part of the amount; and paying the second part of the amount corresponding to the pre-settlement identifier according to the payment account associated with the user in the third-party payment platform.

[0014] In a sixth aspect, an embodiment of the present specification also provides a payment device, which is applied to a third-party payment platform, and the device includes: a receiving module, which receives a medical insurance payment request regarding a user, wherein the medical insurance payment request is generated by a merchant end scanning a digital object unique identifier of a shared account provided by the user; a sending module, which determines the medical insurance settlement institution corresponding to the shared account, and sends the medical insurance payment request to the medical insurance settlement institution, so that the medical insurance accounting structure performs a pre-settlement on the medical insurance payment request; the receiving module is also used to receive a pre-settlement identifier determined by the medical insurance settlement institution and its corresponding second part of the amount; a payment module, which pays the second part of the amount corresponding to the pre-settlement identifier according to the payment account associated with the user in the third-party payment platform.

[0015] In the seventh aspect, the embodiments of this specification also provide a payment device, comprising: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute: receiving a medical insurance payment request regarding a user, wherein the medical insurance payment request is generated by a merchant end scanning a digital object unique identifier of a shared account provided by the user; determining the medical insurance settlement institution corresponding to the shared account, and sending the medical insurance payment request to the medical insurance settlement institution so that the medical insurance accounting structure pre-settles the medical insurance payment request; receiving a pre-settlement identifier determined by the medical insurance settlement institution and its corresponding second part of the amount; and paying the second part of the amount corresponding to the pre-settlement identifier according to the payment account associated with the user in the third-party payment platform.

[0016] In an eighth aspect, an embodiment of the present specification also provides a non-volatile computer storage medium storing computer executable instructions, wherein the computer executable instructions are configured to: receive a medical insurance payment request regarding a user, wherein the medical insurance payment request is generated by a merchant end scanning a digital object unique identifier of a shared account provided by a user; determine the medical insurance settlement agency corresponding to the shared account, and send the medical insurance payment request to the medical insurance settlement agency so that the medical insurance accounting structure performs a pre-settlement on the medical insurance payment request; receive a pre-settlement identifier determined by the medical insurance settlement agency and the corresponding second part of the amount; and pay the second part of the amount corresponding to the pre-settlement identifier according to the payment account associated with the user in the third-party payment platform.

[0017] At least one of the above technical solutions adopted in one or more embodiments of this specification can achieve the following beneficial effects: through the shared account pre-created by the first user, the server receives a request for the second user to join the shared account, wherein the first user corresponds to the first account, the second user corresponds to the second account, and the second user has a family relationship with the first user; when the medical insurance attributes of the second account and the first account are consistent, an association relationship between the second user and the shared account is established, wherein the medical insurance attribute is used to characterize the medical insurance type and the medical insurance settlement location. The first user can create a shared account, and associate the second user who has actual medical needs among family members to the shared account, establish a mutual assistance relationship in medical insurance among family members, and thus reduce the burden of medical expenses on the family unit. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] In order to more clearly illustrate the embodiments of this specification or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying creative labor.

[0019] Figure 1 This is a schematic diagram of the architecture of the shared account and the personal account involved in the embodiments of this specification;

[0020] Figure 2 A flowchart of a method for managing a shared account provided in an embodiment of this specification;

[0021] Figure 3 A schematic diagram of a second user joining a shared account provided in an embodiment of this specification;

[0022] Figure 4 A logical diagram of medical insurance payment based on a shared account provided in an embodiment of this specification;

[0023] Figure 5 A schematic diagram of a payment method provided in an embodiment of this specification;

[0024] Figure 6 A schematic diagram of the structure of a shared account management device provided in an embodiment of this specification;

[0025] Figure 7 A schematic diagram of the structure of a payment device provided in an embodiment of this specification;

[0026] Figure 8 A schematic diagram of the structure of a shared account management device provided in an embodiment of this specification. DETAILED DESCRIPTION

[0027] The embodiments of this specification provide a method, apparatus, device and storage medium for managing a shared account.

[0028] In order to enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below in conjunction with the drawings in the embodiments of this specification. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments of this specification, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this specification.

[0029] Medical insurance payment is an important part of basic medical insurance management and deepening medical reform, and is an important lever for regulating medical service behavior and guiding the allocation of medical resources. With the development of medical technology, the improvement of people's economic level, and the enhancement of safety and health awareness of insured persons, medical expenses continue to rise, and more and more people use medical insurance to pay medical expenses. With the rapid development of Internet technology, mobile payment occupies an important position in life. In order to further facilitate people to make medical insurance payments, it is also a trend to transfer medical insurance payments online and complete medical insurance payments directly using mobile phones.

[0030] In the current medical insurance payment, the conventional payment method is basically continued, that is, individuals are used as insurance units to establish personal accounts for medical insurance payment. If a user's parents or children need to pay for medical insurance, they usually cannot use the user's personal account to pay, which actually increases the medical expense burden of the family unit. Based on this, a shared account management solution with lower risk for family medical burden is needed.

[0031] Before managing the shared account, the first user can create a shared account in advance. First of all, it should be noted that in the settlement of medical insurance payment, for the first user, he or she already has a first account for medical payment. At the same time, the shared account is usually independent of the first account. Figure 1 As shown, Figure 1 This is a schematic diagram of the architecture of the shared account and personal account involved in the embodiments of this specification. That is, each user has a corresponding personal account (and the first account, second account, etc. in the diagram), and at the same time, users can create or participate in related shared accounts based on certain conditions, and personal accounts and shared accounts are relatively independent.

[0032] The first user may need to meet the corresponding conditions specified by each medical insurance agency before creating a shared account. For example, the first user may need to meet the following conditions:

[0033] 1. The first user needs to activate the medical insurance electronic certificate on the platform. The medical insurance electronic certificate can be issued uniformly by the National Medical Insurance Bureau information platform and is an electronic medium for medical insurance identity identification generated for all insured persons based on the medical insurance basic information database. The medical insurance electronic certificate has the functions of identity certificate, information record, self-service inquiry, medical insurance settlement, payment and benefit collection, and medical insurance business processing, ensuring that users can enjoy various public services of the medical insurance department efficiently and safely on the Internet. Participants can activate and use it through the Alipay APP, the National Medical Insurance Service APP, or other third-party platforms certified and authorized by the National Medical Insurance Bureau.

[0034] 2. The first user needs to be a person who has participated in a designated type of medical insurance (such as employee medical insurance, urban and rural resident medical insurance, or new rural cooperative medical insurance, etc.) in a designated location (which can be a designated province or a designated city, etc.). For example, the first user may need to be an employee who has participated in the employee medical insurance in xx province.

[0035] 3. There is a certain available balance in the first account of the first user. For example, the available balance in the first account is greater than RMB 200.

[0036] 4. The first user has not joined any shared account.

[0037] Furthermore, different conditions can be set for the first user based on the differences in different places and types of medical insurance to improve the stability of the created shared account. After the first user creates a shared account, the first user can be defaulted as the administrator of the shared account, with corresponding permissions to manage the shared account, such as adding / deleting members, managing account funds, and changing account status.

[0038] like Figure 2 As shown, Figure 2 A flow chart of a method for managing a shared account provided in an embodiment of the present specification is applied to a shared account pre-created by a first user. Figure 2 The process in may include the following steps:

[0039] S201: Receive a joining request from a second user to join the shared account.

[0040] The second user may be a user who has a family relationship with the first user. For example, the second user is a family member of the first user, including a spouse, a parent, or a child.

[0041] The joining request may come from the first user. For example, after creating a shared account, the first user actively selects the second user in the configuration interface of the shared account and sends a joining request containing the identity information of the second user to the platform so that the platform can verify the identity information and family relationship. In this way, the second user does not need to operate, which is suitable for the second user who is elderly or minors who lack the ability to operate mobile phones.

[0042] Alternatively, the joining request may also be sent by the second user. For example, after creating a shared account, the first user sends the account's sharing information (which may be in the form of an invitation link or a QR code, etc.) to the second user. After confirming the source of the information, the second user sends a joining request to the platform through the sharing information (by clicking on the invitation link or scanning the QR code, etc.). In this way, the second user can actively choose to join or not join (i.e., not click on the invitation link) the shared account, which can meet the actual needs of the second user.

[0043] like Figure 3 As shown, Figure 3 A schematic diagram of a second user joining a shared account provided in an embodiment of this specification. In the schematic diagram, the first user creates a shared account after identity verification and invites the second user to join the shared account. After receiving the sharing link of the first user, the second user performs a secondary confirmation and applies to the platform to join the shared account.

[0044] It should be noted that the first account and the second account in this specification generally refer to the user's medical insurance fund account, rather than the payment account in the third-party payment client in the conventional sense.

[0045] S203: When the medical insurance attributes of the second account are consistent with those of the first account, an association relationship between the second user and the shared account is established, wherein the medical insurance attribute is used to characterize the medical insurance type and the medical insurance settlement location.

[0046] Specifically, in addition to verifying the relationship between the second user and the first user, the platform also needs to verify whether the medical insurance attributes of the first account and the second account are consistent. In the embodiment of this specification, the medical insurance attributes of the account include the type of medical insurance participated by the user and the settlement location of the medical insurance participated in, and the medical insurance attributes can also be attributes such as the available balance in the account or the account credit level.

[0047] For example, assuming that the type of medical insurance that the first user participates in and the location where the user participates in the medical insurance are (Province A, first category medical insurance); the type of medical insurance that the second user participates in and the location where the user participates in the medical insurance are (Province A, second category medical insurance), or, the type of medical insurance that the second user participates in and the location where the user participates in the medical insurance are (Province A, not insured), or, the type of medical insurance that the second user participates in and the location where the user participates in the medical insurance are (Province B, first category medical insurance), then the medical insurance attributes of the second account and the first account should be deemed inconsistent, and the association relationship between the second user and the shared account cannot be established.

[0048] Therefore, only when the first user and the second user participate in the same type of medical insurance and the same location of medical insurance participation (Province A, first category medical insurance), can the medical insurance attributes of the second account be considered consistent with those of the first account. This meets the actual medical insurance settlement needs and avoids confusion in medical insurance settlement.

[0049] The first category of medical insurance in this specification can be any type of national basic medical insurance such as urban and rural residents' medical insurance / new rural cooperative medical insurance / employee medical insurance, and the second category of medical insurance can be commercial medical insurance provided by various commercial institutions, etc. The granularity setting of specific categories can be set based on actual needs.

[0050] In other words, assuming that the medical insurance attribute of the first account is (Province A, urban and rural residents' medical insurance) and the medical insurance attribute of the second account is (Province A, New Rural Cooperative Medical Insurance), the medical insurance attributes of the first account and the second account can still be regarded as consistent; or, assuming that the medical insurance attribute of the first account is (Province A, commercial institution 1's Class I medical insurance) and the medical insurance attribute of the second account is (Province A, commercial institution 1's Class J medical insurance), the medical insurance attributes of the first account and the second account can also be regarded as consistent. Of course, in actual needs, other requirements of different granularity can also be given for the consistency of the types of participating medical insurance.

[0051] It should be noted that if the first user and the second user do not have a family relationship (i.e., they are not parents, children, or spouses), then obviously, in actual application scenarios, the two users will usually not join the same shared account. In other words, if the first user and the second user do not have a family relationship, even if the first user and the second user join a shared account at the same time, the effect of reducing the medical expenses burden of the family as a unit in this specification cannot actually be achieved.

[0052] On the other hand, in actual applications, medical insurance is calculated on a local basis for the different types of medical insurance in which each user participates. Therefore, if the medical insurance attributes of the first account and the second account are inconsistent (for example, the provinces in which the two participate are inconsistent, or the types of medical insurance participated in are inconsistent), even if the first user and the second user join a shared account together, it will be impossible to perform medical insurance calculations between the two accounts (i.e., the first account and the second account), and thus the effect of reducing the medical expenses burden on the family unit will not be achieved.

[0053] Through the shared account pre-created by the first user, the server receives a request from the second user to join the shared account, wherein the first user corresponds to the first account, the second user corresponds to the second account, and the second user and the first user have a family relationship; when the medical insurance attributes of the second account and the first account are consistent, an association relationship between the second user and the shared account is established, wherein the medical insurance attribute is used to characterize the medical insurance type and the medical insurance settlement location. The first user creates a shared account, and associates the second user who has actual medical needs among family members to the shared account, and establishes a mutual assistance relationship in medical insurance among family members, thereby reducing the medical expenses burden on the family unit.

[0054] In one embodiment, when establishing the association relationship between the second user and the shared account, more screening conditions may be introduced, specifically, such as:

[0055] A. When the medical insurance attributes of the second account are consistent with those of the first account, and the number of users associated with the shared account does not exceed the preset number, the association relationship between the second user and the shared account is established. For example, the number of users associated with the shared account does not exceed 6. If it exceeds 6, no user can be associated with the shared account, so that the number of people in the shared account matches the actual number of family members.

[0056] B. When the medical insurance attributes of the second account are consistent with those of the first account, and the second user is not associated with other shared accounts, an association relationship between the second user and the shared account is established.

[0057] C. When the medical insurance attributes of the second account are consistent with those of the first account, and the second user has activated the medical insurance electronic certificate in the platform, it is ensured that the second user is a valid insurance account.

[0058] The aforementioned screening conditions can be selected arbitrarily or in combination; and other screening conditions can be introduced based on actual needs. By introducing further screening conditions, it can be ensured that the second user is a valid insurance account, and it can be avoided that the same shared account is associated with too many users, or the same user is associated with too many shared accounts, thereby reducing the difficulty of data supervision.

[0059] In one embodiment, after the second user and the first user are associated with the shared account, there may also be a logout mechanism. Since the first user is usually the default administrator, the shared account may be directly logged out based on the operation of the first user, or the association between a second user and the shared account may be terminated.

[0060] Furthermore, when the user attributes of the first user meet the preset release conditions, the shared account is cancelled and the balance of the shared account is returned to the first account of the first user. The following are several examples of release conditions that may be applied in practice, including:

[0061] Whether the first user retires; or,

[0062] Whether the medical insurance attribute of the first user has changed, for example, the type of medical insurance participated by the first user and the location of medical insurance participated in by the first user have changed from (Province A, urban and rural residents' medical insurance) to (Province B, urban and rural residents' medical insurance); or

[0063] The first user is included in the insured persons of a specified type of disease (including special diseases or chronic diseases) and is no longer suitable for sharing an account; or

[0064] The first user's medical insurance activation certificate is invalid.

[0065] Obviously, it is impossible to list all the specific conditions for release. In practical applications, based on the actual needs of each place, more practical conditions for release can be formulated to meet the different needs of different places.

[0066] In one embodiment, a similar exit mechanism may also exist for the second user. Specifically, a release request from the second user may be received, and the association between the second user and the shared account may be released, so that the second user can exit the shared account autonomously.

[0067] Alternatively, when the medical insurance attributes of the second account are inconsistent with those of the first account, the association between the second user and the shared account is terminated. For example, if the medical insurance attribute of the second user when joining the shared account is (Province A, employee insurance), and then changes to (Province B, employee insurance), then it is obvious that the medical insurance settlement location of the second user is no longer consistent with that of the first user. Therefore, in order to avoid confusion in medical insurance settlement, the platform can directly terminate the association between the second user and the shared account.

[0068] In one embodiment, the balance in the shared account may be empty by default, so that users participating in the shared account are required to transfer money to the shared account so that any participating party can use the medical insurance funds in the shared account.

[0069] In order to avoid a large waste of medical resources, the amount or number of transfers from each account to the shared account can be limited. For example, an amount not exceeding a preset value is transferred from the first account or the second account to the shared account; or, a transfer not exceeding a preset number of times is performed from the first account or the second account to the shared account; or, based on the upper limit of the amount of the shared account, the first account or the second account is transferred to the shared account.

[0070] For example, each first account or second account may be restricted to transfer money to a shared account no more than once a month; or, the single amount of money transferred from each first account or second account may not exceed RMB 2,000; or, the upper limit of the amount in the shared account may be RMB 20,000, and transfers from the first account or second account may not cause the amount in the shared account to exceed this upper limit.

[0071] In one embodiment, users who participate in a shared account (including a first user and a second user, and there may be multiple second users) can make payments for medical insurance funds based on the shared account. For example, a user can show a QR code to a merchant (including a designated hospital or pharmacy, etc.) through a third-party payment platform. The QR code contains the user's identity information and the account information of the shared account associated with the user, so that the merchant can scan the QR code and obtain the relevant information therein to generate a medical insurance payment request, and send it to a third-party payment platform that supports the medical insurance settlement channel. The third-party payment platform connects the medical insurance payment request with the medical insurance settlement agency to complete the subsequent medical insurance settlement.

[0072] When the medical insurance settlement agency receives the medical insurance payment request forwarded by the third-party payment platform, it can first determine the user who sent the medical insurance payment request, and then query the type of medical insurance that the user participates in, so as to determine the reimbursement ratio that the user can pre-settlement, and determine the first part of the amount that can be directly settled in the pre-settlement based on the amount to be paid and the reimbursement ratio. For example, the amount to be paid is 10,000 yuan. According to the settlement details of the user and the local medical insurance reimbursement rules, the proportion of medical insurance pooling reimbursement is 70%. Then the user will first settle 7,000 yuan through the medical insurance pooling, and the remaining 3,000 yuan can be settled and paid through his personal medical insurance account. This 3,000 yuan belongs to the above-mentioned first part of the amount.

[0073] When the balance of the user's corresponding personal medical insurance account is lower than the first part of the amount, the balance of the user's corresponding account will be deducted first, and the insufficient balance will be paid from the shared account. After the payment is completed, the payment information will be displayed to all members in the shared account. Continuing with the previous example, assuming that the balance of the user's corresponding account is 2,000 yuan, which is lower than the first part of the amount of 3,000 yuan, 2,000 yuan will be paid from the user's corresponding account first, and the insufficient balance of 1,000 yuan will be paid from the shared account. Figure 4 As shown, Figure 4 This is a logic diagram of medical insurance payment based on a shared account provided in an embodiment of this specification. Assuming that the current shared account balance is 4,000 yuan, after the payment, the shared account balance becomes 3,000 yuan, and the balance of the account corresponding to the user is 0, so as to achieve the optimal use of medical insurance funds.

[0074] In one embodiment, the payment of the medical insurance payment request may be completed at the medical insurance settlement agency, that is, the first part of the amount is equal to the amount to be paid. However, in actual applications, users are often required to make partial out-of-pocket payments, that is, the second part of the amount in the medical insurance payment request needs to be determined (including the amount that the shared account is insufficient to pay and the amount that needs to be paid based on the type of insurance). Generally speaking, the amount to be paid = the first part of the amount + the second part of the amount.

[0075] At this time, the medical insurance settlement agency needs to generate a pre-settlement identifier for payment of the medical insurance payment request, and associate the pre-settlement identifier with the first part of the amount and the second part of the amount at the same time, and send the pre-settlement identifier and its corresponding second part of the amount to the third-party payment platform, so that the second part of the amount corresponding to the pre-settlement identifier can be paid according to the payment account associated with the user in the third-party payment platform.

[0076] In this way, when users need to make medical insurance payments, even if the medical insurance settlement agency needs to pre-settlement part of the user's account and the user pays the remaining amount at their own expense, the user does not need to perceive or operate these processes. Finally, after the payment is completed, the payment information of the pre-settlement and the user's own payment is displayed to the user respectively, which improves the user experience.

[0077] In addition, a first settlement receipt containing the pre-settlement mark and the payment amount of the medical insurance account (i.e., the payment amount of the account corresponding to the user + the payment amount of the shared account) can be generated at the medical insurance settlement institution, and a second settlement receipt containing the pre-settlement mark and the second part of the amount can be generated in the third-party payment platform. The medical insurance settlement institution can eventually reconcile the medical insurance payment request based on the first settlement receipt and the second settlement receipt.

[0078] Furthermore, when the second user makes a medical insurance payment based on the funds in the shared account, a certain payment condition may be set. Specifically, the preset payment condition may be that the payee in the medical insurance payment request is an institution type corresponding to the medical insurance type, or that the transaction type in the payment request is a transaction type corresponding to the medical insurance type.

[0079] For example, the institution type corresponding to the medical insurance type can be an outpatient clinic or a designated retail pharmacy of a designated medical institution specified by the medical type; or the transaction type in the medical insurance payment request can be a transaction type such as a designated type of medical expenses incurred in a designated medical institution (including hospitalization, medical equipment or consumables, etc.), and the inoculation of a designated vaccine, etc. In this way, medical insurance payment can be made within the payment scope constrained by the payment conditions, avoiding the abuse of resources in the shared account.

[0080] Furthermore, in one embodiment, the first user can also set a usage limit for the amount in the shared account. For example, a daily limit, a monthly limit, or a single payment limit, etc., is set, so that after receiving the medical insurance payment request, the platform can pay an amount not exceeding the preset limit from the shared account in response to the medical insurance payment request. For example, the first user can set the second user's daily limit to 2,000 yuan, a monthly limit to 20,000 yuan, a single payment limit to 500 yuan, etc. according to the actual needs of the second user, thereby achieving reasonable use of funds in the shared account and avoiding abuse of funds.

[0081] The embodiment of this specification also provides a payment method, which is applied to a third-party payment platform, such as Figure 5 As shown, Figure 5 A schematic diagram of a payment method provided in an embodiment of this specification, the method comprising:

[0082] S501, receiving a medical insurance payment request from a user, wherein the medical insurance payment request is generated by a merchant end scanning a digital object unique identifier of a shared account provided by a user.

[0083] The user may be the first user or the second user associated with the shared account. The relationship between the shared account, the first user and the second user has been described in the previous section and will not be repeated here.

[0084] In actual applications, users can show the digital object unique identifier (including QR code, barcode, unique string, etc.) of their associated shared account to merchants (designated medical institutions, designated pharmacies, etc.) through the client of the third-party payment platform, so that the merchant generates a medical insurance payment request for the user and sends the medical insurance payment request to the third-party payment platform. Obviously, the medical insurance payment request should contain the user identification information, merchant identification information, amount to be paid, shared account identification information, etc. provided by the digital object unique identifier of the shared account, which are necessary for payment.

[0085] S503, determining the medical insurance settlement agency corresponding to the shared account, and sending the medical insurance payment request to the medical insurance settlement agency, so that the medical insurance accounting structure performs preliminary settlement on the medical insurance payment request.

[0086] The third-party payment platform may actually correspond to multiple medical insurance settlement institutions at the same time. Based on this, different coding rules can be pre-defined for the shared accounts of different medical insurance settlement institutions, so that the medical insurance settlement institution corresponding to the shared account can be determined by parsing based on the shared account identification information, or obtaining corresponding information based on the user identification information, and sending the medical insurance payment request to the medical insurance settlement institution so that the medical insurance accounting structure can pre-settlement the medical insurance payment request.

[0087] In this process, the first part of the amount that needs to be pre-settled is first determined, and a pre-settlement identifier is generated. The first part of the amount is paid from the account corresponding to the user in the medical insurance settlement structure. When the balance in the account corresponding to the user in the medical insurance settlement structure is insufficient, the insufficient part is paid from the shared account. When the balance of the shared account cannot fully pay the insufficient part, the insufficient amount of the shared account is included in the second part of the amount. In addition, a first settlement receipt containing the pre-settlement identifier and the amount paid from the medical insurance account can also be generated in the medical insurance settlement institution.

[0088] S505, receiving the pre-settlement identifier determined by the medical insurance settlement agency and its corresponding second part of the amount.

[0089] S507: Pay the second portion of the amount corresponding to the pre-settlement identifier according to the payment account associated with the user in the third-party payment platform.

[0090] This part is the self-paid part. After making the payment of this part, a second settlement receipt containing the pre-settlement mark and the second part amount will usually be generated. The medical insurance settlement agency can eventually reconcile the medical insurance payment request based on the first settlement receipt and the second settlement receipt.

[0091] Through this method, users only need to show the digital object unique identifier of the shared account once to complete the medical insurance pre-settlement and self-payment settlement at the same time. Users do not need to perceive or operate the background settlement process, which improves the user's medical insurance payment experience.

[0092] In order to make the solution of this specification more clear, a specific example is given below.

[0093] User A (first user) and user B (second user) have a family relationship (assuming user B is the mother of user A). Both of them have participated in the relevant basic medical insurance (i.e., the first category of medical insurance) in advance, among which A participated in the employee medical insurance of Province X, and B participated in the resident medical insurance of Province X. And both have activated the medical insurance electronic certificate on the platform, so user A already has a corresponding first account on the platform to pay for his own medical insurance expenses, and user B also has a corresponding second account to pay for his own medical insurance expenses. At the same time, the platform allows users who have participated in employee medical insurance to create and manage shared accounts.

[0094] Based on this, user A can request the platform to create a shared account. The platform will establish the shared account after verifying the relevant identity information, medical insurance information and credential information of user A. User A serves as the default administrator of the shared account.

[0095] Furthermore, user A can submit user B's identity information to the platform through the client to request payment for verification (including verification of B's ​​identity information and verification of the family relationship between A and B), and after the verification is passed, the platform will initiate an invitation link or invitation QR code for user B to join the shared account.

[0096] User B can then click on the received invitation link or invitation QR code to enter the platform's client, and the identity information submitted by user A will be displayed in the client, and user B will perform a second confirmation. After user B confirms that the identity information of user B submitted by user A is correct, he or she can apply to join the shared account through the client. The family relationship between users A and B in the generated shared account is guaranteed through the joint confirmation of both parties.

[0097] The platform can then verify based on user B's application for joining, that is, whether the medical insurance attributes of the first account are consistent with those of the second account. When it is confirmed that the medical insurance attributes of A and B are both the first-class medical insurance in Province X, user B and the shared account are associated.

[0098] Both users A and B can transfer money from their respective medical insurance accounts (i.e., the first account or the second account) to the shared account. As an administrator, user A can limit the amount or number of transfers. In actual applications, there may be situations where users who need to use medical insurance funds do not transfer money. For example, user B needs to use medical insurance funds when he is sick, but does not transfer money to the shared account.

[0099] Furthermore, when user A or B generates a medical insurance payment request, if the payee in the payment request is the institution type corresponding to the medical insurance type, or the transaction type in the payment request is the transaction type corresponding to the medical insurance type, then if the balance in the first account or the second account is insufficient, the insufficient balance can be paid from the shared account, thereby realizing the payment of medical insurance funds on a family basis and reducing the family's medical expenses burden.

[0100] In addition, user B can also choose to exit the shared account according to his own needs, and user A can disassociate other users in the shared account, or invite other second users (for example, user A's father or spouse, etc.) to join the shared account.

[0101] Furthermore, when the medical insurance attributes of user B change and are no longer consistent with those of user A, the platform can automatically cancel the association between user B and the shared account. When the user attributes of the first user meet the preset cancellation conditions (including user A's retirement, changes in medical insurance attributes, invalidation of medical insurance electronic certificates, etc.), the platform can automatically cancel the shared account established by user A and return the balance of the shared account to the first account of the first user.

[0102] When medical insurance payment is needed, the user can show the QR code of the shared account associated with the merchant through the client of the third-party payment platform, so that the merchant generates a corresponding medical insurance payment request and sends it to the third-party payment platform.

[0103] The third-party payment platform determines the medical insurance settlement agency corresponding to the payment request and forwards it, so that the medical insurance settlement agency determines the first part of the amount that needs to be pre-settled based on the user's insurance type, and first pays based on the user's account. When the user's account is insufficient to pay the first part of the amount, the shortfall is paid from the shared account. When the balance or limit in the shared account is still insufficient to pay, the remaining shortfall is included in the second part of the amount. At the same time, a first settlement receipt is generated containing the medical insurance account payment amount and the pre-settlement mark.

[0104] For example, assuming the amount to be paid is 20,000, and the reimbursement ratio of the medical insurance pool is 65% based on the user's insurance type, the medical insurance pool reimbursement settlement is 13,000, and the first part of the amount is 7,000 yuan. If the balance in the user's account is 2,000 yuan, the 2,000 yuan will be deducted first, and the remaining 5,000 will be paid from the shared account.

[0105] If the balance in the shared account is insufficient, for example, the balance in the shared account is 3,000, then 3,000 will be paid from the shared account, and the remaining 2,000 will be included in the second part of the amount. Alternatively, if the balance in the shared account is sufficient, but the single payment limit is less than 5,000, for example, the balance in the shared account is 10,000 and the single payment limit is 3,000, then the single limit of 3,000 will be paid from the shared account, and the remaining 2,000 will be included in the second part of the amount. A first settlement receipt containing the medical insurance account payment amount of 5,000 and a pre-settlement mark is generated on the medical insurance settlement agency side.

[0106] Furthermore, the medical insurance settlement agency determines the second amount that needs to be paid out of pocket based on the user's insurance type (including the amount that needs to be paid based on the insurance ratio, and the amount that is insufficient to be paid by the aforementioned shared account, which is 3000+2000=5000 in the previous example), and forwards the second amount and the pre-settlement mark to the third-party payment platform, so that the third-party payment platform can pay the second amount out of pocket based on the payment account associated with the user in the third-party payment platform, and at the same time, generate a second settlement receipt containing the second amount and the pre-settlement mark, which can be returned to the user and the merchant at the same time. The medical insurance settlement agency can finally complete the reconciliation of this medical insurance payment request based on the first settlement receipt and the second settlement receipt.

[0107] Based on the same idea, the embodiments of this specification also provide devices and equipment corresponding to the above method, such as Figure 6 , Figure 7 shown.

[0108] Figure 6 A schematic diagram of a structure of a shared account management device provided in an embodiment of the present specification, which is applied to a shared account pre-created by a first user, and the device includes:

[0109] The receiving module 601 receives a request for a second user to join the shared account, wherein the first user corresponds to the first account, the second user corresponds to the second account, and the second user has a family relationship with the first user;

[0110] Establishing module 603, when the medical insurance attributes of the second account and the first account are consistent, establishing an association relationship between the second user and the shared account, wherein the medical insurance attribute is used to characterize the medical insurance type and the medical insurance settlement location.

[0111] Furthermore, the establishment module 603 establishes an association relationship between the second user and the shared account when the medical insurance attributes of the second account are consistent with those of the first account and the number of users associated with the shared account does not exceed a preset number; or, when the medical insurance attributes of the second account are consistent with those of the first account and the second user is not associated with other shared accounts, establishes an association relationship between the second user and the shared account.

[0112] Furthermore, the device also includes a cancellation module 605, which cancels the shared account when the user attribute of the first user meets the preset release condition; and returns the balance of the shared account to the first account.

[0113] Furthermore, the device also includes a release module 607, which receives a release request from the second user and releases the association between the second user and the shared account; or, when the medical insurance attributes of the second account are inconsistent with those of the first account, releases the association between the second user and the shared account.

[0114] Furthermore, the device also includes a transfer module 609, which transfers an amount not exceeding a preset value from the first account or the second account to the shared account, or performs no more than a preset number of transfers from the first account or the second account to the shared account; or, based on the upper limit of the amount of the shared account, transfers from the first account or the second account to the shared account.

[0115] Furthermore, the device also includes a payment module 611, which receives a medical insurance payment request regarding a user, wherein the user includes the first user or the second user; determines a first portion of the amount to be paid in the medical insurance payment request; and when the balance of the account corresponding to the user is lower than the first portion of the amount, executes payment of the insufficient balance from the shared account.

[0116] Furthermore, the payment module 611 executes payment of the insufficient balance from the shared account when the medical insurance payment request meets preset conditions, and the preset conditions include: the payee in the medical insurance payment request is an institution type corresponding to the medical insurance type, or the transaction type in the payment request is a transaction type corresponding to the medical insurance type.

[0117] Furthermore, the payment module 611 pays an amount not exceeding a preset limit from the shared account in response to the medical insurance payment request.

[0118] Furthermore, the payment module 611 generates a pre-settlement identifier for payment of the medical insurance payment request; determines the second part of the amount corresponding to the pre-settlement identifier; and sends the pre-settlement identifier and its corresponding second part of the amount to a third-party payment platform so that the second part of the amount corresponding to the pre-settlement identifier can be paid according to the payment account associated with the user in the third-party payment platform.

[0119] Figure 7 A schematic diagram of a payment device provided in an embodiment of this specification is applied to a third-party payment platform, and the device includes:

[0120] The receiving module 701 receives a medical insurance payment request from a user, wherein the medical insurance payment request is generated by a merchant end scanning a digital object unique identifier of a shared account provided by the user;

[0121] The sending module 703 determines the medical insurance settlement institution corresponding to the shared account, and sends the medical insurance payment request to the medical insurance settlement institution so that the medical insurance accounting structure performs a preliminary settlement on the medical insurance payment request;

[0122] The receiving module 701 is also used to receive the pre-settlement identifier determined by the medical insurance settlement agency and the corresponding second part of the amount;

[0123] The payment module 705 pays the second portion of the amount corresponding to the pre-settlement identifier according to the payment account associated with the user in the third-party payment platform.

[0124] Figure 8 A schematic diagram of a structure of a shared account management device provided in one or more embodiments of this specification, the device comprising:

[0125] at least one processor; and,

[0126] a memory communicatively connected to the at least one processor; wherein,

[0127] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the following steps: Figure 1 or Figure 5 The method shown.

[0128] Based on the same idea, one or more embodiments of this specification also provide a non-volatile computer storage medium corresponding to the above method, storing computer executable instructions, which can perform the following when executed: Figure 1 or Figure 5 The method shown.

[0129] In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0130] The controller can be implemented in any appropriate manner, for example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) that can be executed by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, the controller can be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be regarded as structures within the hardware component. Or even, the devices for implementing various functions can be regarded as both software modules for implementing the method and structures within the hardware component.

[0131] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smart phone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0132] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0133] Those skilled in the art will appreciate that the embodiments of this specification may be provided as methods, systems, or computer program products. Therefore, the embodiments of this specification may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the embodiments of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program codes.

[0134] This specification is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0135] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0136] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process in the computer or other programmable device. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0137] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0138] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0139] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules 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 disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0140] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0141] This specification may be described in the general context of computer-executable instructions executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform specific tasks or implement specific abstract data types. This specification may also be practiced in distributed computing environments where tasks are performed by remote processing devices connected through a communication network. In a distributed computing environment, program modules may be located in local and remote computer storage media, including storage devices.

[0142] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device, equipment, and non-volatile computer storage medium embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0143] The above is a description of a specific embodiment of the specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0144] The above description is only one or more embodiments of this specification and is not intended to limit this specification. For those skilled in the art, one or more embodiments of this specification may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of one or more embodiments of this specification shall be included in the scope of the claims of this specification.

Claims

1. A method for managing a shared account, applied to a shared account pre-created by a first user, the method comprising: receiving a request for a second user to join the shared account, wherein the first user corresponds to the first account, the second user corresponds to the second account, and the second user has a family relationship with the first user; When the medical insurance attributes of the second account are consistent with those of the first account, an association relationship between the second user and the shared account is established, wherein the medical insurance attributes are used to characterize the medical insurance type and the medical insurance settlement location, and the first account and the second account refer to the user's medical insurance fund account, rather than the payment account in the third-party payment client in the conventional sense.

2. The method of claim 1, wherein: When the medical insurance attributes of the second account are consistent with those of the first account, establishing an association relationship between the second user and the shared account includes: When the medical insurance attributes of the second account are consistent with those of the first account, and the number of users associated with the shared account does not exceed a preset number, an association relationship between the second user and the shared account is established; or, When the medical insurance attributes of the second account are consistent with those of the first account, and the second user is not associated with other shared accounts, an association relationship between the second user and the shared account is established.

3. The method of claim 1, wherein: The method further comprises: When the user attributes of the first user meet the preset release conditions, canceling the shared account; Return the balance of the shared account to the first account.

4. The method of claim 1, wherein: After establishing the association relationship between the second user and the shared account, the method further includes: receiving a release request from the second user, and releasing the association between the second user and the shared account; or, When the medical insurance attributes of the second account are inconsistent with those of the first account, the association between the second user and the shared account is released.

5. The method of claim 1, wherein: The method further comprises: Transferring an amount not exceeding a preset value from the first account or the second account to the shared account; or, Performing a transfer from the first account or the second account to the shared account no more than a preset number of times; or, Based on the upper limit of the amount of the shared account, transfer money from the first account or the second account to the shared account.

6. The method of claim 1, wherein: The method further comprises: receiving a medical insurance payment request for a user, wherein the user includes the first user or the second user; Determine a first portion of the amount to be paid in the medical insurance payment request; when the balance of the account corresponding to the user is lower than the first portion of the amount, pay the shortfall from the shared account.

7. The method of claim 6, wherein: Paying the insufficient balance from the shared account includes: When the medical insurance payment request meets a preset condition, payment of the insufficient balance is performed from the shared account, and the preset condition includes: The payee in the medical insurance payment request is an institution type corresponding to the medical insurance type, or the transaction type in the medical insurance payment request is a transaction type corresponding to the medical insurance type.

8. The method of claim 6, wherein: Paying the insufficient balance from the shared account includes: For payment of the insufficient balance, an amount not exceeding a preset limit is paid from the shared account.

9. The method according to claim 6 or 8, wherein: The method further comprises: Generating a pre-settlement mark for payment of the medical insurance payment request; Determine the second amount corresponding to the pre-settlement identifier; The pre-settlement identifier and the second portion of the amount corresponding to it are sent to a third-party payment platform so that the second portion of the amount corresponding to the pre-settlement identifier can be paid according to the payment account associated with the user in the third-party payment platform.

10. A payment method, applied to a third-party payment platform, comprising: Receive a medical insurance payment request from a user, wherein the medical insurance payment request is generated by a merchant end scanning a digital object unique identifier of a shared account provided by a user, the shared account is pre-created by a first user, an association is established between the shared account and a second user, the first user corresponds to a first account, the second user corresponds to a second account, the second user has a family relationship with the first user, the second account has the same medical insurance attribute as the first account, and the first account and the second account refer to the user's medical insurance fund account, rather than a payment account in a third-party payment client in a conventional sense; Determine the medical insurance settlement institution corresponding to the shared account, and send the medical insurance payment request to the medical insurance settlement institution so that the medical insurance settlement institution performs a preliminary settlement on the medical insurance payment request; Receiving the pre-settlement identifier determined by the medical insurance settlement agency and the corresponding second part of the amount; The second portion of the amount corresponding to the pre-settlement identifier is paid according to the payment account associated with the user in the third-party payment platform.

11. A shared account management device, applied to a shared account pre-created by a first user, the device comprising: a receiving module, receiving a joining request of a second user to join the shared account, wherein the first user corresponds to the first account, the second user corresponds to the second account, and the second user has a family relationship with the first user; Establish a module, when the medical insurance attributes of the second account are consistent with those of the first account, establish an association relationship between the second user and the shared account, wherein the medical insurance attributes are used to characterize the medical insurance type and the medical insurance settlement location, and the first account and the second account refer to the user's medical insurance fund account, rather than the payment account in the third-party payment client in the conventional sense.

12. The device as described in claim 11, wherein the establishment module establishes an association relationship between the second user and the shared account when the medical insurance attributes of the second account are consistent with those of the first account and the number of users associated with the shared account does not exceed a preset number; or, when the medical insurance attributes of the second account are consistent with those of the first account and the second user is not associated with other shared accounts, establishes an association relationship between the second user and the shared account.

13. The device as claimed in claim 11 further comprises a cancellation module, which cancels the shared account when the user attributes of the first user meet a preset release condition; and returns the balance of the shared account to the first account.

14. The device as described in claim 11 further includes a release module, which receives a release request from the second user and releases the association between the second user and the shared account; or, when the medical insurance attributes of the second account are inconsistent with those of the first account, releases the association between the second user and the shared account.

15. The device as claimed in claim 11 further comprises a transfer module, which transfers an amount not exceeding a preset value from the first account or the second account to the shared account, or performs transfers from the first account or the second account to the shared account not exceeding a preset number of times; or transfers from the first account or the second account to the shared account based on an upper limit of the amount of the shared account.

16. The device according to claim 11, further comprising a payment module for receiving a medical insurance payment request of a user, wherein: The user includes the first user or the second user; determining a first part of the amount to be paid in the medical insurance payment request; when the balance of the account corresponding to the user is lower than the first part of the amount, executing payment of the insufficient balance from the shared account.

17. The device of claim 16, wherein the payment module pays the insufficient balance from the shared account when the medical insurance payment request satisfies a preset condition, wherein the preset condition comprises: The payee in the medical insurance payment request is an institution type corresponding to the medical insurance type, or the transaction type in the payment request is a transaction type corresponding to the medical insurance type.

18. The device of claim 16, wherein the payment module pays an amount not exceeding a preset limit from the shared account in response to the medical insurance payment request.

19. In the device as described in claim 16 or 18, the payment module generates a pre-settlement identifier for payment of the medical insurance payment request; determines the second part of the amount corresponding to the pre-settlement identifier; and sends the pre-settlement identifier and its corresponding second part of the amount to a third-party payment platform so that the second part of the amount corresponding to the pre-settlement identifier can be paid according to the payment account associated with the user in the third-party payment platform.

20. A payment device, applied to a third-party payment platform, comprising: A receiving module receives a medical insurance payment request from a user, wherein the medical insurance payment request is generated by a merchant end scanning a digital object unique identifier of a shared account provided by a user, the shared account is pre-created by a first user, an association is established between the shared account and a second user, the first user corresponds to a first account, the second user corresponds to a second account, the second user has a family relationship with the first user, the second account has the same medical insurance attribute as the first account, and the first account and the second account refer to the user's medical insurance fund account, rather than a payment account in a third-party payment client in a conventional sense; A sending module, which determines the medical insurance settlement institution corresponding to the shared account, and sends the medical insurance payment request to the medical insurance settlement institution so that the medical insurance settlement institution performs a preliminary settlement on the medical insurance payment request; The receiving module is also used to receive the pre-settlement identifier determined by the medical insurance settlement agency and the corresponding second part of the amount; The payment module pays the second portion of the amount corresponding to the pre-settlement identifier according to the payment account associated with the user in the third-party payment platform.

21. A shared account management device, comprising: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute: receiving a request for a second user to join the shared account, wherein a first user corresponds to a first account, the second user corresponds to a second account, and the second user has a family relationship with the first user; When the medical insurance attributes of the second account are consistent with those of the first account, an association relationship between the second user and the shared account is established, wherein the medical insurance attributes are used to characterize the medical insurance type and the medical insurance settlement location, and the first account and the second account refer to the user's medical insurance fund account, rather than the payment account in the third-party payment client in the conventional sense.

22. A payment device comprising: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute: Receive a medical insurance payment request from a user, wherein the medical insurance payment request is generated by a merchant end scanning a digital object unique identifier of a shared account provided by a user, the shared account is pre-created by a first user, an association is established between the shared account and a second user, the first user corresponds to a first account, the second user corresponds to a second account, the second user has a family relationship with the first user, the second account has the same medical insurance attribute as the first account, and the first account and the second account refer to the user's medical insurance fund account, rather than a payment account in a third-party payment client in a conventional sense; Determine the medical insurance settlement institution corresponding to the shared account, and send the medical insurance payment request to the medical insurance settlement institution so that the medical insurance settlement institution performs a preliminary settlement on the medical insurance payment request; Receiving the pre-settlement identifier determined by the medical insurance settlement agency and the corresponding second part of the amount; The second portion of the amount corresponding to the pre-settlement identifier is paid according to the payment account associated with the user in the third-party payment platform.

Images