Payment processing method and apparatus applied to a family group

Abstract

Embodiments of the present specification provide a payment processing method and device applied to a family group, wherein a payment processing method applied to a family group comprises: obtaining an audit result of payment code of the family group; if the audit result is passed, determining the event type of the payment event submitted based on the payment code; the payment code is accessed based on the family relationship established between the family user and the family group; in the case that the event type matches the specific payment type configured for the family user, the payment event is detected for payment constraint; based on the constraint detection result, the payment event is processed.

Description

Technical Field

[0001] This document relates to the field of data processing technology, and in particular to a payment processing method and apparatus for family groups. Background Technology

[0002] With the continuous development of the Internet, more and more users are starting to use it, and the demand for Internet payment is also increasing. Internet payment is gradually replacing cash payment to improve the convenience of payment for users. However, due to the immaturity of minors and their insufficient judgment in the face of Internet payment, there are security risks associated with the way minors make payments through Internet payment. Summary of the Invention

[0003] This specification provides one or more embodiments of a payment processing method applied to a family group, comprising: obtaining the review result of a payment verification of a payment code for the family group; if the review result is approved, determining the event type of a payment event submitted based on the payment code; the payment code is accessed based on the family relationship established between the family user and the family group; if the event type matches a specific payment type configured for the family user, performing payment constraint detection on the payment event; and processing the payment event based on the constraint detection result.

[0004] This specification provides one or more embodiments of a payment processing device applied to a family group, including: an audit result acquisition module configured to acquire an audit result of a payment code audited by the family group; if the audit result is approved, an event type determination module is run, configured to determine the event type of the payment event submitted based on the payment code; the payment code is accessed based on the family relationship established between the family user and the family group; if the event type matches a specific payment type configured for the family user, a payment constraint detection module is run, configured to perform payment constraint detection on the payment event; and a payment processing module is configured to process the payment event based on the constraint detection result.

[0005] This specification provides one or more embodiments of a payment processing device for a family group, comprising: a processor; and a memory configured to store computer-executable instructions, which, when executed, cause the processor to: obtain an audit result of a payment code for the family group; if the audit result is approved, determine the event type of a payment event submitted based on the payment code, wherein the payment code is accessed based on a family relationship established between a family user and the family group; if the event type matches a specific payment type configured for the family user, perform payment constraint detection on the payment event; and process the payment event based on the constraint detection result.

[0006] This specification provides one or more embodiments of a storage medium for storing computer-executable instructions that, when executed by a processor, implement the following process: obtaining the review result of a payment verification for a family group's payment code; if the review result is approved, determining the event type of the payment event submitted based on the payment code; the payment code is accessed based on the family relationship established between the family user and the family group; if the event type matches a specific payment type configured for the family user, performing payment constraint detection on the payment event; and processing the payment event based on the constraint detection result. Attached Figure Description

[0007] To more clearly illustrate the technical solutions in one or more embodiments of this specification or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0008] Figure 1 A flowchart illustrating a payment processing method for a family group, provided for one or more embodiments of this specification;

[0009] Figure 2 This specification provides a flowchart of a payment processing method for a family group scenario, which is provided in one or more embodiments of this specification.

[0010] Figure 3 A flowchart illustrating another payment processing method applied to a family group, provided for one or more embodiments of this specification;

[0011] Figure 4 A schematic diagram of a payment processing device for use in a family group, provided for one or more embodiments of this specification;

[0012] Figure 5 This is a schematic diagram of the structure of a payment processing device applied to a family group, provided for one or more embodiments of this specification. Detailed Implementation

[0013] To enable those skilled in the art to better understand the technical solutions in one or more embodiments of this specification, the technical solutions in one or more embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of the embodiments. Based on one or more embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the protection scope of this document.

[0014] This specification provides an example of a payment processing method applied to family groups:

[0015] The payment processing method for family groups provided in this embodiment performs payment constraint detection on payment events of family users during the payment process based on the family group's payment code. Specifically, based on the determined event type of the payment event submitted based on the payment code, payment constraint detection is performed on the payment event, and payment processing is carried out on the payment event according to the constraint detection result. In this way, during the process of family users making payments using the family group's payment code, payment constraint detection is performed on the payment events generated by family users. By implementing payment constraint detection, payment constraints are imposed on family users, preventing them from making unlimited payments using the payment code and causing fund loss in the family group. This achieves effective control over payment events of family users and improves the convenience and accuracy of payment constraints for family users.

[0016] Reference Figure 1 The payment processing method for family groups provided in this embodiment specifically includes steps S102 to S108.

[0017] Step S102: Obtain the verification result of the payment verification of the family group's payment code.

[0018] The family group described in this embodiment includes a group composed of at least two users with a family relationship. In practical applications, users can apply to create a family group. The user who applies to create the family group is the applicant user in the family group. Users other than the applicant user in the family group are participating users. In addition, the family group may also include an administrator user. That is, the family group is composed of the applicant user, the administrator user, and / or participating users. The applicant user has management permissions for the family group. The management permissions include the permission to configure constraints for participating users, the permission to disable participating users' access to payment codes, the permission to add participating users, and / or the permission to delete participating users. The family relationship includes the association between the family group and the family users.

[0019] The payment code includes an identification code or a family code set for payment within a family group. Family users in the group can use this identification code or family code to make payments. The payment code uniquely identifies the family group and can take the form of a QR code, barcode, voice code, or other identification code. Users in the family group include applicant users, administrator users, and / or participating users. Furthermore, the payment code can also be a family code with specific constraints, a family code used by users with family status within the family group, or a family code used solely for payments. The family code here includes an institutional code applied to or used in a family setting. The institutional code refers to an identification code set by an institution for its members' payments, invoicing, and reimbursement. Optionally, the specific constraints include the lack of expense reimbursement capabilities or the cancellation of the institutional code's reimbursement usage rights. Expense reimbursement capabilities include the ability to reimburse payments made using the family code. Family status refers to a user's identity within the family group, such as a participating user, applicant user, or administrator user.

[0020] In practice, the process involves obtaining the payment verification results for payment codes within a family group. Applicant users, administrators, and / or participating users within the family group can access the payment code. The transaction store can scan this payment code using a configured scanning device and send the scanned payment code, along with the payment data of the applicant, administrator, and / or participating users, to the payment platform. The payment platform then verifies the payment for the family group's payment code and receives the verification results returned by the payment platform. The payment data includes the amount to be paid, the type of payment, and / or the transaction store to be paid for. Additionally, the payment data may include other types of data.

[0021] In practical applications, there are various types of payment codes, such as family payment codes. To enable targeted payment processing based on payment codes, improve the flexibility and security of payment processing based on payment codes, payment verification can be performed on family group payment codes. Specifically, the label type of the payment tag marked on the family group payment code is verified. If the label type is family payment, the verification result is determined to be approved.

[0022] In one optional implementation of this embodiment, the verification result is determined based on the tag type of the payment tag marked on the read payment code. Specifically, the payment verification for family group payment codes is performed in the following manner:

[0023] Read the payment tag corresponding to the payment code and determine the tag type of the payment tag;

[0024] If the label type is a family payment type, the review result is determined to be approved;

[0025] If the label type is not a family payment type, the review result is determined to be "review failed".

[0026] Optionally, the payment tag includes tag information generated after marking the payment code; the tag type includes family payment type, personal payment type, or institutional payment type.

[0027] In the specific implementation process, the payment code for the family group can be generated in advance. Specifically, a family group can be created based on the applicant's identity information, and a payment code corresponding to the family group can be generated. To ensure the validity of the generated payment code for the family group, in an optional implementation method provided in this embodiment, the payment code for the family group is generated in the following way:

[0028] The user attributes of the applicant user are determined based on the applicant user's identity information;

[0029] If the user attribute is a preset user attribute, create the family group and generate a creation record carrying the group keyword of the family group;

[0030] Grant the applicant user management permissions to the family group, and generate the payment code corresponding to the family group based on the applicant user's user information; the user information includes the identity information.

[0031] Specifically, in the process of generating the payment code corresponding to the family group based on the user information of the applicant, this can be achieved by constructing a mask image of the applicant's identity certificate and generating the payment code corresponding to the family group based on the mask image.

[0032] The applicant user refers to the user applying to create a family group; optionally, the applicant user has the authority to manage the family group; the identity information includes an identity credential identifier; the user attributes include the length of time the user has lived from birth to the calculation time; if the length of time is greater than a time length threshold, the user attributes are determined to be preset user attributes; the group keyword includes a structured identifier for the family group, such as the group keyword F1001; the user information refers to information related to the applicant user, such as name, occupation, identity credential identifier, communication identifier, and email account.

[0033] In addition, the payment code for a family group can also be generated in the following way: determine the user attributes of the applicant user based on the applicant user's identity information; if the user attributes are preset user attributes, create a family group based on the applicant user's user information; grant the applicant user management permissions for the family group, and generate the payment code corresponding to the family group; the user information includes the identity information;

[0034] Alternatively, the payment code for a family group can be generated in the following way: the applicant user's identity is verified based on the applicant user's information; after successful verification, a family group is created and a creation record carrying the group keyword is generated; management permissions for the family group are granted to the applicant user, and the payment code corresponding to the family group is generated based on the user information.

[0035] It should be noted that after generating the payment code corresponding to the family group, access rights to the payment code can be further activated for the family group; the family account of the family group can also be associated with the payment code; for example, the family account has a third-party payment account or a bank account.

[0036] It should be added that step S102 can be replaced by obtaining the audit result of the payment audit of the general payment code; and together with other processing steps provided in this embodiment, it forms a new implementation method.

[0037] The universal payment code refers to various types of payment codes commonly used in practice, such as personal payment codes, family payment codes, and / or institutional payment codes.

[0038] Step S104: Determine the event type of the payment event submitted based on the payment code.

[0039] The above-mentioned step of obtaining the payment verification result for the payment code of the family group involves determining the event type of the payment event submitted based on the payment code. Specifically, if the verification result is approved, the event type of the payment event is determined; if the verification result is not approved, payment processing is performed based on the family user's resource account. Optionally, the payment code is accessed based on the family relationship established between the family user and the family group. This enhances the flexibility of family users accessing the payment code and further manages the funds of the family group through payment processing via the payment code, preventing the loss of funds from the family group.

[0040] The payment event mentioned in this embodiment refers to a payment event generated by a family user at a transaction store, such as a payment event generated for the purchase of goods at the transaction store; the event type refers to the type of payment event, such as a game event type, a stationery event type, or a transportation event type.

[0041] Optionally, the family user refers to a user in a family group; the family user includes the applicant user, the administrator user, and / or the participating user; the participating user refers to a user who participates in the family group; the relationship between the applicant user and the participating user includes kinship and / or friendship; in addition, the relationship between the applicant user and the participating user may also include elder and / or younger generation relationship, such as the applicant user being an aunt and the participating user being a niece.

[0042] In practice, family users access the payment code based on the family relationship established with the family group. In the process of establishing the family relationship between the family group and the family user, in one case, the applicant user can add the participating user to the family group to establish the family relationship between the participating user and the family group; in another case, the participating user can actively apply to join the family group, and after joining, the family relationship between the participating user and the family group is established. In this way, the flexibility and diversity of adding new users to the family group are realized. Optionally, the access rights of the family user to the payment code are activated after the family relationship is established. The family user includes the applicant user, the administrator user, and / or the participating user.

[0043] In one optional implementation of this embodiment, a record carrying the user's keywords is generated based on the participating user information submitted by the applicant user. A family relationship is established by associating group keywords with user keywords. Specifically, the family relationship is established in the following way:

[0044] Obtain the participating user information submitted by the applicant for the family group;

[0045] Based on the participating user information, a record carrying the user's keywords is generated, and the family relationship is established by establishing the association between the group keywords and the user keywords;

[0046] The access rights of the participating user to the payment code are activated after the family relationship is established.

[0047] The participating user information here refers to relevant information about the participating user, such as name, occupation, identity credential identifier, communication identifier, and email account; the user keywords include the structured identifier of the participating user, which is an identifier that represents the uniqueness of the participating user in the family group, such as the user keyword M1001.

[0048] Specifically, it can obtain the participating user information submitted by the applicant for the family group, generate records carrying the user keywords of the participating users, associate the participating user information with the user keywords, and establish family relationships by establishing the association between group keywords and user keywords.

[0049] For example, the system obtains the participating user information submitted by the applicant, which is "name xx, communication identifier xxx", generates a record carrying the user keyword M1001, associates the participating user information "name xx, communication identifier xxx" with the user keyword M1001, and establishes a family relationship by establishing an association between the group keyword F1001 and the user keyword M1001.

[0050] In addition, the family relationship can also be established in the following way: obtaining the participating user information submitted by the applicant for the family group; verifying the user attributes of the participating users based on the participating user information; generating a record carrying the user keywords of the participating users based on the participating user information after the verification is passed, and establishing the family relationship by establishing the association between the group keywords and the user keywords; optionally, the participating users' access rights to the payment code are activated after the family relationship is established.

[0051] Specifically, in the process of verifying the user attributes of participating users based on the participating user information, the user attributes of participating users are determined based on the participating user information, and it is verified whether the user attribute is within the attribute value range. If so, the verification is confirmed to be successful.

[0052] As mentioned above, in addition to the method of establishing family relationships provided, participating users can also actively apply to join the family group. After joining, a family relationship is established between the participating user and the family group. Specifically, the family relationship is established in the following way:

[0053] Obtain the application instructions submitted by participating users for the family group; the application instructions carry the information of the participating users;

[0054] Records containing user keywords of participating users are generated based on the information of participating users, and family relationships are established by establishing associations between group keywords and user keywords;

[0055] The access permissions for the payment code to the participating users are activated after the family relationship is established.

[0056] It should be noted that, as mentioned above, after generating the payment code corresponding to the family group, access permissions to the payment code can be further activated for the family group. In this case, after establishing the family relationship between the family group and the participating users, that is, after the participating users are added to the family group, it is not necessary to activate access permissions for the payment code for the participating users again, because the family group has access permissions for the payment code, and the participating users who join the family group also have access permissions for the payment code.

[0057] Step S106: Perform payment constraint detection on the payment event.

[0058] The above steps determine the event type of payment events submitted based on payment codes. In this step, payment constraint detection is performed on the payment events. Specifically, the event type of the payment event is matched with the specific payment type configured for family users. If the match is successful, payment constraint detection is performed on the payment event. If the match fails, a payment failure reminder is displayed to the family users.

[0059] The payment constraint detection described in this embodiment includes detecting payment events generated by household users based on constraint conditions or detecting payment behaviors of household users based on constraint conditions, so as to constrain the payment behavior of household users. The detection of payment events can be achieved through detection in various dimensions to constrain the payment behavior of household users. Specifically, it can be achieved by detecting whether the payment event meets the constraint conditions, thereby constraining the payment behavior of household users and improving the rationality of the payment behavior of household users.

[0060] In practice, when the event type of a payment event matches a specific payment type configured for a family user, payment constraint detection is performed on the payment event. The specific payment type refers to a pre-defined payment type for making a payment; the specific payment type includes specific payment conditions or specific payment categories; for example, the specific payment type is "stationery payment type" or "game payment type".

[0061] Optionally, the specific payment type is configured based on the family user's group identity type in the family group or based on the family user's behavioral data. The group identity type can represent the family user's identity in the family group, including the identity type or group role in the family group, such as being a junior or an elder of the applicant user. In addition, the specific payment type can also be configured based on the close relationship between the family user and the applicant user in the family group, such as the applicant user being the family user's parent or child.

[0062] To control the payment behavior of household users, in one optional implementation of this embodiment, the following operations are performed during the payment constraint detection process for household user payment events:

[0063] Extract payment information from at least one payment constraint dimension carried by the payment event;

[0064] Detect whether the payment information meets the constraint conditions of the corresponding payment constraint dimension;

[0065] If yes, the constraint detection result is determined to be a pass; otherwise, the constraint detection result is determined to be a fail.

[0066] Optionally, the payment constraint dimensions include at least one of the following: amount dimension, time dimension, transaction store dimension, and transaction platform dimension;

[0067] Accordingly, the constraints include at least one of the following:

[0068] The payment amount is within the limit range, the payment time is within the time range, the location of the transaction store is within the payment location range, and the transaction platform is a preset transaction platform.

[0069] The credit limit dimension includes a payment limit dimension, which includes a single payment limit and / or a periodic payment limit, such as a monthly payment limit of 500 yuan. The payment information refers to payment-related information, including the payment amount, payment time, and / or the location information of the transaction store. The transaction store refers to the store where the user conducts the transaction, such as a merchant's store; the transaction platform refers to the platform on which the user conducts the transaction, such as a shopping platform.

[0070] Specifically, the payment amount (credit limit dimension) carried by the payment event is extracted, and it is checked whether the payment amount is within the credit limit range. If so, the constraint detection result is determined to be passed. And / or, the payment time (time dimension) carried by the payment event is extracted, and it is checked whether the payment time is within the time range. If so, the constraint detection result is determined to be passed. And / or, the location information of the transaction store (transaction store dimension) carried by the payment event is extracted, and it is checked whether the location of the transaction store corresponding to the transaction store location information is within the payment location range. If so, the constraint detection result is determined to be passed. And / or, the transaction platform (transaction platform dimension) carried by the payment event is extracted, and it is checked whether the transaction platform is a preset transaction platform. If so, the constraint detection result is determined to be passed.

[0071] Step S108: Perform payment processing on the payment event based on the constraint detection results.

[0072] The above-mentioned payment constraint detection for payment events specifically detects the payment information carried by the payment event based on the constraint conditions. In this step, the payment event is processed based on the constraint detection results. In this way, payment constraint detection constrains the payment events of family users, controls the payment behavior of family users, achieves precise control over the payment behavior of family users, and prevents family users from overspending based on the payment code of the family group.

[0073] In one optional implementation of this embodiment, if the constraint detection result is "passed," the payment event is processed based on the family account of the family group; if the constraint detection result is "failed," the payment event is processed based on the resource account of the family user. This avoids excessive payment behavior by family users, prevents the loss of funds in the family group, and ensures the security of funds in the family group. Specifically, in the process of processing the payment event based on the constraint detection result, the following operations are performed:

[0074] If the constraint detection result is a pass, the payment event is processed based on the family account of the family group, or a payment processing instruction is sent to the payment platform corresponding to the family account of the family group, so that the payment event is processed based on the family account of the family group on the payment platform;

[0075] If the constraint detection result is that the detection fails, the payment event is processed based on the family user's resource account, or a payment failure reminder is returned to the family user;

[0076] The family account includes the resource account of the user applying in the family group.

[0077] The payment platform mentioned here refers to a platform for managing family accounts, including opening accounts and transferring funds; the payment processing instruction refers to an instruction to process payments.

[0078] After payment processing, a payment record is generated and returned to the family group. The payment record can include information such as payment amount, payment product information, transaction store information, payment device information, and payment time. Applicant users in the family group can view the payment record, trace payment events of family users, and further adjust the constraints to improve the effectiveness of payment constraints for family users.

[0079] In practical applications, after performing payment constraint detection on payment events—specifically, after detecting the payment information carried by the payment events based on the set constraint conditions—double constraints are applied to the payment events of family users to further enhance their payment security and ensure their legitimacy. In another optional implementation provided in this embodiment, payment processing is performed based on the applicant's confirmation response to the payment event. Specifically, during the payment processing based on the constraint detection results, the following operations are executed:

[0080] After the constraint detection is passed, a confirmation request for the payment event is sent to the applicant users in the family group;

[0081] Obtain the confirmation response submitted by the applicant in response to the confirmation request, and perform the payment processing based on the confirmation response.

[0082] The confirmation request refers to inviting a user to confirm payment for a payment event. Payment processing can proceed after receiving confirmation from the user.

[0083] In practical applications, the number of times a household user's payment events fail to meet the constraints may be high or low. To enhance the constraint on household users' payment behavior, the payment behavior can be constrained based on the number of times the detected payment events fail to meet the constraints. In an optional implementation of this embodiment, the following operation is also performed: detecting the number of times the payment information of at least one payment constraint dimension carried in the payment event is not within the constraint value range of the corresponding payment constraint dimension;

[0084] The access rights of the family users to the payment code may be closed based on the number of times the access rights were requested, or the access rights may be closed based on the number of times the access rights were requested and the permission closure instruction from the user in the family group.

[0085] Optionally, the constraint value range includes the amount value range, the time value range, the payment location range, and / or the transaction platform range; the payment event here includes the current payment event and the historical payment event.

[0086] Specifically, access to the payment code for family users can be disabled based on the number of times the access is used, including: if the number of times exceeds a threshold, the access to the payment code for family users is disabled; access can also be disabled based on the number of times the access is used and the permission-disabling command from the user applying in the family group, including: if the number of times exceeds a threshold, the access to the payment code for family users is disabled based on the permission-disabling command from the user applying in the family group; in addition, access to the payment code for family users can also be disabled directly based on the permission-disabling command from the user applying in the family group.

[0087] In practical applications, there may be multiple elders participating in a family group. To enable all elders participating in the family group to manage the group and improve the accuracy of control over participating users, the applicant can submit a level change instruction for participating users in the family group and change the family level of the participating users. After the change, they will have the authority to manage the family group. In an optional implementation of this embodiment, the following operation is also performed:

[0088] Obtain the level change instruction submitted by the applicant user in the family group for the participating user;

[0089] If the user attributes of the participating user meet the preset attribute conditions, the family level of the participating user will be changed to that of an administrator.

[0090] The managing user has the authority to set constraints for participating users in the family group, and the authority to disable access to the payment code for participating users in the family group.

[0091] The "family level" here refers to a user's level within a family group. This family level includes applicant users, administrator users, and / or participating users. Applicant users have administrative privileges for managing family groups, including the ability to set constraints for participating users, disable participating users' access to payment codes, add participating users to the family group, and / or delete participating users from the family group. The "level change instruction" refers to an instruction to change a user's family level.

[0092] It should be noted that, based on the user's instruction to change the administrator's level within the family group, the administrator's family level can also be changed to a participating user.

[0093] In specific implementation, by disabling family users' access to the family group's payment code, unreasonable payment events by family users can be "punished." Simultaneously, when family users have remaining payment credit, the remaining resources corresponding to that credit can be transferred to the family user's resource account to "reward" them. This enhances family users' awareness and motivation to use the family group's payment code reasonably, and also increases their initiative in controlling payment behavior. In an optional implementation of this embodiment, the following operations are also performed:

[0094] When the time period included in the constraints configured for the family user expires, determine the remaining payment amount for the family user under the specific payment type;

[0095] The remaining resources corresponding to the remaining payment amount are transferred from the family account of the family group to the resource account of the family user; the resource account is managed by the applicant user in the family group.

[0096] Optionally, pay the remaining balance, including the difference between the amount paid and the balance paid within the time period.

[0097] For example, the constraints for a family user include a time period of one month and a specific payment type of stationery. When one month is up, the remaining payment amount for the family user under the stationery payment type is determined to be 200 yuan. The remaining resources of 200 yuan corresponding to the remaining payment amount are transferred to the family user's resource account, which the family user can then use to dispose of the remaining resources.

[0098] In summary, the payment processing method for family groups provided in this embodiment obtains the review result of the payment code of the family group, determines the event type of the payment event submitted based on the review result, performs payment constraint detection on the payment event based on the matching result of the event type of the payment event and the specific payment type configured for the family user, and processes the payment event according to the constraint detection result.

[0099] Specifically, based on the tag type of the payment tag read from the payment code for the family group, the review result of the payment code is determined. If the tag type is a family payment type, the review result is determined to be approved. The event type of the payment event submitted based on the payment code is then determined. If the event type matches the specific payment type configured for the family user, the payment information is checked to see if it meets the constraint conditions of the corresponding payment constraint dimension based on the payment information extracted from the payment event. If it does, the constraint detection result is determined to be approved, and the payment event is processed based on the family group's resource account, or the payment is sent to the payment platform corresponding to the family account. The platform sends payment processing instructions to process payment events based on the family group's family account on the payment platform. If the conditions are not met, the constraint detection result is determined to be a failure, and the payment event is processed based on the family user's resource account. In this way, during the process of family users making payments using the family group's payment code, payment constraint detection is performed on the payment events generated by family users. Through payment constraint detection, payment constraints are implemented for family users to prevent them from making unlimited payments using the payment code, which could lead to the loss of funds in the family group. This achieves effective control over payment events for family users and improves the convenience and accuracy of payment constraints for family users.

[0100] The following description uses the application of a payment processing method for family groups provided in this embodiment in a family group scenario as an example to further illustrate the payment processing method for family groups provided in this embodiment. See [link to documentation]. Figure 2 The payment processing method for family groups, which is applied to family group scenarios, specifically includes the following steps.

[0101] Step S202: Read the payment tag marked with the payment code for the family group and determine the tag type of the payment tag.

[0102] Step S204: If the tag type is family payment type, determine the event type of the payment event submitted based on the payment code.

[0103] Step S206: Query whether there is a specific payment type configured for family users that matches the event type of the payment event;

[0104] If so, proceed with steps S208 to S210;

[0105] If not, payment events are processed based on the resource accounts of family users.

[0106] Step S208: Extract payment information from at least one payment constraint dimension carried by the payment event.

[0107] Step S210: Check whether the payment information meets the constraint conditions of the corresponding payment constraint dimension;

[0108] If so, proceed to steps S212 to S218;

[0109] If not, payment events are processed based on the resource accounts of family users.

[0110] Step S212: Send a confirmation request for the payment event to the applicant in the family group.

[0111] Step S214: Obtain the confirmation response from the applicant user for submitting the confirmation application, and process the payment event based on the family account of the family group.

[0112] Step S216: Detect the number of times that the payment information of at least one payment constraint dimension carried in the payment event of a family user is not within the constraint value range of the corresponding payment constraint dimension.

[0113] The payment events here include current payment events and historical payment events.

[0114] Step S218: Based on the number of times, close the family user's access to the payment code.

[0115] Step S214 above can be replaced by obtaining the confirmation response from the applicant user for the confirmation application, and sending a payment processing instruction to the payment platform corresponding to the family account, so as to process the payment event based on the family group's family account on the payment platform; and forming a new implementation method with other processing steps in this embodiment.

[0116] Another example of a payment processing method for family groups provided in this specification is as follows:

[0117] Reference Figure 3 The payment processing method for family groups provided in this embodiment specifically includes steps S302 to S308.

[0118] Step S302: Obtain the payment events carried in the payment orders submitted by family users in the family group, and determine the event type of the payment events.

[0119] Payment orders refer to payment orders generated on the trading platform.

[0120] Step S304: Perform payment constraint detection on the payment event.

[0121] Optionally, if the event type matches a specific payment type configured for the household user, payment constraint detection is performed on the payment event.

[0122] Step S306: Perform payment processing on the payment event based on the constraint detection results.

[0123] It should be noted that the specific implementation process of steps S302 to S306 in the payment processing method for family groups provided in this embodiment is similar to the specific implementation process of steps S104 to S108 in the payment processing method for family groups provided in the above embodiment. Therefore, when reading the payment processing method for family groups provided in this embodiment, please refer to the specific implementation process of the payment processing method for family groups provided in the above embodiment. This embodiment will not repeat it here.

[0124] This specification provides an embodiment of a payment processing device for use in family groups as follows:

[0125] In the above embodiments, a payment processing method for family groups is provided, and correspondingly, a payment processing device for family groups is also provided, which will be described below with reference to the accompanying drawings.

[0126] Reference Figure 4 The diagram illustrates a payment processing device for family groups provided in this embodiment.

[0127] Since the apparatus embodiments correspond to the method embodiments, the descriptions are relatively simple. For relevant parts, please refer to the corresponding descriptions of the method embodiments provided above. The apparatus embodiments described below are merely illustrative.

[0128] This embodiment provides a payment processing device for use in family groups, including:

[0129] The audit result acquisition module 402 is configured to acquire the audit result of the payment audit of the payment code of the family group;

[0130] If the review result is approved, the event type determination module 404 is run. The event type determination module 404 is configured to determine the event type of the payment event submitted based on the payment code; the payment code is accessed based on the family relationship established between the family user and the family group.

[0131] If the event type matches a specific payment type configured for the household user, the payment constraint detection module 406 is run. The payment constraint detection module 406 is configured to perform payment constraint detection on the payment event.

[0132] The payment processing module 408 is configured to process the payment event based on the constraint detection result.

[0133] This specification provides an example of a payment processing device for use in family groups, as follows:

[0134] Corresponding to the payment processing method for family groups described above, based on the same technical concept, one or more embodiments of this specification also provide a payment processing device for family groups, which is used to execute the payment processing method for family groups provided above. Figure 5 This is a schematic diagram of the structure of a payment processing device applied to a family group, provided for one or more embodiments of this specification.

[0135] This embodiment provides a payment processing device for use in family groups, comprising:

[0136] like Figure 5 As shown, payment processing devices for home groups can vary considerably due to differences in configuration or performance. They may include one or more processors 501 and memory 502, with memory 502 storing one or more applications or data. Memory 502 can be temporary or persistent storage. The applications stored in memory 502 may include one or more modules (not shown), each module including a series of computer-executable instructions for the payment processing device. Furthermore, processor 501 may be configured to communicate with memory 502, executing the series of computer-executable instructions in memory 502 on the payment processing device. Payment processing devices for home groups may also include one or more power supplies 503, one or more wired or wireless network interfaces 504, one or more input / output interfaces 505, one or more keyboards 506, etc.

[0137] In one specific embodiment, the payment processing device for a family group includes a memory and one or more programs, wherein the one or more programs are stored in the memory, and the one or more programs may include one or more modules, and each module may include a series of computer-executable instructions for the payment processing device for a family group, and is configured to be executed by one or more processors. The one or more programs include computer-executable instructions for performing the following:

[0138] Obtain the verification results of payment verification for family group payment codes;

[0139] If the review result is approved, the event type of the payment event submitted based on the payment code is determined; the payment code is accessed based on the family relationship established between the family user and the family group;

[0140] If the event type matches a specific payment type configured for the family user, a payment constraint detection is performed on the payment event;

[0141] The payment event is processed based on the constraint detection results.

[0142] This specification provides an example of a storage medium as follows:

[0143] Corresponding to the payment processing method applied to family groups described above, based on the same technical concept, one or more embodiments of this specification also provide a storage medium.

[0144] The storage medium provided in this embodiment is used to store computer-executable instructions, which, when executed by a processor, implement the following process:

[0145] Obtain the verification results of payment verification for family group payment codes;

[0146] If the review result is approved, the event type of the payment event submitted based on the payment code is determined; the payment code is accessed based on the family relationship established between the family user and the family group;

[0147] If the event type matches a specific payment type configured for the family user, a payment constraint detection is performed on the payment event;

[0148] The payment event is processed based on the constraint detection results.

[0149] It should be noted that the embodiments concerning storage media in this specification and the embodiments concerning payment processing methods applied to family groups in this specification are based on the same inventive concept. Therefore, the specific implementation of this embodiment can be referred to the implementation of the corresponding methods described above, and the repeated parts will not be described again.

[0150] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0151] In the 1930s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many improvements to the methodology today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that an improvement to the methodology cannot be implemented using a hardware physical module. For example, a Programmable Logic Device (PLD) (e.g., a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, 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, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0152] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, ASICs, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

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

[0154] For ease of description, the above apparatus is described by dividing it into various functional units. Of course, when implementing the embodiments of this specification, the functions of each unit can be implemented in one or more software and / or hardware.

[0155] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, one or more embodiments of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this specification may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0156] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0157] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0158] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

[0160] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0161] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0162] It should also be noted that the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0163] One or more embodiments of this specification can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a particular task or implement a particular abstract data type. One or more embodiments of this specification can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0164] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0165] The above description is merely an embodiment of this document and is not intended to limit the scope of this document. Various modifications and variations can be made to this document by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this document should be included within the scope of the claims of this document.

Claims

1. A payment processing method for family groups, comprising: Obtain the verification results of payment verification for family group payment codes; If the review result is "approved", determine the event type of the payment event submitted based on the payment code; The payment code is generated based on a masked image of the applicant's identity credentials and accessed based on the family relationship established between the family user and the family group; If the event type matches a specific payment type configured for the family user, extract the transaction platform carried by the payment event and detect whether the transaction platform is a preset transaction platform. If so, the payment event is processed based on the family account of the family group.

2. The payment processing method for family groups according to claim 1 further includes: The number of times that payment information in at least one payment constraint dimension carried in a payment event is not within the constraint value range of the corresponding payment constraint dimension; The access rights of the family users to the payment code may be closed based on the number of times the access rights were requested, or the access rights may be closed based on the number of times the access rights were requested and the permission closure instruction from the user in the family group.

3. The payment processing method for family groups according to claim 1, if the result of detecting whether the transaction platform is a preset transaction platform after the operation is not found to be true, the following operation is performed: The payment event is processed based on the resource account of the family user; in, The family account includes the resource account of the user applying in the family group.

4. The payment processing method for family groups according to claim 1, wherein the payment verification of the payment code for the family group includes: Read the payment tag corresponding to the payment code and determine the tag type of the payment tag; If the label type is a family payment type, the review result is determined to be approved.

5. The payment processing method for family groups according to claim 1, wherein the payment code for the family group is generated in the following manner: The user attributes of the applicant user are determined based on the applicant user's identity information; If the user attribute is a preset user attribute, create the family group and generate a creation record carrying the group keyword of the family group; Grant the applicant user management permissions to the family group, and generate the payment code corresponding to the family group based on the applicant user's user information; the user information includes the identity information.

6. The payment processing method applied to a family group according to claim 5, wherein the family relationship is established in the following manner: Obtain the participating user information submitted by the applicant for the family group; Based on the participating user information, a record carrying the user's keywords is generated, and the family relationship is established by establishing the association between the group keywords and the user keywords; in, The participating user's access rights to the payment code are activated after the family relationship is established.

7. The payment processing method for family groups according to claim 1, further comprising: Obtain the level change instruction submitted by the applicant user in the family group for the participating user; If the user attributes of the participating user meet the preset attribute conditions, the family level of the participating user will be changed to that of an administrator. The managing user has the authority to set constraints for participating users in the family group, and the authority to disable access to the payment code for participating users in the family group.

8. The payment processing method for a family group according to claim 1, wherein the specific payment type is configured based on the family user's group identity type in the family group or based on the family user's behavioral data.

9. The payment processing method for family groups according to claim 1, further comprising: When the time period included in the constraints configured for the family user expires, determine the remaining payment amount for the family user under the specific payment type; The remaining resources corresponding to the remaining payment amount are transferred from the family account of the family group to the resource account of the family user; the resource account is managed by the applicant user in the family group.

10. A payment processing device for use in a family group, comprising: The review result retrieval module is configured to retrieve the review results of payment code verification for family groups; If the review result is approved, the event type determination module is run. The event type determination module is configured to determine the event type of the payment event submitted based on the payment code. The payment code is generated based on a masked image of the applicant's identity credentials and accessed based on the family relationship established between the family user and the family group; If the event type matches a specific payment type configured for the family user, the payment constraint detection module is run. The payment constraint detection module is configured to extract the transaction platform carried by the payment event and detect whether the transaction platform is a preset transaction platform. The payment processing module is configured to, if so, process the payment event based on the family account of the family group.

11. A payment processing device for use in a family group, comprising: processor; And, a memory configured to store computer-executable instructions, which, when executed, cause the processor to: Obtain the verification results of payment verification for family group payment codes; If the review result is "approved", determine the event type of the payment event submitted based on the payment code; The payment code is generated based on a masked image of the applicant's identity credentials and accessed based on the family relationship established between the family user and the family group; If the event type matches a specific payment type configured for the family user, extract the transaction platform carried by the payment event and detect whether the transaction platform is a preset transaction platform. If so, the payment event is processed based on the family account of the family group.

12. A storage medium for storing computer-executable instructions, which, when executed by a processor, perform the following process: Obtain the verification results of payment verification for family group payment codes; If the review result is "approved", determine the event type of the payment event submitted based on the payment code; The payment code is generated based on a masked image of the applicant's identity credentials and accessed based on the family relationship established between the family user and the family group; If the event type matches a specific payment type configured for the family user, extract the transaction platform carried by the payment event and detect whether the transaction platform is a preset transaction platform. If so, the payment event is processed based on the family account of the family group.

Images