Hybrid payment method and device based on insurance premium, equipment and medium

Abstract

The application relates to the technical field of data processing, and discloses a hybrid payment method and device based on insurance premiums, equipment and medium, belonging to the technical field of data processing, applied to the financial technology scene, comprising the following steps: based on a hybrid payment request, target member bills corresponding to a plurality of policy payment members and payment benchmark data are called from a payment configuration database; based on a plurality of payment benchmark data, the receivable fees of each policy payment member are analyzed, the receivable fees of the corresponding policy corresponding to each policy payment member are determined, and the hybrid payment fees are distributed and paid to each target member bill. The application embodiment improves the accuracy of fee allocation and the flexibility of payment execution in the multi-payment subject insurance task by splitting the hybrid payment fees to the plurality of target member bills and performing payment processing respectively, so that the payment adaptation capability and the overall execution efficiency of the insurance business are improved.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, applicable to financial technology scenarios, and particularly to a hybrid payment method, apparatus, device, and medium based on insurance premiums. Background Technology

[0002] Currently, in traditional insurance policy processing systems, the payment function typically achieves unilateral, single-transaction settlement by binding the total cost of the entire order to a single payment entity and a fixed payment channel. For example, in the scenario of premium payment for corporate group insurance, in response to the task request to "increase the coverage amount for company employees," the system obtains the increased coverage amount for the task and issues a deduction instruction for the increased coverage amount to the company's linked corporate account for unified deduction, or issues a deduction instruction for the increased coverage amount to the individual bank card accounts of company employees for independent deduction, thereby completing the payment task.

[0003] However, this method typically only supports payment processing for a single entity handling the entire expense. When multiple entities share the cost in the same task, it becomes difficult to allocate costs and execute payments separately for each entity, potentially disrupting insurance business processes and resulting in insufficient payment adaptability. Therefore, how to provide hybrid payment solutions for insurance tasks involving multiple entities to improve the efficiency of insurance business execution has become an urgent problem to be solved. Summary of the Invention

[0004] This invention provides a hybrid payment method, apparatus, computer equipment, and medium based on insurance premiums to solve the technical problem of how to provide hybrid payments for insurance tasks involving multiple parties in order to improve the execution efficiency of insurance business.

[0005] Firstly, a hybrid payment method based on insurance premiums is provided, including: Obtain the mixed payment request and the mixed payment fee corresponding to the mixed payment request; Based on the hybrid payment request, the corresponding target configuration data table is retrieved from the pre-built payment configuration database; wherein, the target configuration data table contains target member bills and payment benchmark data corresponding to multiple policy payment members; Based on multiple payment benchmark data, the payable amount for each policy payment member is analyzed to determine the policy payable amount corresponding to each policy payment member; Based on the policy receivables corresponding to each policy payment member, the mixed payment fees are allocated and paid to each target member's bill.

[0006] Secondly, a hybrid payment device based on insurance premiums is provided, comprising: A mixed payment request and fee acquisition module is used to acquire a mixed payment request and a mixed payment fee corresponding to the mixed payment request; The configuration data table acquisition module is used to retrieve the corresponding target configuration data table from a pre-built payment configuration database based on the hybrid payment request; wherein, the target configuration data table contains target member bills and payment benchmark data corresponding to multiple policy payment members; The accounts receivable parsing module is used to perform accounts receivable parsing on each of the policy payment members based on multiple payment benchmark data, so as to determine the policy accounts receivable corresponding to each of the policy payment members; The hybrid payment operation module is used to allocate the hybrid payment fees to each of the target member's bills based on the policy receivables corresponding to each policy payment member.

[0007] Thirdly, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the steps of the above-described hybrid payment method based on insurance premiums.

[0008] Fourthly, a computer-readable storage medium is provided, which stores a computer program that, when executed by a processor, implements the steps of the above-described hybrid payment method based on insurance premiums.

[0009] In the above-mentioned scheme implemented by the hybrid payment method, device, equipment, and medium based on insurance premiums, a hybrid payment request and the corresponding hybrid payment fee can be obtained. Based on the hybrid payment request, the corresponding target configuration data table can be retrieved from a pre-built payment configuration database. The target configuration data table contains target member bills and payment benchmark data corresponding to multiple policy payment members. Further, based on the multiple payment benchmark data, the accounts receivable of each policy payment member are parsed to determine the policy accounts receivable corresponding to each policy payment member. Then, based on the policy accounts receivable corresponding to each policy payment member, the hybrid payment fee is allocated to each target member bill for payment operation. In this application, a pre-built payment configuration database is used to perform configurable matching of mixed payment requests, and the payment benchmark data in the target configuration data table is used to parse the payable fees of different policy payment members. This enables the policy maintenance business processing system to split the mixed payment fees into multiple target member bills and execute payment processing separately based on different payment entities, different member bills, and different fee-sharing rules. This effectively solves the problem of difficulty in completing fee allocation and payment execution separately for different payment entities, avoids interruption of insurance business processes, improves the accuracy of fee allocation and payment execution flexibility in multi-payer insurance tasks, and thus improves the payment adaptability and overall execution efficiency of insurance business. Attached Figure Description

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

[0011] Figure 1 This is a schematic diagram of an application environment for a hybrid payment method based on insurance premiums according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating a hybrid payment method based on insurance premiums in one embodiment of the present invention; Figure 3 yes Figure 2 A schematic diagram of a specific implementation method for step S102; Figure 4 yes Figure 2 A schematic diagram of a specific implementation method for step S103; Figure 5 yes Figure 4 A schematic diagram of a specific implementation of step S304; Figure 6 yes Figure 2A schematic diagram of a specific implementation of step S104; Figure 7 Yes Figure 2 A flowchart illustrating another specific implementation of step S104; Figure 8 This is a schematic diagram of a hybrid payment device based on insurance premiums in one embodiment of the present invention; Figure 9 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 10 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] The hybrid payment method based on insurance premiums provided in this application relates to the field of data processing technology.

[0013] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0014] The hybrid payment method based on insurance premiums provided in this invention can be applied to, for example... Figure 1In this application environment, the client communicates with the server via a network. The server can obtain a mixed payment request and the corresponding mixed payment fee, and retrieve the corresponding target configuration data table from a pre-built payment configuration database based on the mixed payment request. The target configuration data table contains target member bills and payment benchmark data corresponding to multiple policy payment members. Further, based on the multiple payment benchmark data, the server performs accounts receivable parsing for each policy payment member to determine the policy accounts receivable for each policy payment member. Finally, based on the policy accounts receivable for each policy payment member, the server allocates the mixed payment fee to each target member bill for payment. In this application, a pre-built payment configuration database is used to perform configurable matching of mixed payment requests. Payment benchmark data in the target configuration data table is used to parse the payable fees of different policy payment members. This enables the policy maintenance business processing system to split mixed payment fees into multiple target member bills and execute payment processing separately based on different payment entities, different member bills, and different fee-sharing rules. This effectively solves the problem of difficulty in separately completing fee allocation and payment execution based on different payment entities, avoids interruptions in insurance business processes, improves the accuracy of fee allocation and the flexibility of payment execution in multi-payer insurance tasks, thereby improving the payment adaptability and overall execution efficiency of insurance business. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a standalone server or a server cluster consisting of multiple servers. The invention will be described in detail below through specific embodiments.

[0015] like Figure 2 As shown, Figure 2 A flowchart illustrating a hybrid payment method based on insurance premiums provided in an embodiment of the present invention may include, but is not limited to, steps S101 to S104: Step S101: Obtain the mixed payment request and the mixed payment fee corresponding to the mixed payment request.

[0016] Step S102: Based on the mixed payment request, retrieve the corresponding target configuration data table from the pre-built payment configuration database; wherein, the target configuration data table contains target member bills and payment benchmark data corresponding to multiple policy payment members.

[0017] Step S103: Based on multiple payment benchmark data, analyze the payables for each policy payment member to determine the policy payables corresponding to each policy payment member.

[0018] Step S104: Based on the policy receivables of each policy payment member, the mixed payment fees are allocated and paid to each target member's bill.

[0019] Steps S101 to S104 as illustrated in this embodiment involve obtaining a mixed payment request and the corresponding mixed payment fee, and retrieving the corresponding target configuration data table from a pre-built payment configuration database based on the mixed payment request. The target configuration data table contains target member bills and payment benchmark data corresponding to multiple policy payment members. Further, based on the multiple payment benchmark data, the payable fees for each policy payment member are parsed to determine the policy payable fees corresponding to each policy payment member. Then, based on the policy payable fees corresponding to each policy payment member, the mixed payment fee is allocated and paid to each target member bill. In this application, a pre-built payment configuration database is used to perform configurable matching of mixed payment requests, and the payment benchmark data in the target configuration data table is used to parse the payable fees of different policy payment members. This enables the policy maintenance business processing system to split the mixed payment fees into multiple target member bills and execute payment processing separately based on different payment entities, different member bills, and different fee-sharing rules. This effectively solves the problem of difficulty in completing fee allocation and payment execution separately for different payment entities, avoids interruption of insurance business processes, improves the accuracy of fee allocation and payment execution flexibility in multi-payer insurance tasks, and thus improves the payment adaptability and overall execution efficiency of insurance business.

[0020] In step S101 of some embodiments, specifically, a mixed payment request and a mixed payment fee corresponding to the mixed payment request are obtained.

[0021] Specifically, a mixed payment request refers to a request that allocate insurance premiums collected from multiple policy payment members to the corresponding policy payment members.

[0022] Specifically, the mixed payment fee refers to the total unallocated payment fee corresponding to the mixed payment request, which is used for billing balance of multiple policy payment members.

[0023] For example, in insurance application scenarios, for requests such as premium payment, increase of coverage, additional coverage for individuals, or bill balancing in group insurance policy maintenance business, the mixed payment fee can be the sum of the payment fees to be allocated to multiple policy payment members corresponding to the mixed payment request; among them, the payment members involved in the sum of payment fees to be allocated can be insured employees, enterprises, and financial units in the group insurance policy, etc.

[0024] Specifically, obtaining the mixed payment request and the corresponding mixed payment fee includes: identifying the request type of the mixed payment request to obtain the payment request type; wherein, the request type includes the initial payment request type and the transfer failure adjustment request type; when the request type is the initial payment request type, querying the pending payment fee data corresponding to the target preservation task based on the preservation task identifier in the mixed payment request, and determining the mixed payment fee corresponding to the mixed payment request based on the pending payment fee data; when the request type is the transfer failure adjustment request type, obtaining the replacement payment account information carried in the transfer failure adjustment request, and determining the replacement payment account information as the target payment account information corresponding to the mixed payment fee, so as to continue to execute the payment processing for the mixed payment fee based on the target payment account information.

[0025] The "Initial Payment Request" type indicates that the current request is the first payment request initiated for an insurance preservation task, while the "Failed Transfer Adjustment Request" type indicates that the current request is an adjustment request for resubmitting payment account information after a previous payment failure.

[0026] For example, in insurance application scenarios, if the request type is an initial payment request and the target policy maintenance task is a group insurance premium increase task, and the pending payment amount is 500 yuan based on the policy maintenance task identifier, then this 500 yuan is identified as a mixed payment amount for subsequent fee analysis and allocation based on the payment benchmark data. If the request type is a transfer failure adjustment request, and a policy payment member experiences a payment failure due to an incorrect bank card number, then upon receiving a transfer failure adjustment request carrying new bank card information, the new bank card information is used as the target payment account information, and the payment processing for the unsuccessful portion continues based on this target payment account information.

[0027] In this embodiment, by acquiring the mixed payment request and the corresponding mixed payment fee, it is possible to be compatible with both the initial payment scenario and the transfer failure adjustment scenario within the same mixed payment processing flow. During the initial payment, the mixed payment fee can be accurately determined based on the insurance task identifier. During the payment failure adjustment, the failure fee can be processed by replacing the payment account information without re-initiating the entire insurance insurance task. This effectively reduces the business blockage risk caused by bank card errors, account abnormalities, or payment channel failures in mixed payments, thereby improving the continuity of the mixed payment process and the efficiency of abnormal handling.

[0028] In step S102 of some embodiments, specifically, based on the mixed payment request, the corresponding target configuration data table is retrieved from the pre-built payment configuration database; wherein, the target configuration data table contains target member bills and payment benchmark data corresponding to multiple policy payment members; wherein, the payment benchmark data includes payment method restriction information, payment priority information and payment ratio information.

[0029] Specifically, the payment configuration database refers to a collection of data tables that pre-store policy maintenance status information, insurance premium allocation rules, member billing information, and payment benchmark relationships.

[0030] Specifically, the target configuration data table refers to the configuration data table that matches the mixed payment request and is used to guide the allocation of this fee; the target configuration data table contains target member bills and payment benchmark data corresponding to multiple policy payment members.

[0031] Furthermore, the target member bill refers to the outstanding fees corresponding to each policy payment member.

[0032] Furthermore, payment benchmark data refers to the data rules used to determine how hybrid payment fees are allocated among multiple policy payment members. This can include payment method restrictions, payment priority information, and payment ratio information. Specifically, payment method restrictions refer to data used to limit the payment channels or account types that policy payment members can use, such as bank card transfers, corporate account deductions, personal bank card deductions, and cash. Payment priority information refers to data used to determine the order in which payments are executed among multiple policy payment members. Payment ratio information refers to data used to determine the proportion of hybrid payment fees allocated among multiple policy payment members.

[0033] For example, in an insurance application scenario, the target member's bill could be that employee A has an outstanding premium of 100 yuan and employee B has an outstanding premium of 1,000 yuan. The payment benchmark data could be 500 yuan. The mixed payment fee is allocated according to the repayment ratio of 1:9 between A and B, and A and B have the same payment priority. The payment method is limited to bank card transfer.

[0034] In this embodiment, based on the hybrid payment request, the corresponding target configuration data table is retrieved from the pre-built payment configuration database. This decouples the fee allocation logic from the fixed program code and allows the payment configuration database to manage it in a rule-based manner, effectively improving the maintainability and business adaptability of hybrid payments.

[0035] like Figure 3 As shown, in some embodiments, the payment benchmark data includes payment method restriction information, payment priority information, and payment ratio information. Step S102 includes, but is not limited to, steps S201 to S202: Step S201: Parse the mixed payment request to obtain the mixed payment policy identifier.

[0036] Step S202: Based on the mixed payment policy identifier and multiple policy payment members, query the payment method restriction information, payment priority information and payment ratio information corresponding to each policy payment member from the payment configuration database.

[0037] In step S201 of some embodiments, specifically, the mixed payment policy identifier refers to the identifier data used to determine the insurance contract, group policy, maintenance task, or billing batch associated with the mixed payment request. The mixed payment identifier may include at least one of the group policy number, maintenance task identifier, billing batch number, insured unit number, and insured member number.

[0038] Specifically, the request message in the mixed payment request can be parsed to extract the maintenance task identifier, group policy number, bill batch number, and policy payment member information. The mixed payment policy identifier can then be determined based on this information. If the mixed payment request carries both the group policy number and the maintenance task identifier, the maintenance task identifier can be used as the mixed payment policy identifier to accurately locate the payment configuration data corresponding to the current maintenance business. If the mixed payment request does not carry the maintenance task identifier, the mixed payment policy identifier can be determined based on both the group policy number and the bill batch number.

[0039] For example, in an insurance application scenario, if a company processes additional insurance for employees A and B, and the mixed payment request carries the group policy number "G001", the policy maintenance task identifier "BQT202406001", and the bill batch number "P001", then after parsing the mixed payment request, the policy maintenance task identifier "BQT202406001" can be identified as the mixed payment policy identifier, and the payment configuration range corresponding to the additional insurance task can be located accordingly.

[0040] In step S202 of some embodiments, specifically, based on the hybrid payment policy identifier, a target configuration data table corresponding to the hybrid payment policy identifier is queried from the payment configuration database. Subsequently, according to the policy payment member field in the target configuration data table, which includes a payment method field, a payment priority field, and a payment ratio field, the payment method restriction information corresponding to each policy payment member is read from the target configuration data table based on the payment method field, the payment priority information corresponding to each policy payment member is read from the target configuration data table based on the payment priority field, and the payment ratio information corresponding to each policy payment member is read from the target configuration data table based on the payment ratio field. If multiple matching records exist in the payment configuration database, the currently valid configuration record can be selected based on the configuration effective time, configuration version number, or business priority.

[0041] For example, if the mixed payment fee is 500 yuan, the server queries the target configuration data table based on the mixed payment policy identifier "BQT202406001" to determine that this payment involves two policyholders, Employee A and Employee B. Employee A's payment method is limited to bank card transfer, WeChat, and Alipay, etc., with a second priority and a payment ratio of 10%. Employee B's payment method is also limited to bank card transfer, WeChat, and Alipay, with a second priority and a payment ratio of 90%.

[0042] In this embodiment, based on the hybrid payment policy identifier and multiple policy payment members, the payment method restriction information, payment priority information, and payment ratio information corresponding to each policy payment member are queried from the payment configuration database. This enables the payment rules for each policy payment member to be uniformly provided by the payment configuration database, avoiding the need to solidify the payment ratio, payment method, and payment order in the program code. This reduces the reliance on fixed code logic to process payment tasks and makes the payment rules configurable and scalable. When the insurance product, policy maintenance task type, or payment undertaking method changes in the future, the configuration content in the payment configuration database can be adjusted to achieve adaptation.

[0043] Steps S201 to S202 enable the mixed payment request to be accurately matched with the payment configuration rules, providing a unified and configurable data basis for subsequent fee parsing and payment allocation operations, and effectively improving the maintainability and business adaptability of the mixed payment rules.

[0044] In step S103 of some embodiments, specifically, the payable amount for each policy payment member is parsed based on multiple payment benchmark data to determine the policy payable amount corresponding to each policy payment member.

[0045] Specifically, policy payment members refer to members who have a billing relationship or expense offsetting relationship in the same insurance task, such as enterprises, individual employees, insured persons, or other entities that bear insurance premiums.

[0046] Specifically, the policy receivables refer to the payment fees that should be allocated to each policy payment member, that is, the fees that each policy payment member should pay in this payment transaction, rather than the target member bills involved in each policy payment member.

[0047] For example, in an insurance application scenario, if the mixed payment fee is 500 yuan and the payment benchmark data is the repayment ratio of A to B as 1:9, then the mixed payment fee of 500 yuan is analyzed according to this ratio, and it is determined that the policy fee payable for A is 50 yuan and the policy fee payable for B is 450 yuan.

[0048] In this embodiment, the payable fees for each policy payment member are analyzed based on multiple payment benchmark data to determine the policy payable fees corresponding to each policy payment member. This can accurately determine the policy payable fees that should be paid by each policy payment member for mixed payment fees, effectively avoiding the situation of incorrect payment fee attribution caused by binding a single entity.

[0049] like Figure 4 As shown, in some embodiments, step S103 includes, but is not limited to, steps S301 to S304: Step S301: Based on the mixed payment fees and the payment ratio information of each policy payment member, the accounts receivable are allocated to obtain the initial accounts receivable corresponding to each policy payment member.

[0050] Step S302: Integrate the initial receivables of each policy payment member to obtain the total initial receivables.

[0051] Step S303: Perform a consistency check on the sum of the mixed payment fees and the initial accounts receivable fees to obtain consistency check data.

[0052] Step S304: If the consistency verification data indicates that the payables of the mixed payment fees are unevenly distributed, then the initial payables of at least one policy payment member are adjusted based on the preset fee adjustment rules to obtain the policy payables corresponding to each policy payment member.

[0053] In step S301 of some embodiments, specifically, the initial chargeable fee refers to the preliminary allocation fee corresponding to each policy payment member, calculated based on the mixed payment fee and payment ratio information.

[0054] For example, in an insurance scenario, if the combined payment fee is 500 yuan and the payment ratio information for employee A and employee B is 1:9, then employee A's initial receivable is 500 × 0.1 = 50 yuan, and employee B's initial receivable is 500 × 0.1 = 450 yuan.

[0055] In step S302 of some embodiments, specifically, the initial total receivables refer to the total amount of initial receivables corresponding to multiple policy payment members. This initial total receivables is used to determine whether the total amount of expenses after the initial allocation is consistent with the mixed payment expenses.

[0056] For example, if employee A's initial receivables are 50 yuan and employee B's initial receivables are 450 yuan, then the sum of the two will give a total initial receivables of 500 yuan. If the policy involves three policy payment members—the company, the individual employee, and the financial unit—and their corresponding initial receivables are 200 yuan, 250 yuan, and 50 yuan respectively, then the total initial receivables will also be 500 yuan.

[0057] In step S303 of some embodiments, specifically, the consistency verification data is used to characterize the uneven distribution of accounts payable for mixed payment fees, or the even distribution of accounts payable for mixed payment fees.

[0058] Specifically, the consistency verification data characterizes the uneven distribution of receivables in mixed payment fees, which may include: inconsistency between the initial total receivables and the mixed payment fees; the sum of the payment ratio information corresponding to each policy payment member not equal to the preset ratio threshold; the initial receivables corresponding to any policy payment member exceeding the payment limit information corresponding to that policy payment member; the initial receivables corresponding to any policy payment member not meeting the liability sharing rules information corresponding to that policy payment member; and the presence of decimal differences in the initial receivables corresponding to each policy payment member.

[0059] Furthermore, the mixed payment costs are compared with the sum of the initial receivables. If the two costs are consistent, and the initial receivables of each policy payment member meet the payment ratio information, payment limit information, and liability sharing rule information, then consistency verification data indicating that the verification has passed is generated. If the two costs are inconsistent, or if there are situations such as the sum of the ratios not equaling the preset ratio threshold, the initial receivables exceeding the payment limit information, the initial receivables not meeting the liability sharing rule information, or the initial receivables having decimal differences, then consistency verification data indicating uneven distribution of receivables is generated.

[0060] For example, if the mixed payment fee is 500 yuan, and the payment ratios of the three policyholders (A, B, and C) are 33.33%, 33.33%, and 33.34% respectively, i.e., A receives 166.65 yuan, B receives 166.65 yuan, and C receives 166.70 yuan, and the initial total payable is 500 yuan, then the consistency verification data indicates that the verification has passed. However, if the payment ratio information for A, B, and C is all 33.33%, and the sum of the ratios is 99.99%, then the consistency verification data indicates that the sum of the payment ratios is not equal to the preset ratio threshold. If, after fee precision processing, A, B, and C are all 166.67 yuan, and the initial total payable is 500.01 yuan, then the consistency verification... The consistency verification data indicates that the total initial receivables are inconsistent with the mixed payment expenses, and there is a decimal difference. If A's payment limit is 160 yuan, while A's initial receivables are 166.65 yuan, then the consistency verification data indicates that the payment limit has been exceeded. For example, since the liability sharing rule information is used to limit the types and scope of expenses borne by policy payment members, if the mixed payment expense of 500 yuan includes a basic premium of 300 yuan and an additional protection fee of 200 yuan, and the liability sharing rule stipulates that the enterprise only bears the basic premium and the individual only bears the additional protection fee, if 50 yuan of the additional protection fee is allocated to the enterprise, then the consistency verification data indicates that the initial receivables do not meet the liability sharing rule information.

[0061] like Figure 5 As shown, in some embodiments, if the consistency verification data indicates an uneven distribution of receivables for mixed payment fees, then step S304 includes, but is not limited to, steps S401 to S404: Step S401: Determine the cost difference between the initial total receivables and the mixed payment costs.

[0062] Step S402: Based on at least one of payment priority information, preset default payment member, and preset payment limit information, determine the member responsible for the shortfall from multiple policy payment members.

[0063] Step S403: Adjust the initial receivables of the member bearing the difference based on the cost difference to obtain the policy receivables corresponding to the member bearing the difference.

[0064] Step S404: Determine the initial receivables of the remaining policy payment members, excluding the members who bear the difference, as the policy receivables corresponding to the remaining policy payment members.

[0065] In step S401 of some embodiments, specifically, the cost difference refers to the difference between the initial total amount of receivables and the mixed payment cost, which is used to characterize whether the initial total amount of receivables is allocated more or less than the mixed payment cost.

[0066] In step S402 of some embodiments, specifically, the difference-bearing member refers to the policy payment member who bears the cost difference adjustment.

[0067] Specifically, the default payment member refers to the payment member pre-configured to bear the fee when there is no specially designated payment entity or the fee cannot be clearly attributed to a certain policy payment member. For example, in a group insurance mixed payment scenario, the enterprise can be the default payment member. If a 10 yuan handling fee is not clearly specified to be borne by the enterprise or the individual employee, the 10 yuan handling fee can be allocated to the enterprise payment entity by default.

[0068] Specifically, the payment cap information refers to the maximum payment amount or the maximum payment ratio that a policy payment member is allowed to bear in this hybrid payment task.

[0069] Specifically, the difference-bearing member can be determined first based on the payment priority information, and the policy payment member with the highest payment priority can be determined as the difference-bearing member. If multiple policy payment members have the same payment priority, the difference-bearing member can be further determined based on the preset default payment member. If the difference adjustment may cause the policy receivables of a certain policy payment member to exceed the payment limit information, that policy payment member can be excluded, and the difference-bearing member can be re-determined from the remaining members.

[0070] For example, among the three policy payment members A, B, and C, A has the highest payment priority, but A's payment limit is 100 yuan, and A's initial receivable is already 100 yuan. If an additional 50 yuan fee difference is needed, then A is not suitable as the difference-bearing member. According to the preset default payment member rules, B can be determined as the difference-bearing member.

[0071] In step S403 of some embodiments, specifically, if the total initial receivables are greater than the mixed payment fee, the fee difference can be deducted from the initial receivables of the member bearing the difference; if the total initial receivables are less than the mixed payment fee, the fee difference can be added to the initial receivables of the member bearing the difference, and the adjusted fee is determined as the policy receivables corresponding to the member bearing the difference.

[0072] In step S404 of some embodiments, specifically, the remaining policy payment member refers to the other policy payment members among the multiple policy payment members besides the member who bears the difference.

[0073] It should be noted that since the remaining policy payment members do not bear the cost difference adjustment, their initial receivables can be directly determined as policy receivables, and the policy receivables of each policy payment member can be re-aggregated to confirm that the final total of policy receivables equals the mixed payment cost.

[0074] Through steps S401 to S404, when there is a difference in the allocation of receivables, the difference can be determined first, and then the member responsible for the difference can be determined according to the payment priority information, the preset default payment member and the preset payment limit information. The initial receivables of the member responsible for the difference can be adjusted in a targeted manner to solve the problem of decimal differences and inconsistencies in cost allocation in the proportional split, so that the final policy receivables are consistent with the mixed payment costs, thereby improving the accuracy of cost allocation results and the consistency of financial processing.

[0075] Through steps S301 to S304, by analyzing the accounts receivable of each policy payment member, the cost-sharing results of each policy payment member can be determined based on the payment benchmark data in the target configuration data table. This reduces the risk of errors in cost allocation, inconsistent payment costs, or unclear billing attribution. Furthermore, the accounts receivable of each policy payment member can be associated with the corresponding target member's bill, which improves the clarity of financial accounting, reconciliation, and settlement processing, and reduces the risk of payment confusion caused by the mixing of corporate and individual payment portions.

[0076] In step S104 of some embodiments, the mixed payment fee is allocated to each target member's bill based on the policy receivables corresponding to each policy payment member.

[0077] Specifically, the allocation payment operation refers to the process of recording the mixed payment fees into or offsetting the corresponding target member's bill according to the policy receivables of each policy payment member, and updating the bill status or bill balance.

[0078] For example, in an insurance application scenario, A's target member bill shows A's premium as 100 yuan, and B's target member bill shows B's premium as 1000 yuan. 50 yuan of the 500 yuan mixed payment fee is used to balance A's bill, and 450 yuan is used to balance B's bill. That is, a 50 yuan allocation payment operation is performed on A's target member bill, updating A's remaining premium from 100 yuan to 50 yuan, and a 450 yuan allocation payment operation is performed on B's target member bill, updating B's remaining premium from 1000 yuan to 550 yuan.

[0079] In this embodiment, based on the policy receivables corresponding to each policy payment member, the mixed payment fee is allocated to each target member's bill, so that the same mixed payment fee can be accurately allocated to multiple target member bills according to the payment benchmark data, realizing the synchronous update of bills of multiple policy payment members and avoiding the incorrect offsetting of the entire fee to a single member's bill.

[0080] like Figure 6 As shown, in some embodiments, step S104 includes, but is not limited to, steps S501 to S504: Step S501: Determine the initial payment order of multiple policy payment members based on the payment priority information corresponding to each policy payment member.

[0081] Step S502: Perform payment order conflict detection between the initial payment order and the preset payment order rules to obtain payment order conflict verification data; wherein, the payment order rules include at least one of the following: payment member priority rules, fixed deduction member priority rules, abnormal payment blocking rules, and crediting order rules.

[0082] Step S503: If the payment order conflict verification data indicates that the initial payment order does not meet the payment order rules, then it is determined that there is a payment order conflict in the initial payment order. Based on the payment order rules, the initial payment order is adjusted to obtain the target payment order.

[0083] Step S504: According to the target payment order, based on the policy receivables corresponding to each policy payment member, the mixed payment fees are allocated and paid to each target member's bill.

[0084] In step S501 of some embodiments, specifically, the initial payment order refers to the payment execution order initially generated based on the payment priority information corresponding to each policy payment member, which is used to indicate the payment sequence among different policy payment members such as enterprises, individuals, and financial units.

[0085] Specifically, multiple policy payment members can be sorted in descending order of payment priority. If multiple policy payment members have the same payment priority, the initial payment order can be further determined based on the policy payment member number, bill generation time, policy payment member type, or preset sorting rules.

[0086] For example, in a group insurance coverage task, the company pays 100 yuan and the individual employee pays 400 yuan. If the target configuration data table sets the company payment member as the first priority and the individual employee payment member as the second priority, then the initial payment order is determined to be company first, then individual. If the individual priorities are the same, the order of individual payments is determined according to the policy payment member number, bill generation time, and policy payment member type.

[0087] In step S502 of some embodiments, specifically, the payment order conflict verification data is used to characterize whether the initial payment order does not meet the payment order rules or meets the payment order rules, wherein the payment order rules include at least one of the payment member priority rules, fixed deduction member priority rules, abnormal payment blocking rules, and crediting order rules.

[0088] Specifically, payment order conflict detection can include at least one of the following: multiple policy payment members correspond to the same payment priority information; the initial payment order of multiple policy payment members is inconsistent with the business payment order corresponding to the policy maintenance task type; the fixed deduction payment member corresponding to the fixed deduction member priority rule is located after the proportional sharing policy payment member; the subsequent policy payment member is triggered when the preceding policy payment member is in a payment failure pending adjustment state; the parallel payment rule is inconsistent with the financial accounting order rule.

[0089] For example, in the scenario of supplementary payment of group insurance premiums, the payment order rule requires that the fixed deduction portion of the enterprise be executed first, and the individual employee's share be executed later. However, if the individual employee is ranked before the enterprise in the initial payment order, it can be determined that the initial payment order does not meet the priority rule of fixed deduction members.

[0090] In step S503 of some embodiments, specifically, the target payment order refers to the final payment execution order obtained after adjustment based on the payment order rules when there is a payment order conflict in the initial payment order.

[0091] In practice, if the payment order conflict verification data indicates that the initial payment order does not meet the payment order rules, then it is determined that there is a payment order conflict in the initial payment order, and the payment order rules corresponding to the conflict type are read. If the conflict is caused by the fixed deduction member not being executed first, then the fixed deduction payment member is adjusted to the previous position. If the conflict is caused by the previous policy payment member being in a payment failure pending adjustment state, then the payment triggering of the subsequent policy payment member is suspended. If the conflict is caused by the inconsistency between the parallel payment rules and the financial accounting order rules, then the parallel payment is adjusted to a serial payment or batch payment that conforms to the financial accounting order.

[0092] For example, if the initial payment order is individual employee, company, and government agency, but the payment order rules require government agency subsidies to be deducted first, followed by company payments, and finally individual employee payments, then the target payment order can be adjusted to government agency, company, and individual employee.

[0093] In step S504 of some embodiments, the fee allocation payment operation refers to the process of recording or offsetting the mixed payment fees into or against the bills of each target member according to the target payment order and based on the policy receivables corresponding to each policy payment member.

[0094] Specifically, based on the target payment order, the system can sequentially read the policy receivables and target member bills corresponding to each policy payment member, and perform payment, offset, or balance update operations on the target member bills corresponding to each policy payment member based on the policy receivables. If a previous policy payment member fails to make a payment, the system can suspend subsequent payments to that previous policy payment member according to the abnormal payment blocking rules, and generate an entry point for adjusting the transfer failure.

[0095] For example, if the target payment order is government agencies, enterprises, and individual employees, and the corresponding policy receivables for government agencies are 50 yuan, for enterprises are 150 yuan, and for individual employees are 300 yuan, then first, 50 yuan will be deducted from the bills of the target members corresponding to government agencies, then 150 yuan will be deducted from the bills of enterprises, and finally 300 yuan will be deducted from the bills of individual employees.

[0096] Through steps S501 to S504, the initial payment order can be determined based on payment priority information. Conflict detection and order adjustment are then performed by combining payment member priority rules, fixed deduction member priority rules, abnormal payment blocking rules, and accounting entry order rules. Finally, the fee allocation payment operation is completed according to the target payment order. This solves the problems of payment order conflicts, the impact of previous payment failures on subsequent processing, and inconsistencies in financial accounting entry order in mixed payments, thereby improving the stability of mixed payment execution and the consistency of accounting settlement.

[0097] like Figure 7As shown, in some embodiments, step S104 may include, but is not limited to, steps S601 to S604: Step S601: Obtain the payment request method of each policy payment member.

[0098] Step S602: Based on the payment method limitation information, perform compatibility verification on the payment methods requested by each policy payment member to obtain payment method compatibility verification data.

[0099] Step S603: If the payment method compatibility verification data indicates that the requested payment method does not meet the payment method limitation information, then it is determined that the requested payment method is incompatible, and candidate payment methods with payment method limitation information are obtained. The target payment method is selected from the candidate payment methods based on the payment priority information.

[0100] Step S604: According to the target payment method, based on the policy receivables corresponding to each policy payment member, the mixed payment fee is allocated and paid separately to each target member's bill.

[0101] In step S601 of some embodiments, specifically, the requested payment method refers to the payment method submitted by each policy payment member in the mixed payment request. The requested payment method may include bank card transfer, corporate account deduction, personal bank card deduction, cash, and Alipay, etc.

[0102] Specifically, the payment method field corresponding to each policy payment member can be read from the mixed payment request, or the requested payment method can be read from the payment application record associated with the policy maintenance task. If a policy payment member does not actively submit a requested payment method, the requested payment method of that policy payment member can be generated based on the default payment method in the payment configuration database.

[0103] In step S602 of some embodiments, specifically, the payment method compatibility verification data refers to data used to characterize whether the requested payment method does not meet the payment method limitation information or whether the requested payment method meets the payment method limitation information.

[0104] Specifically, payment method restrictions can include the payment methods supported by the policy payment members, the payment methods allowed for the policy maintenance task type, payment limit requirements, account signing status requirements, account status requirements, and the scope of support for the financial accounting interface.

[0105] Specifically, the payment method requested by each policy payment member is compared with the corresponding payment method restriction information in the payment configuration database. If the requested payment method is one of the payment methods supported by the policy payment member and meets the requirements of the current policy maintenance task type, single transaction limit, account signing status, account status, and financial accounting interface, then payment method compatibility verification data is generated to indicate compatibility. If any condition is not met, payment method compatibility verification data is generated to indicate incompatibility, and the reason for incompatibility is recorded.

[0106] For example, if an employee requests payment via bank card deduction for a policy charge of 4,500 yuan, but the single transaction limit for that bank card is 3,000 yuan, then the requested payment method does not meet the single transaction limit requirement in the payment method restriction information. Similarly, if a financial entity requests cash payment, but the current group insurance maintenance task only allows transfers from the corporate account, then the requested payment method does not meet the payment method restriction information corresponding to the policy maintenance task type.

[0107] In step S603 of some embodiments, specifically, the candidate payment method refers to one or more payment methods allowed in the payment method limitation information.

[0108] Specifically, the target payment method refers to the payment method that is actually used to execute the payment when the requested payment method is incompatible, selected from the candidate payment methods.

[0109] Specifically, if the payment method compatibility verification data indicates that the requested payment method does not meet the payment method limitation information, it is determined that the requested payment method is incompatible. Candidate payment methods are obtained from the payment method limitation information, and the candidate payment methods are filtered according to payment priority information, payment limit, account signing status, account normal status, and financial accounting interface support to determine the target payment method. If there is no available payment method among the candidate payment methods, a payment method exception information or transfer failure adjustment request is generated.

[0110] Specifically, payment method incompatibility includes at least one of the following: the requested payment method is not one of the payment methods supported by the corresponding policy payment member; the requested payment method does not meet the payment method restriction information corresponding to the policy maintenance task type; the single payment limit of the requested payment method is less than the pending payment fee of the policy payment member; the payment account corresponding to the requested payment method has not completed the signing; the payment account corresponding to the requested payment method is in an abnormal state; or the requested payment method is not supported by the financial accounting interface.

[0111] For example, if an employee requests to pay 450 yuan using Alipay, but the payment method options include bank card deduction and company direct deduction, and bank card deduction has a higher priority than company direct deduction, then further verification will be performed to confirm that the bank card account is registered, the account status is normal, and the single transaction limit is 1,000 yuan. Therefore, bank card deduction will be selected as the target payment method.

[0112] In step S604 of some embodiments, specifically, if the payment is successful, the bill balance and payment status of the target member's bill corresponding to the policy payment member can be updated according to the payment success result. If the payment fails, the reason for the failure can be recorded and a transfer failure adjustment request can be generated so that the payment can continue after the payment account information is replaced.

[0113] For example, employee A's target payment method is bank card deduction, and the policy payment amount is 50 yuan; employee B's target payment method is bank card deduction, and the policy payment amount is 450 yuan. They send deduction instructions of 50 yuan and 450 yuan respectively to the payment channel. If employee A's payment is successful, the target member's bill will be updated from 100 yuan to 50 yuan; if employee B's payment is successful, the target member's bill will be updated from 1000 yuan to 550 yuan.

[0114] Through steps S601 to S604, the allocation and payment operations for multiple entities and multiple bills can be automatically completed under the same insurance task. This better adapts to the business needs of enterprises and employees sharing insurance costs, improves the flexibility of insurance cost payment processing, and reduces manual intervention and task rollback caused by mismatched payment methods, thereby reducing payment process blockage. Furthermore, the basis for splitting mixed payment costs, the splitting objects, and the payment execution objects all have clear data sources, which helps to improve the accuracy and traceability of payment processing. This reduces problems such as unclear payment logic, unclear cost attribution, and difficulty in verifying payment results, thereby improving the execution efficiency of insurance business.

[0115] In some embodiments, the hybrid payment method based on insurance premiums further includes: after the hybrid payment premiums are allocated to each target member's bill, if there is a target member's bill that meets the preset policy activation conditions, the policy maintenance status information is changed from an inactive state to an active state.

[0116] Specifically, policy maintenance status information refers to data used to characterize the current processing status of policy maintenance tasks.

[0117] Specifically, the preset conditions for policy activation may include that all policy fees payable for each policy payment member have been successfully paid, all offset amounts for each target member's bill have been offset, and the payment result has passed financial accounting verification or there are no policy payment members in a state of failed transfer pending adjustment.

[0118] For example, in a group insurance coverage scenario, if the target member bills for all policy payment members have been updated and the policy charges for each policy payment member are consistent with the mixed payment charges, then it can be determined that the target member bills meet the preset policy activation conditions, and the policy maintenance status information is changed from an inactive state to an active state.

[0119] In this embodiment, by updating the policy status information after the payment allocation operation based on whether the target member's bill meets the preset policy activation conditions, it is possible to ensure that the policy status change is consistent with the mixed payment result, and avoid prematurely triggering the policy activation in the event of partial payment failure or partial bill unbalanced accounts, thereby improving the consistency of funds and business compliance in insurance expense processing.

[0120] As can be seen, in the above scheme, by obtaining the mixed payment request and the corresponding mixed payment fee, and retrieving the corresponding target configuration data table from the pre-built payment configuration database based on the mixed payment request, the target configuration data table contains target member bills and payment benchmark data corresponding to multiple policy payment members; further, based on the multiple payment benchmark data, the accounts receivable of each policy payment member are parsed to determine the policy accounts receivable corresponding to each policy payment member; and then, based on the policy accounts receivable corresponding to each policy payment member, the mixed payment fee is allocated to each target member bill for payment operations. In this application, a pre-built payment configuration database is used to perform configurable matching of mixed payment requests, and the payment benchmark data in the target configuration data table is used to parse the payable fees of different policy payment members. This enables the policy maintenance business processing system to split the mixed payment fees into multiple target member bills and execute payment processing separately based on different payment entities, different member bills, and different fee-sharing rules. This effectively solves the problem of difficulty in completing fee allocation and payment execution separately for different payment entities, avoids interruption of insurance business processes, improves the accuracy of fee allocation and payment execution flexibility in multi-payer insurance tasks, and thus improves the payment adaptability and overall execution efficiency of insurance business.

[0121] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0122] Please see Figure 8 This application also provides a hybrid payment device based on insurance premiums, which can implement the above-mentioned hybrid payment method based on insurance premiums. The device includes: The mixed payment request and fee acquisition module is used to acquire the mixed payment request and the mixed payment fee corresponding to the mixed payment request; The configuration data table acquisition module is used to retrieve the corresponding target configuration data table from the pre-built payment configuration database based on the mixed payment request; the target configuration data table contains the target member bills and payment benchmark data corresponding to multiple policy payment members; The accounts receivable parsing module is used to parse the accounts receivable for each policy payment member based on multiple payment benchmark data, so as to determine the policy accounts receivable corresponding to each policy payment member. The mixed payment operation module is used to allocate and pay the mixed payment fees to the bills of each target member based on the policy receivables of each policy payment member.

[0123] In one embodiment, the payment benchmark data in the configuration data table acquisition module includes payment method restriction information, payment priority information, and payment ratio information, specifically used for: The mixed payment request is parsed to obtain the mixed payment policy identifier; Based on the hybrid payment policy identifier and multiple policy payment members, the payment method restriction information, payment priority information and payment ratio information corresponding to each policy payment member are queried from the payment configuration database.

[0124] In one embodiment, the account fee parsing module is specifically used for: Based on the mixed payment fees and the payment ratio information of each policy payment member, the accounts receivable are allocated to obtain the initial accounts receivable corresponding to each policy payment member; The initial receivables of each policy payment member are consolidated to obtain the total initial receivables; The sum of the mixed payment fees and the initial receivable fees is subjected to a consistency check to obtain consistency check data; If the consistency verification data indicates that the payables of the mixed payment fees are unevenly distributed, the initial payables of at least one policy payment member will be adjusted based on the preset fee adjustment rules to obtain the policy payables corresponding to each policy payment member.

[0125] In one embodiment, the account fee parsing module is further specifically used for: Determine the cost difference between the initial total receivables and the mixed payment costs; Based on at least one of payment priority information, preset default payment members, and preset payment limit information, determine the member responsible for bearing the difference from multiple policy payment members; The initial receivables of the member bearing the difference are adjusted based on the difference in costs to obtain the policy receivables corresponding to the member bearing the difference. The initial receivables of the remaining policy payment members, excluding the members who bear the difference, are determined as the policy receivables corresponding to the remaining policy payment members.

[0126] In one embodiment, the hybrid payment operation module is specifically used for: Based on the payment priority information corresponding to each policy payment member, the initial payment order of multiple policy payment members is determined; The initial payment order is compared with the preset payment order rules to detect payment order conflicts and obtain payment order conflict verification data; wherein, the payment order rules include at least one of the following: payment member priority rules, fixed deduction member priority rules, abnormal payment blocking rules, and crediting order rules; If the payment order conflict verification data indicates that the initial payment order does not meet the payment order rules, then it is determined that there is a payment order conflict in the initial payment order. Based on the payment order rules, the initial payment order is adjusted to obtain the target payment order. Based on the target payment order and the policy receivables corresponding to each policy payment member, the mixed payment fees are allocated and paid separately to each target member's bill.

[0127] In one embodiment, the hybrid payment operation module is further specifically used for: Obtain the payment requests from each policyholder; Based on the payment method restriction information, the compatibility of the payment methods requested by each policy payment member is verified to obtain payment method compatibility verification data; If the payment method compatibility verification data indicates that the requested payment method does not meet the payment method limitation information, then it is determined that the requested payment method is incompatible, and candidate payment methods with payment method limitation information are obtained. The target payment method is then selected from the candidate payment methods based on the payment priority information. Based on the target payment method, and according to the policy receivables of each policy payment member, the mixed payment fees are allocated and paid separately to the bills of each target member.

[0128] In one embodiment, the payment configuration database in the hybrid payment device based on insurance premiums stores policy maintenance status information and further includes: After the mixed payment fees are allocated to each target member's bill, if a target member's bill for a policy payment member meets the preset policy activation conditions, the policy maintenance status information will be changed from an inactive state to an active state.

[0129] Specific limitations regarding the hybrid payment device based on insurance premiums can be found in the limitations of the hybrid payment method based on insurance premiums mentioned above, and will not be repeated here. Each module in the aforementioned hybrid payment device based on insurance premiums can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in a computer device in hardware form, or stored in the memory of a computer device in software form, so that the processor can call and execute the corresponding operations of each module.

[0130] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 9 As shown. The computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements the functions or steps of a hybrid payment method based on insurance premiums on the server side.

[0131] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 10 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When executed by the processor, the computer program implements client-side functions or steps of a hybrid payment method based on insurance premiums.

[0132] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Obtain the mixed payment request and the corresponding mixed payment fee; Based on the mixed payment request, the corresponding target configuration data table is retrieved from the pre-built payment configuration database; the target configuration data table contains target member bills and payment benchmark data corresponding to multiple policy payment members; Based on multiple payment benchmark data, the payables for each policy payment member are analyzed to determine the policy payables corresponding to each policy payment member; Based on the policy receivables of each policy payment member, the mixed payment fees are allocated and paid to each target member's bill.

[0133] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor: Obtain the mixed payment request and the corresponding mixed payment fee; Based on the mixed payment request, the corresponding target configuration data table is retrieved from the pre-built payment configuration database; the target configuration data table contains target member bills and payment benchmark data corresponding to multiple policy payment members; Based on multiple payment benchmark data, the payables for each policy payment member are analyzed to determine the policy payables corresponding to each policy payment member; Based on the policy receivables of each policy payment member, the mixed payment fees are allocated and paid to each target member's bill.

[0134] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0135] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0136] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0137] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0138] The above embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A hybrid payment method based on insurance premiums, characterized in that, include: Obtain the mixed payment request and the mixed payment fee corresponding to the mixed payment request; Based on the hybrid payment request, the corresponding target configuration data table is retrieved from the pre-built payment configuration database; wherein, the target configuration data table contains target member bills and payment benchmark data corresponding to multiple policy payment members; Based on multiple payment benchmark data, the payable amount for each policy payment member is analyzed to determine the policy payable amount corresponding to each policy payment member; Based on the policy receivables corresponding to each policy payment member, the mixed payment fees are allocated and paid to each target member's bill.

2. The method according to claim 1, characterized in that, The payment benchmark data includes payment method restriction information, payment priority information, and payment ratio information; The step of retrieving the corresponding target configuration data table from the pre-built payment configuration database based on the hybrid payment request includes: The mixed payment request is parsed to obtain the mixed payment policy identifier; Based on the hybrid payment policy identifier and multiple policy payment members, the payment method restriction information, payment priority information, and payment ratio information corresponding to each policy payment member are queried from the payment configuration database.

3. The method according to claim 2, characterized in that, The step of parsing the payable charges for each policy payment member based on multiple payment benchmark data to determine the policy payable charges corresponding to each policy payment member includes: Based on the mixed payment fee and the payment ratio information of each policy payment member, the accounts receivable are allocated to obtain the initial accounts receivable corresponding to each policy payment member; The initial receivables of each policy payment member are integrated to obtain the total initial receivables; The sum of the mixed payment fee and the initial receivable fee is subjected to a consistency check to obtain consistency check data; If the consistency verification data indicates that the payable amount of the mixed payment is unevenly distributed, then the initial payable amount of at least one of the policy payment members is adjusted based on the preset fee adjustment rules to obtain the policy payable amount corresponding to each of the policy payment members.

4. The method according to claim 3, characterized in that, The adjustment of the initial receivables for at least one of the policy payment members based on the preset fee adjustment rules, to obtain the policy receivables corresponding to each of the policy payment members, includes: Determine the cost difference between the initial total receivables and the mixed payment costs; Based on at least one of the payment priority information, the preset default payment member, and the preset payment limit information, the member responsible for bearing the difference is determined from among the multiple policy payment members; The initial receivables of the member bearing the difference are adjusted based on the difference to obtain the policy receivables corresponding to the member bearing the difference. The initial receivables of the remaining policy payment members, excluding the member who bears the difference, are determined as the policy receivables corresponding to the remaining policy payment members.

5. The method according to claim 2, characterized in that, The process of allocating the mixed payment fees to each target member's bill based on the policy receivables corresponding to each policy payment member includes: Based on the payment priority information corresponding to each of the policy payment members, the initial payment order of the multiple policy payment members is determined; The initial payment order is compared with the preset payment order rules to detect payment order conflicts, thereby obtaining payment order conflict verification data; wherein, the payment order rules include at least one of the following: payment member priority rules, fixed deduction member priority rules, abnormal payment blocking rules, and crediting order rules; If the payment order conflict verification data indicates that the initial payment order does not meet the payment order rule, then it is determined that there is a payment order conflict in the initial payment order, and the initial payment order is adjusted based on the payment order rule to obtain the target payment order; According to the target payment order, based on the policy receivables corresponding to each policy payment member, the mixed payment fee is allocated and paid to each target member's bill.

6. The method according to claim 2, characterized in that, The method of allocating the mixed payment fee to each target member's bill based on the policy receivables corresponding to each policy payment member also includes: Obtain the payment request method for each of the aforementioned policy payment members; Based on the payment method limitation information, the compatibility of the requested payment method of each policy payment member is verified to obtain payment method compatibility verification data; If the payment method compatibility verification data indicates that the requested payment method does not meet the payment method limitation information, then it is determined that the requested payment method is incompatible, and candidate payment methods with the payment method limitation information are obtained. Based on the payment priority information, the target payment method is selected from the candidate payment methods. According to the target payment method, based on the policy receivables corresponding to each policy payment member, the hybrid payment fee is allocated and paid to each target member's bill.

7. The method according to any one of claims 1 to 6, characterized in that, The payment configuration database stores policy maintenance status information. After the process of allocating the mixed payment fees to each target member's bill based on the policy receivables corresponding to each policy payment member, the process further includes: After the mixed payment fee is allocated to each of the target member bills, if any of the target member bills of the policy payment member meets the preset policy activation conditions, the policy maintenance status information is changed from an inactive state to an active state.

8. A hybrid payment device based on insurance premiums, characterized in that, The device includes: A mixed payment request and fee acquisition module is used to acquire a mixed payment request and a mixed payment fee corresponding to the mixed payment request; The configuration data table acquisition module is used to retrieve the corresponding target configuration data table from a pre-built payment configuration database based on the hybrid payment request; wherein, the target configuration data table contains target member bills and payment benchmark data corresponding to multiple policy payment members; The accounts receivable parsing module is used to perform accounts receivable parsing on each of the policy payment members based on multiple payment benchmark data, so as to determine the policy accounts receivable corresponding to each of the policy payment members; The hybrid payment operation module is used to allocate the hybrid payment fees to each of the target member's bills based on the policy receivables corresponding to each policy payment member.

9. A computer device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the hybrid payment method based on insurance premiums as described in any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program, characterized in that, When the computer program is executed by a processor, it implements the steps of the hybrid payment method based on insurance premiums as described in any one of claims 1 to 7.

Images