Payment method, device, equipment and storage medium

Abstract

The embodiments of the present invention provide a payment method, device, equipment and storage medium. The method includes: obtaining a user ID for ordering a service, and a payment relationship corresponding to the user ID; parsing first payment information in the payment relationship, the first payment information including the user ID and the user ID to be paid; determining a target payment model corresponding to the payment relationship in at least one payment model according to the first payment information; and performing payment according to the target payment model and the first payment information. Through the embodiments of the present invention, the processing volume of call bills can be reduced, the transformation volume of a large number of call bill types can be simplified, and the efficiency of payment processing and user experience can be improved.

Description

Technical Field

[0001] The present invention relates to the field of communication technology, and in particular to a payment method, device, equipment and storage medium. Background Art

[0002] In the communications industry, telecommunications services were previously sold to users as independent products, such as mobile phone IDs, fixed-line IDs, broadband, and dedicated lines. The services provided by these products were relatively simple. With the integration of the telecommunications network, the Internet, and cable TV networks, mobile value-added services have developed rapidly, and the number of proprietary, personalized, and diversified products for groups and families has become increasingly rich. The relationship between products has become increasingly close, and products have gradually developed from a single product to a combination. Therefore, in the face of various requirements for integrated products, payment on behalf of others is more prominent in aggregated groups such as families and groups.

[0003] At present, traditional payment solutions mainly include bill payment solutions and bill payment solutions. However, for bill payment solutions, each new type of bill or billing collection source must be transformed and modified in the business support system, and the implementation process is not flexible. In addition, the bill volume of the bill payment solution is too large, and it is difficult to support bill query, account cancellation, invoice and other services in real time. In summary, the traditional payment solution has low payment processing efficiency and poor user experience. Summary of the invention

[0004] The embodiments of the present invention provide a payment method, device, equipment and storage medium, which can reduce the processing volume of call bills, simplify the transformation volume of a large number of call bill types, and improve the payment processing efficiency and user experience.

[0005] In a first aspect, an embodiment of the present invention provides a payment method, the method comprising:

[0006] Obtaining the user ID of the subscription service and the payment relationship corresponding to the user ID;

[0007] Parsing the first payment information in the payment relationship, the first payment information including the user ID and the ID of the user to be paid;

[0008] Determining, according to the first payment information, a target payment model corresponding to the payment relationship in at least one payment model;

[0009] Payment is made according to the target payment model and the first payment information.

[0010] In some implementations of the first aspect, the method further includes:

[0011] Get the address code of the payment model where the user ID is located;

[0012] Wherein, obtaining the payment relationship corresponding to the user identifier includes:

[0013] Automatically address according to the address code and determine the payment relationship corresponding to the user ID.

[0014] In some implementations of the first aspect, parsing the first payment information in the payment relationship includes:

[0015] When the payment relationship is a multi-level payment relationship, the multi-level payment relationship is resolved into a basic payment relationship, and the basic payment relationship is a payment relationship including a user ID and an ID of the user to be paid;

[0016] The second payment information in the basic payment relationship is parsed, and the second payment information is used as the first payment information.

[0017] In some implementations of the first aspect, determining, according to the first payment information, a target payment model corresponding to the payment relationship in at least one payment model includes:

[0018] Get the number of bills for the user ID to be paid in the specified time period;

[0019] A target payment model is determined in at least one payment model according to the bill quantity and a preset quantity threshold.

[0020] In some implementations of the first aspect, the first payment information also includes a payment amount.

[0021] In some implementable embodiments of the first aspect, the target payment model includes any one of a call bill payment model, a product payment model, a real-time payment model, a combined account payment model, and a bill payment model.

[0022] In some implementations of the first aspect, after performing the payment according to the target payment model and the first payment information, the method further includes:

[0023] Determine at least one type of bill according to the payment result and at least one type of preset storage format;

[0024] Get the bill call request sent by the application device;

[0025] Determining a target bill corresponding to the bill call request from at least one type of bills;

[0026] The target bill is sent to the application device so that the application device displays the target bill to the user.

[0027] In a second aspect, an embodiment of the present invention provides a payment device, the device comprising:

[0028] An acquisition module, used to acquire a user ID for ordering services and a payment relationship corresponding to the user ID;

[0029] A parsing module, used for parsing first payment information in the payment relationship, where the first payment information includes a user ID and a user ID to be paid;

[0030] A determination module, configured to determine, according to the first payment information, a target payment model corresponding to the payment relationship in at least one payment model;

[0031] The payment module is used to perform payment according to the target payment model and the first payment information.

[0032] In some implementations of the second aspect, the acquisition module is further used to acquire an address code of the payment model where the user identifier is located;

[0033] The acquisition module is specifically used for automatically addressing according to the address code and determining the payment relationship corresponding to the user identification.

[0034] In some implementations of the second aspect, the parsing module includes: a first parsing unit, configured to, when the agency payment relationship is a multi-level agency payment relationship, parse the multi-level agency payment relationship into a basic agency payment relationship, the basic agency payment relationship being an agency payment relationship including a user identifier and an identifier of a user to be paid;

[0035] The second parsing unit is used to parse the second payment information in the basic payment relationship and use the second payment information as the first payment information.

[0036] In some implementations of the second aspect, the determination module includes: an acquisition unit, configured to acquire the number of bills of the to-be-paid user identifier in a specified time period;

[0037] A determination unit is used to determine a target payment model in at least one payment model according to the bill quantity and a preset quantity threshold.

[0038] In some implementations of the second aspect, the first payment information also includes a payment amount.

[0039] In some implementable embodiments of the second aspect, the target payment model includes any one of a call bill payment model, a product payment model, a real-time payment model, a joint account payment model, and a bill payment model.

[0040] In some implementations of the second aspect, the determination module is further configured to determine at least one type of bill according to the payment result and at least one type of preset storage format after performing payment according to the target payment model and the first payment information;

[0041] The acquisition module is also used to obtain the bill call request sent by the application device;

[0042] The determination module is further used to determine a target bill corresponding to the bill call request in at least one type of bill;

[0043] The device also includes: a sending module, which is used to send the target bill to the application device, so that the application device can display the target bill to the user.

[0044] In a third aspect, an embodiment of the present invention provides a payment device, the device comprising: a processor and a memory storing computer program instructions;

[0045] When the processor executes the computer program instructions, the payment method described in the first aspect or any implementable manner of the first aspect is implemented.

[0046] In a fourth aspect, an embodiment of the present invention provides a computer-readable storage medium having computer program instructions stored thereon, which, when executed by a processor, implement the payment method described in the first aspect or any implementable manner of the first aspect.

[0047] A payment method, device, equipment and storage medium provided by an embodiment of the present invention obtain a user identifier of a subscription service and a payment relationship corresponding to the user identifier, that is, obtains the payment relationship to be processed, then parses the first payment information in the payment relationship, and determines a target payment model corresponding to the payment relationship in at least one payment model based on the first payment information, determines a payment model suitable for processing the payment relationship, and then performs payment based on the target payment model and the first payment information. The payment model for processing the payment relationship can be flexibly selected, and the payment information of the payment relationship can be processed based on the payment model, thereby reducing the processing volume of call bills, reducing implementation costs and prices, simplifying the transformation volume of a large number of call bill types, and improving payment processing efficiency and user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0048] In order to more clearly illustrate the technical solution of the embodiment of the present invention, the following briefly introduces the drawings required for use in the embodiment of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0049] Figure 1 It is a schematic diagram of a payment model provided by the relevant technology;

[0050] Figure 2 It is a schematic diagram of a payment model provided by an embodiment of the present invention;

[0051] Figure 3 This is a schematic diagram of a payment engine provided by an embodiment of the present invention;

[0052] Figure 4 It is a flowchart of a payment method provided by an embodiment of the present invention;

[0053] Figure 5This is a schematic diagram of a payment relationship provided by an embodiment of the present invention;

[0054] Figure 6 is another schematic diagram of payment relationship provided by an embodiment of the present invention;

[0055] Figure 7 This is a schematic diagram of a bill provided by an embodiment of the present invention;

[0056] Figure 8 This is a schematic diagram of obtaining a payment relationship provided by an embodiment of the present invention;

[0057] Fig. 9 This is a schematic diagram of a bill call provided by an embodiment of the present invention;

[0058] Fig.10 is a schematic diagram of the structure of a payment device provided by an embodiment of the present invention;

[0059] Fig.11 It is a schematic diagram of the hardware structure of a payment agent device provided in an embodiment of the present invention. DETAILED DESCRIPTION

[0060] The features and exemplary embodiments of various aspects of the present invention will be described in detail below. In order to make the purpose, technical solutions and advantages of the present invention clearer, the present invention will be further described in detail below in conjunction with the accompanying drawings and Examples. It should be understood that the specific embodiments described herein are only configured to explain the present invention and are not configured to limit the present invention. For those skilled in the art, the present invention can be implemented without the need for some of these specific details. The following description of the embodiments is only to provide a better understanding of the present invention by illustrating examples of the present invention.

[0061] It should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the statement "include..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0062] Based on the background technology part, it can be known that traditional payment solutions mainly include call bill payment solutions and bill payment solutions. Among them, the call bill payment solution is implemented based on the call bill payment model, and the bill payment solution is implemented based on the bill payment model.

[0063] like Figure 1 As shown, the business support system can be used to perform billing collection, bill exchange preprocessing, billing batch pricing, billing calculation and other operations to obtain detailed bills and bills. Among them, the bill payment model is a payment model that acts on the bill preprocessing link. According to the payment relationship, the user ID (such as mobile phone number) of the subscription service is directly replaced with the user ID to be paid to complete the payment relationship conversion. This method does not involve complex processing of the business support system logic. The payment can be completed through the conversion operation of the ID, which has no impact on the subsequent batch pricing, billing and other processes, and does not require any adjustments.

[0064] The bill payment model is a payment model used in the bill calculation link. According to the user's payment relationship, the user ID's fees are directly recorded in the account of the user ID to be paid, forming the bill of the user ID to be paid, that is, the payment relationship conversion is completed when the bill is generated. The call record still belongs to the user ID, only the bill is paid by the user ID to be paid. The user ID can query the payment status of the user ID to be paid and can participate in the discount of the user ID to be paid. The bill payment model acts on the last link of payment, has high flexibility, and is suitable for the needs of various business scenarios.

[0065] However, the bill payment model processes bill records, which is not flexible enough. The reason is that the bill payment model needs to convert all bills, and there are about thousands of bill types for billing at present, and the bill collection sources are very many, such as switches, gateways, group billing platforms, third-party platforms, etc. If each type of bill is modified, the cost of transforming the business support system is very high, and each new type of bill or billing collection source requires the transformation and modification of the business support system. The implementation process is not flexible and the configurability is not strong. Therefore, the bill payment model is only suitable for businesses with relatively single payment types, such as traffic bill payment, etc.

[0066] The bill payment model realizes the payment relationship through account items, and the configuration is complex. For example, to realize the payment of product services, the payment relationship of all account items involved in the product services must be configured and managed. Once the tariff model of the product services is adjusted, the payment relationship needs to be refreshed and adjusted again, so the configuration management is very complex and inconvenient. In addition, since the bill payment model needs to record the field information such as the user ID to be paid and the user ID on the bill at the same time, it is easy to generate a large number of bills. It is difficult to support the query, cancellation, invoice and other services of the bill in real time, and the payment processing efficiency is low.

[0067] In order to solve the problems of the prior art, the embodiments of the present invention provide a payment method, device, equipment and storage medium. Obtain the user identification of the subscription service and the payment relationship corresponding to the user identification, that is, obtain the payment relationship to be processed, then parse the first payment information in the payment relationship, and determine the target payment model corresponding to the payment relationship in at least one payment model according to the first payment information, determine the payment model suitable for processing the payment relationship, and then make payment according to the target payment model and the first payment information, so that the payment model for processing the payment relationship can be flexibly selected, and the payment information of the payment relationship can be processed based on the payment model, thereby reducing the processing volume of call bills, reducing implementation costs and prices, simplifying the transformation of a large number of call bill types, and improving the efficiency of payment processing and user experience.

[0068] Since the payment method provided in the embodiment of the present invention involves at least one payment model, the payment model involved in the embodiment of the present invention is first introduced below.

[0069] In some embodiments, the payment model may include at least one of a call bill payment model, a product payment model, a real-time payment model, a combined account payment model, and a bill payment model.

[0070] Among them, the product payment model is a payment model that acts on the product service tariff subscription, for example, it can be used for the payment of video traffic package services. As an example, when subscribing to a product service, the user can set the payment user ID, that is, the user number for which the payment is made, and information such as the payment amount, and this information is used to generate a payment relationship. The product payment model can record the product ordering information, that is, the ordering relationship and the information set by the user, and generate the payment relationship corresponding to the user ID of the subscription service based on the information set by the user. When performing fixed fee calculations, it is checked whether there is a payment relationship with the user ID. If there is a payment relationship, the payment relationship is directly associated with the ordering relationship, and a fixed fee file of the payment user ID is generated, which is used for subsequent billing calculations after the call bill is standardized. Among them, the fixed fee file is a new type of fixed fee file, which can be distinguished by its call bill type.

[0071] The real-time payment model is a payment model used when ordering real-time services. As an example, when ordering a value-added service, a user can set the payment user ID and payment amount. The real-time payment model can record product ordering information, i.e., ordering relationship, and user-set information, and generate a payment relationship corresponding to the user ID based on the user-set information. According to the payment relationship and ordering relationship, the ordering service data is scanned in real time, and a payment list file is generated in real time for later billing calculation after the call sheet is standardized.

[0072] The joint account payment model is a payment model used when the call bill is standardized. As an example, the joint account payment model can handle payment for any business and form a payment record based on the payment relationship. When the call bill is standardized, the user ID of the payment record is directly replaced with the payment user ID for later billing calculation.

[0073] As an example, Figure 2 As shown, the payment model may include a bill payment model, a product payment model, a real-time payment model, a joint account payment model, and a bill payment model. The bill payment model, the product payment model, the real-time payment model, the joint account payment model, and the bill payment model may be implemented by a server or a server cluster.

[0074] Among them, the bill payment model, product payment model, real-time payment model, joint account payment model, and bill payment model can be integrated with each other to make up for each other's shortcomings and deficiencies in the model. Specifically, the bill payment model, product payment model, and real-time payment model can be used as the first-level payment model, which belongs to the payment model of the business support system at the bill layer and business layer. The information it outputs is temporary transitional data for payment, providing basic data for the final bill. The joint account payment model can be used as the second-level payment model, which is a payment model after the first-level payment model. Its input information is all types of bill fee data, and its output information is standardized bill calculation and usage data. The bill payment model can be used as the third-level payment model to generate the final payment bill.

[0075] It is worth noting that the payment method provided in the embodiment of the present invention can be applied to a payment device, which can include a payment engine, such as Figure 3 As shown, the payment engine can establish communication connections with the call bill payment model, product payment model, real-time payment model, joint account payment model, and bill payment model.

[0076] The payment engine can be used to obtain the payment relationship corresponding to the user identifier, determine a target payment model suitable for processing the payment relationship in at least one payment model according to the payment relationship, and perform payment based on the payment model and the payment information in the payment relationship. Optionally, the payment engine can be implemented by a server or a server cluster.

[0077] The following is an introduction to the payment method provided by an embodiment of the present invention. The payment method can be applied to Figure 3 The payment engine shown.

[0078] Figure 4 is a flow chart of a payment method provided by an embodiment of the present invention, such as Figure 4 As shown, the payment method may include S410 to S440.

[0079] S410, obtaining a user ID for ordering a service and a payment relationship corresponding to the user ID.

[0080] In some embodiments, the user identification can be obtained from the payment model, wherein the payment model can be a bill payment model, a product payment model, a real-time payment model, a joint account payment model, or a bill payment model. In addition, the address code of the payment model can be obtained, and the address can be automatically searched according to the address code to determine the payment relationship corresponding to the user identification.

[0081] S420, parsing the first payment information in the payment relationship.

[0082] The first payment information may include a user ID and a user ID to be paid corresponding to the user ID. Optionally, it may also include at least one of a payment amount, payment fee, fee category, and service information.

[0083] In some embodiments, when the payment relationship is a basic payment relationship, the second payment information in the basic payment relationship can be directly parsed and used as the first payment information. The basic payment relationship is a payment relationship including a user identifier and a user identifier to be paid, that is, a payment relationship without an intermediate payment relationship.

[0084] Optionally, when the agency payment relationship is a multi-level agency payment relationship, the multi-level agency payment relationship can be parsed into a basic agency payment relationship, the second agency payment information in the basic agency payment relationship can be parsed, and the second agency payment information can be used as the first agency payment information. By parsing the complex multi-level agency payment relationship into the basic agency payment relationship and using the basic agency payment relationship for subsequent agency payment processing, the agency payment efficiency can be improved.

[0085] As an example, Figure 5 As shown in the figure, user A is paid by user B, which is the first-level payment relationship, user B is paid by user C, which is the second-level payment relationship, and user C is paid by user D, which is the third-level payment relationship. After analysis, the basic payment relationship can be obtained, such as Figure 6 As shown, users A, B, and C are paid by user D.

[0086] S430: Determine, based on the first payment information, a target payment model corresponding to the payment relationship in at least one payment model.

[0087] Among them, the target payment model can include any one of a call bill payment model, a product payment model, a real-time payment model, a combined account payment model, and a bill payment model.

[0088] In some embodiments, the number of bills of the to-be-paid user ID in a specified time period can be obtained, and a target payment model can be determined in at least one payment model according to the number of bills and a preset number threshold. The preset number threshold can include multiple ones and can be flexibly adjusted according to actual conditions, which is not limited here.

[0089] S440, performing payment according to the target payment model and the first payment information.

[0090] In some embodiments, the first payment information may be sent to a target payment model, and the target payment model may perform relevant payment processing according to the first payment information.

[0091] In an embodiment of the present invention, a user identifier of a subscription service and a payment relationship corresponding to the user identifier are obtained, that is, the payment relationship to be processed is obtained, and then the first payment information in the payment relationship is parsed, and based on the first payment information, a target payment model corresponding to the payment relationship is determined in at least one payment model, and a payment model suitable for processing the payment relationship is determined, and then payment is performed based on the target payment model and the first payment information. The payment model for processing the payment relationship can be flexibly selected, and the payment information of the payment relationship is processed based on the payment model, thereby reducing the processing volume of call bills, reducing implementation costs and prices, simplifying the transformation volume of a large number of call bill types, and improving payment processing efficiency and user experience.

[0092] Since issued bills are generally followed by business operations such as payment, account closing, inquiry, balance inquiry, bill audit, bill storage and withdrawal, these business operations require frequent bill calls and access. In the case of multiple business operations, such as large-scale payment of bills, the response speed becomes very slow, affecting the business perception and service capabilities.

[0093] Therefore, in some embodiments, after performing the payment on behalf of another according to the target payment model and the first payment on behalf of another, the payment on behalf of another method may further include the following steps:

[0094] At least one type of bill is determined based on the payment result and at least one type of preset storage format. Specifically, the bill calculation can be performed based on the payment result, and the bill calculation result can be separated using at least one type of preset storage format and data redundancy to obtain at least one type of bill.

[0095] Get the bill call request sent by the application device, where the application device can be a mobile phone, tablet computer, laptop computer and other devices.

[0096] The target bill corresponding to the bill call request is determined in at least one type of bill, and the target bill is sent to the application device so that the application device can display the target bill to the user. By separating multiple types of bills, the storage fields are reduced, the number of bills is reduced, and the number of bills read and processed during business operations such as query and credit control is greatly reduced. At the same time, calling a bill through a bill call request can simplify the complexity of bill call execution and improve bill call efficiency.

[0097] As an example, Figure 7 As shown, by calculating the outgoing bills for the payment results, three types of bills, namely, outgoing bills, write-off bills and payment bills, are obtained by separation according to three storage formats.

[0098] Among them, the billing invoice has the largest amount of bills, and the data is stored in the structure of detailed fields such as user ID, payment user ID, billing status, etc. It is a detailed bill and is used for business operations such as income calculation, auditing, extraction, and transfer.

[0099] The amount of bills for write-off invoices is relatively small, and data is stored in a structure of detailed fields such as user ID, account item, and expense, and is used to connect to business operations such as payment, write-offs, balance calculation, and credit control.

[0100] The bill volume of bill payment on behalf of others is the smallest, and data is mainly stored in the structure of user identification, account items, and ledgers for query and other business operations.

[0101] The following is a description of the payment method provided by the embodiment of the present invention in conjunction with a specific embodiment, which is as follows:

[0102] like Figure 8 As shown, the payment engine establishes communication connections with multiple payment models, obtains address codes, user identifiers, payment fees and other information from the payment models, and automatically searches for addresses based on the address codes to find the payment relationship corresponding to the user identifier.

[0103] The payment relationship is parsed to obtain the first payment information including the user ID, the ID of the user to be paid, the payment limit, the payment fee, the fee category and the business information. The number of bills of the user ID to be paid in a specified time period is obtained, and the target payment model for processing the payment relationship is determined according to the number of bills and a preset number threshold.

[0104] The first payment information is fed back to the target payment model, and the target payment model performs relevant payment processing based on the first payment information. After the processing is completed, the payment result is fed back to the payment engine, and the payment engine adjusts the payment relationship of the payment model based on the payment result for subsequent use.

[0105] Optionally, the payment engine can also provide maintenance configuration capabilities, manage payment relationships, adjust the priority of payment relationships, achieve personalized customization, and achieve the ability to pause and enable payment.

[0106] In addition, after obtaining the payment result, the payment result is calculated and separated into three types of bills according to three storage formats: payment bills, cancellation bills and payment bills. Each type of bill is managed by the corresponding bill cluster.

[0107] like Fig. 9 As shown, another part of the payment device (bill scheduling engine) can periodically detect the host status of each bill cluster (billing cluster for issuing bills, billing cluster for cancelling bills, and billing cluster for payment), and is responsible for collecting information such as the activity status of the hosts of each bill cluster to ensure the availability of the hosts, and record the detection results, such as bill cluster, bill type, host identity document (ID), availability, activity status, number of connections, and other information in the host registration table.

[0108] The billing cluster information retrieved by each application device, such as application device ID, billing cluster, account hash, etc., is recorded in the application registration table.

[0109] When the application device calls, it passes the module application device ID, account number, operation type, operation statement and other information to the bill scheduling engine.

[0110] The bill scheduling engine determines the cluster to be called based on the incoming application device ID, and then allocates the available hosts based on the number of host connections and activity status in the host registration table, and executes the application operation statement. The bill scheduling engine feeds back the results of the statement execution to the corresponding application device.

[0111] Optionally, the bill scheduling engine also manages the data consistency audit of the three bill clusters, regularly comparing the payment bills and cancellation bills according to the outgoing bills. Once inconsistencies are found, the data is automatically adjusted to ensure the consistency of the three types of bills.

[0112] Based on the payment method provided by the embodiment of the present invention, the embodiment of the present invention also provides a payment device, such as Fig.10 As shown, the payment device 1000 may include: an acquisition module 1010 , a parsing module 1020 , a determination module 1030 , and a payment module 1040 .

[0113] The acquisition module 1010 is used to acquire the user identification of the subscription service and the payment relationship corresponding to the user identification.

[0114] The parsing module 1020 is used to parse the first payment information in the payment relationship, where the first payment information includes a user identifier and a user identifier to be paid.

[0115] The determination module 1030 is used to determine a target payment model corresponding to the payment relationship in at least one payment model according to the first payment information.

[0116] The payment module 1040 is used to perform payment according to the target payment model and the first payment information.

[0117] In some embodiments, the acquisition module 1010 is further used to obtain the address code of the payment model where the user identifier is located.

[0118] The acquisition module 1010 is specifically used for: automatically addressing according to the address code, and determining the payment relationship corresponding to the user identification.

[0119] In some embodiments, the parsing module 1020 includes: a first parsing unit, which is used to parse the multi-level payment relationship into a basic payment relationship when the payment relationship is a multi-level payment relationship, and the basic payment relationship is a payment relationship including a user identifier and a user identifier to be paid.

[0120] The second parsing unit is used to parse the second payment information in the basic payment relationship and use the second payment information as the first payment information.

[0121] In some embodiments, the determination module 1030 includes: an acquisition unit, configured to acquire the number of bills of the to-be-paid user ID in a specified time period.

[0122] A determination unit is used to determine a target payment model in at least one payment model according to the bill quantity and a preset quantity threshold.

[0123] In some embodiments, the first payment information also includes a payment amount.

[0124] In some embodiments, the target payment model includes any one of a call bill payment model, a product payment model, a real-time payment model, a combined account payment model, and a bill payment model.

[0125] In some embodiments, the determination module 1030 is further used to determine at least one type of bill according to the payment result and at least one type of preset storage format after payment is made according to the target payment model and the first payment information.

[0126] The acquisition module 1010 is also used to acquire the bill calling request sent by the application device.

[0127] The determination module 1030 is further configured to determine a target bill corresponding to the bill call request in at least one type of bills.

[0128] The payment device 1000 also includes: a sending module, which is used to send the target bill to the application device, so that the application device can display the target bill to the user.

[0129] Understandably, Fig.10 Each module / unit in the payment device 1000 has the function of realizing Figure 4 The functions of each step in the process can achieve the corresponding technical effects, and for the sake of brevity, they will not be described in detail here.

[0130] Fig.11 It is a schematic diagram of the hardware structure of a payment agent device provided in an embodiment of the present invention.

[0131] like Fig.11 As shown, the payment device 1100 in this embodiment includes an input device 1101, an input interface 1102, a central processing unit 1103, a memory 1104, an output interface 1105, and an output device 1106. The input interface 1102, the central processing unit 1103, the memory 1104, and the output interface 1105 are interconnected through a bus 1110, and the input device 1101 and the output device 1106 are connected to the bus 1110 through the input interface 1102 and the output interface 1105, respectively, and then connected to other components of the payment device 1100.

[0132] Specifically, the input device 1101 receives input information from the outside and transmits the input information to the central processing unit 1103 through the input interface 1102; the central processing unit 1103 processes the input information based on the computer executable instructions stored in the memory 1104 to generate output information, temporarily or permanently stores the output information in the memory 1104, and then transmits the output information to the output device 1106 through the output interface 1105; the output device 1106 outputs the output information to the outside of the payment device 1100 for user use.

[0133] In some embodiments, Fig.11 The payment device 1100 shown includes: a memory 1104 for storing programs; a processor 1103 for running the programs stored in the memory to execute Figure 4 The embodiment shown provides a payment method.

[0134] The embodiment of the present invention further provides a computer-readable storage medium, wherein the computer-readable storage medium stores computer program instructions; when the computer program instructions are executed by a processor, Figure 4 The embodiment shown provides a payment method.

[0135] It should be clear that each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and for the sake of brevity, no further description is given. The present invention is not limited to the specific configurations and processes described above and shown in the figures. For the sake of simplicity, a detailed description of the known methods is omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of the present invention is not limited to the specific steps described and shown, and those skilled in the art can make various changes, modifications and additions, or change the order between the steps after understanding the spirit of the present invention.

[0136] The functional blocks shown in the structural block diagram described above can be implemented as hardware, software, firmware or a combination thereof. When implemented in hardware, it can be, for example, an electronic circuit, an application specific integrated circuit (Application Specific Integrated Circuit, ASIC), appropriate firmware, plug-in, function card, etc. When implemented in software, the elements of the present invention are programs or code segments used to perform the required tasks. The program or code segment can be stored in a machine-readable medium, or transmitted on a transmission medium or communication link by a data signal carried in a carrier. "Machine-readable medium" may include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, read-only memories (Read-Only Memory, ROM), flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, optical fiber media, radio frequency (Radio Frequency, RF) links, etc. The code segment can be downloaded via a computer network such as the Internet, an intranet, etc.

[0137] It should also be noted that the exemplary embodiments mentioned in the present invention describe some methods or systems based on a series of steps or devices. However, the present invention is not limited to the order of the above steps, that is, the steps can be performed in the order mentioned in the embodiments, or in a different order from the embodiments, or several steps can be performed simultaneously.

[0138] Aspects of the present disclosure are described above with reference to the flowchart and / or block diagram of the method, device (system) and computer program product according to the embodiment of the present disclosure. It should be understood that each box in the flowchart and / or block diagram and the combination of each box in the flowchart and / or block diagram can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to produce a machine so that these instructions executed by the processor of the computer or other programmable data processing device enable the implementation of the function / action specified in one or more boxes of the flowchart and / or block diagram. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field programmable logic circuit. It can also be understood that each box in the block diagram and / or flowchart and the combination of boxes in the block diagram and / or flowchart can also be implemented by dedicated hardware that performs a specified function or action, or can be implemented by a combination of dedicated hardware and computer instructions.

[0139] The above is only a specific implementation of the present invention. Those skilled in the art can clearly understand that for the convenience and simplicity of description, the specific working process of the system, module and unit described above can refer to the corresponding process in the aforementioned method embodiment, and will not be repeated here. It should be understood that the protection scope of the present invention is not limited to this. Any technician familiar with the technical field can easily think of various equivalent modifications or replacements within the technical scope disclosed by the present invention, and these modifications or replacements should be covered within the protection scope of the present invention.

Claims

1. A payment method, characterized in that: The method comprises: Obtaining a user ID for ordering a service and a payment relationship corresponding to the user ID; parsing first payment information in the payment relationship, wherein the first payment information includes the user identifier and the identifier of the user to be paid; Determining, according to the first proxy payment information, a target proxy payment model corresponding to the proxy payment relationship in at least one proxy payment model; Performing payment according to the target payment model and the first payment information; The step of determining, according to the first payment information, a target payment model corresponding to the payment relationship in the at least one payment model includes: Obtaining the number of bills for the to-be-paid user ID in a specified time period; The target payment model is determined in the at least one payment model according to the bill quantity and a preset quantity threshold.

2. The method according to claim 1, characterized in that The method further comprises: Obtaining the address code of the payment model where the user identification is located; Wherein, obtaining the payment relationship corresponding to the user identifier includes: Automatically addressing according to the address code to determine the payment relationship corresponding to the user identification.

3. The method according to claim 1, characterized in that The parsing of the first payment information in the payment relationship includes: When the agency payment relationship is a multi-level agency payment relationship, resolving the multi-level agency payment relationship into a basic agency payment relationship, wherein the basic agency payment relationship is an agency payment relationship including the user identifier and the to-be-paid user identifier; The second payment information in the basic payment relationship is parsed, and the second payment information is used as the first payment information.

4. The method according to claim 1, characterized in that: The first payment information also includes a payment amount.

5. The method according to claim 1, characterized in that The target payment model includes any one of a call bill payment model, a product payment model, a real-time payment model, a combined account payment model, and a bill payment model.

6. The method according to any one of claims 1 to 5, characterized in that: After performing the payment according to the target payment model and the first payment information, the method further includes: Determine at least one type of bill according to the payment result and at least one type of preset storage format; Get the bill call request sent by the application device; Determining a target bill corresponding to the bill call request from the at least one type of bills; The target bill is sent to the application device so that the application device displays the target bill to the user.

7. A payment device, characterized in that: The device comprises: An acquisition module, used to acquire a user ID for ordering a service and a payment relationship corresponding to the user ID; A parsing module, used for parsing the first payment information in the payment relationship, wherein the first payment information includes the user identifier and the identifier of the user to be paid; a determination module, configured to determine, according to the first payment information, a target payment model corresponding to the payment relationship from at least one payment model; a payment module, configured to perform payment according to the target payment model and the first payment information; The determination module is specifically used to obtain the number of bills of the user identification to be paid in a specified time period; and determine the target payment model in the at least one payment model according to the number of bills and a preset number threshold.

8. A payment device, characterized in that: The device comprises: a processor and a memory storing computer program instructions; When the processor executes the computer program instructions, the payment method as described in any one of claims 1-6 is implemented.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer program instructions, and when the computer program instructions are executed by a processor, the payment method according to any one of claims 1 to 6 is implemented.

Images