CN106920083B - Service implementation method, payment method and device - Google Patents
Service implementation method, payment method and device Download PDFInfo
- Publication number
- CN106920083B CN106920083B CN201610634419.1A CN201610634419A CN106920083B CN 106920083 B CN106920083 B CN 106920083B CN 201610634419 A CN201610634419 A CN 201610634419A CN 106920083 B CN106920083 B CN 106920083B
- Authority
- CN
- China
- Prior art keywords
- payment
- client
- transaction
- amount
- numerical value
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/08—Payment architectures
- G06Q20/10—Payment architectures specially adapted for electronic funds transfer [EFT] systems; specially adapted for home banking systems
- G06Q20/102—Bill distribution or payments
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
- G06Q20/00—Payment architectures, schemes or protocols
- G06Q20/04—Payment circuits
- G06Q20/06—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme
- G06Q20/065—Private payment circuits, e.g. involving electronic currency used among participants of a common payment scheme using e-cash
Landscapes
- Business, Economics & Management (AREA)
- Accounting & Taxation (AREA)
- Finance (AREA)
- Strategic Management (AREA)
- Physics & Mathematics (AREA)
- General Business, Economics & Management (AREA)
- General Physics & Mathematics (AREA)
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Development Economics (AREA)
- Economics (AREA)
- Financial Or Insurance-Related Operations Such As Payment And Settlement (AREA)
Abstract
The application relates to the technical field of service implementation, in particular to a service implementation method, a payment method and a payment device, wherein in the service implementation method, when a first service request sent by a sender client is received, the total transaction amount is divided into a first number of transaction amounts with unequal numerical values according to a predefined division algorithm; when a second service request sent by a receiver client is received, selecting a transaction amount with a first numerical value from transaction amounts with first quantity and unequal numerical values according to the second service request; and returning a request response containing the transaction amount of the first numerical value to the receiver client so that the receiver client completes corresponding business operation according to the transaction amount of the first numerical value. In the application, the total transaction amount is divided into a first number of transaction amounts with unequal numerical values, and then one of the transaction amounts with one numerical value is allocated to each second service request after the second service request is received, so that the difference of each service operation aiming at the same service request is realized.
Description
Technical Field
The present application relates to the field of service implementation technologies, and in particular, to a service implementation method, a payment method, and an apparatus.
Background
In the conventional technology, when a service request sent by a sender client is directed to multiple receiver clients, transaction amounts corresponding to service operations executed by each receiver client are the same, that is, for the same service request, the service operations executed by the multiple receiver clients have no difference, but in practical application, it is desirable to realize the difference of the service operations executed by different receiver clients.
Disclosure of Invention
The application describes a service implementation method, a payment method and a device, which are used for realizing the difference of service operations aiming at the same service request.
In a first aspect, a method for implementing a service is provided, where the method includes:
receiving a first service request sent by a client of a sender, wherein the first service request comprises a total transaction amount and a first number of receivers;
dividing the total transaction amount into the transaction amounts of the first number of unequal values according to a predefined division algorithm;
receiving a second service request sent by the client of the receiving party;
selecting a transaction amount with a first numerical value from the transaction amounts with the first quantity of unequal numerical values according to the second service request;
and returning a request response containing the transaction amount of the first numerical value to the receiver client so that the receiver client completes corresponding business operation according to the transaction amount of the first numerical value.
In a second aspect, a payment method is provided, the method comprising:
receiving a collection request sent by a client of a collection party, wherein the collection request comprises a total payment amount and a first quantity of a payment party;
dividing the total payment amount into the payment amounts of the first number of unequal values according to a predefined division algorithm;
receiving a payment request sent by a client of a payer;
selecting a payment amount of a first number from the payment amounts of the first number of unequal values according to the payment request;
and returning a request response containing the payment amount of the first value to the payer client so that the payer client completes payment according to the payment amount of the first value.
In a third aspect, an apparatus for implementing a service is provided, where the apparatus includes:
the system comprises a receiving unit, a sending unit and a receiving unit, wherein the receiving unit is used for receiving a first service request sent by a client of a sending party, and the first service request comprises a total transaction amount and a first number of receiving parties;
the dividing unit is used for dividing the transaction total amount received by the receiving unit into the transaction amounts with the first number of unequal values according to a predefined dividing algorithm;
the receiving unit is further configured to receive a second service request sent by the receiver client;
the selecting unit is used for selecting the transaction amount of a first numerical value from the transaction amounts of the first number of unequal numerical values according to the second service request received by the receiving unit;
and the sending unit is used for returning a request response containing the transaction amount of the first numerical value selected by the selecting unit to the receiver client so as to enable the receiver client to complete corresponding business operation according to the transaction amount of the first numerical value.
In a fourth aspect, there is provided a payment device, the device comprising:
the system comprises a receiving unit, a receiving unit and a processing unit, wherein the receiving unit is used for receiving a collection request sent by a collector client, and the collection request comprises a total payment amount and a first amount of a payer;
the dividing unit is used for dividing the total payment amount received by the receiving unit into the payment amounts with the first number of unequal values according to a predefined dividing algorithm;
the receiving unit is also used for receiving a payment request sent by a client of a payer;
the selecting unit is used for selecting the payment amount of a first numerical value from the payment amounts of the first number of unequal numerical values according to the payment request received by the receiving unit;
and the sending unit is used for returning a request response containing the payment amount of the first numerical value selected by the selecting unit to the payer client so that the payer client completes payment according to the payment amount of the first numerical value.
According to the business implementation method, the payment method and the device, when a first business request sent by a sender client is received, the total transaction amount is divided into transaction amounts with a first number of unequal numerical values according to a predefined division algorithm; then, when a second service request sent by the client of the receiving party is received, selecting the transaction amount of a first numerical value from the transaction amounts of the first numerical value and the unequal numerical values according to the second service request; and returning a request response containing the transaction amount of the first numerical value to the receiver client so that the receiver client completes corresponding business operation according to the transaction amount of the first numerical value. That is, in the present application, the total transaction amount is divided into a first number of transaction amounts with unequal values, and then, each time a second service request is received, one of the transaction amounts with one value is allocated to the second service request, so as to implement the difference of each service operation for the same service request.
Drawings
In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
Fig. 1 is a schematic view of an application scenario of a payment method provided in the present application;
fig. 2 is a flowchart of a service implementation method according to an embodiment of the present application;
FIG. 3a is a schematic view of a checkout interface provided herein;
FIG. 3b is a second schematic diagram of a checkout interface provided in the present application;
FIG. 3c is a third schematic view of a checkout interface provided in the present application;
FIG. 4 is a flow chart of a payment method provided in another embodiment of the present application;
fig. 5 is a schematic diagram of a service implementation apparatus according to yet another embodiment of the present application;
fig. 6 is a schematic view of a payment device according to another embodiment of the present application.
Detailed Description
Embodiments of the present invention will be described below with reference to the accompanying drawings.
The service implementation method, the payment method and the device provided by the embodiment of the application are suitable for a scene that the service operation corresponding to the service request executed by a plurality of receiver clients has difference when the sender client sends the same service request aiming at the plurality of receiver clients, wherein the 'sender client' refers to an application program which logs in a registered account of a sender user, and the application program can be located in any terminal equipment; similarly, the "receiver client" refers to an application program that logs in the registered account of the receiver user, and the application program may be located in any terminal device as well; the service request may refer to a payment receipt request or a payment request, etc. In this specification, the difference of the business operations may mean that the transaction amounts corresponding to the business operations are different.
For example, the scenario of AA collection for a payer shown in fig. 1 includes a payee client and a plurality of payer clients, where a payee user of the payee client and payer users of the plurality of payer clients may belong to the same group; the payee client is used for sending a collection request, and the payer client is used for executing corresponding payment operation according to the collection request sent by the payee client. It should be noted that, in fig. 1, for the payment request sent by the payee client, the payment operations executed by the payer clients may have differences, and specifically, the differences may be distinguished by the time of executing the payment operation, for example, the payment operation executed at an earlier time corresponds to a smaller payment amount, while the payment operation executed at a later time corresponds to a larger payment amount, so as to promote the payer user of the payer client to complete payment in an earlier time, thereby improving the efficiency of implementing the payment service.
Fig. 2 is a flowchart of a service implementation method according to an embodiment of the present application. The execution subject of the method may be a device with processing capabilities: as shown in fig. 2, the method may specifically include, by a server or a system or an apparatus, for example, a server of a payment system:
step 210, receiving a first service request sent by a sender client, wherein the first service request includes a total transaction amount and a first number of receivers.
The first service request may specifically be a request for a service to be implemented, for example, when a payment service is implemented, the first service request may be a payment request, and when a charging service is implemented, the first service request may be a charging request. The first service request may include a total transaction amount and a first number of the receiving parties, and may further include identification information for identifying the requested service, a service initiator, and the like, where the service initiator refers to a user identification (for example, account information of a user) of a sending party user on a sending party client, and the first service request may also include information of a corresponding receiving party user, and the like. According to different practical application scenarios, the request may include corresponding information to facilitate smooth implementation of the service, and so on.
It should be noted that the first service request may be sent to multiple receiver clients, and when all the receiver clients perform service operations corresponding to the first service request, the service of the sender client is completed.
For example, in the scenario of AA collection for a pay pal, the sending client may be a payee client, and the first service request may be a collection request. Specifically, the steps of the payee client sending a collection request to a plurality of payer clients are as follows: clicking a '+' button at the lower right corner in a display interface of a group (established by the following steps of address book- > group chat- > selection of a group type (such as entertainment group) > selection of users (namely selection of payee users and other users)), and then selecting 'AA money collection' in a pop-up display interface, so that the display interface shown in figure 3a can be entered, and in figure 3a, a payment total amount (namely 'total amount') input by a payee user and a first number (namely 'total number') of receivers can be received; in addition, the payment method of the payer user input by the payee user can be received, and the payment method comprises the following steps: the payment method comprises the steps that the payment methods of the payer user input by the payee user are equal and unequal, when the payment methods of the payer user input by the payee user are equal, the payment operations executed by the payer user are not different, namely, the payment amounts corresponding to the payment operations are the same; when the payment modes of the payer users input by the payee users are unequal, the payment operations executed by the payer users have differences, that is, the payment amounts corresponding to the payment operations are different. It should be noted that, when the payment method of the payer user input by the payee user is "unequal", a corresponding division algorithm, that is, an algorithm for dividing the total payment amount into a first number of unequal payment amounts, may be configured.
In one implementation, the configured partitioning algorithm may include two types: the first type refers to linear partitioning algorithms, such as "average first; then, respectively increasing a preset value on the average value and reducing the preset value to obtain two adjacent values; then reducing the value smaller than the average value of two adjacent values by a preset value, increasing the value larger than the average value by a preset value to obtain another two values, and so on until obtaining a first number of unequal values; for example, assume that the total amount paid is: 100, the first number is: 5, the predetermined values are: 1; the average is then: 20, the other 4 numbers are respectively: 20+1 ═ 21, 20-1 ═ 19, 20+1+1 ═ 22, 20-1-1 ═ 18, that is, according to the above linear division algorithm, the 5 unequal values obtained by division are: 20, 21, 19, 22, 18.
The second type refers to non-linear partitioning algorithms, such as "randomly generating a first number of unequal values", assuming a total payout amount of: 100, the first number is: 5, according to a non-linear division algorithm, the 5 unequal numerical values obtained by division can be respectively: 16, 19, 20, 21, 24.
In fig. 3a, after the payee user inputs "total amount", "total number", and "unequal" payment manners (when the payment manners are "unequal", a division algorithm may also be configured), and clicks the "ok" button, the payee client is triggered to send a receipt request in the group, that is, the payee client is triggered to send a receipt request to a plurality of payer clients; the server may then receive the collection request sent by the payee client, and after the server responds to the collection request, the server may enter the display interface shown in fig. 3b, where the display interface displays the collection message corresponding to the collection request, and here the response of the server may include calculating the "average payment amount" according to the "total amount" and the "total number". When the payer user clicks the receipt message in fig. 3b, the details interface shown in fig. 3c can be entered, and then the payer user can perform the corresponding payment operation.
It should be noted that, when the sender user configures a corresponding partitioning algorithm at the sender client, the first service request may further include the partitioning algorithm, that is, in the scenario of collecting AA money for a pay bank, the collection request may further include the partitioning algorithm.
Step 220, the total transaction amount is divided into a first number of transaction amounts of unequal value according to a predefined division algorithm.
It is understood that the predefined partitioning algorithm herein may refer to the partitioning algorithm sent by the sending client, or may refer to the partitioning algorithm predefined by the server, and whether received from the sending client or customized, the predefined partitioning algorithm may be described in reference to step 210, that is, it may include two types: linear division algorithm and non-linear division algorithm, when the predefined division algorithm is the linear division algorithm, the total transaction amount is assumed as: 100, the first data volume is: 5, the predetermined values are: 1, the divided transaction amounts of the 5 unequal numerical values are respectively: 20, 21, 19, 22, 18; when the predefined division algorithm is a non-linear division algorithm, the transaction amounts of the 5 unequal values obtained by division may be: 16, 19, 20, 21, 24.
It can be understood that, when the predefined partitioning algorithm refers to a partitioning algorithm predefined by the server, the first service request sent by the sender client may further include an "unequal" service operation manner, so that the server partitions the total transaction amount by using the predefined partitioning algorithm; when the "unequal" business operation mode is not included, the server may divide the transaction amount according to a default division algorithm (averaging).
It should be noted that, the step 220 may be executed when the server responds to the first service request of the sender client, or may be executed after the server responds to the first service request of the sender client, which is not limited in this application.
Of course, in practical applications, step 210 and step 220 may be replaced by: the method comprises the steps that a sender client receives the total payment amount and the first number of receivers input by a sender user, and receives a division algorithm configured by the sender user; dividing the total transaction amount into a first number of transaction amounts with unequal values according to the division algorithm; and sending the transaction amount with the first quantity of unequal values to the server, and storing the transaction amount with the first quantity of unequal values by the server.
Optionally, after dividing the total transaction amount into the transaction amounts with the first number of unequal values, the transaction amounts with the first number of unequal values may be sorted according to the descending order of the transaction amounts, so as to obtain the sorted transaction amounts with the first number of unequal values. As in the previous example, the 5 transaction amounts with unequal values, which are divided according to the linear division algorithm, are sorted as follows: 18, 19, 20, 21, 22; and after the transaction amounts of the 5 unequal values obtained by dividing according to the nonlinear division algorithm are sequenced, the following steps are carried out: 16, 19, 20, 21, 24.
Step 230, receiving a second service request sent by the receiver client.
The second service request may be initiated by the receiver client when performing a corresponding service operation with respect to the first service request sent by the sender client, and is only used to request the server to allocate a corresponding transaction amount for the receiver client, and is not used to implement a real service. In one example, the second service request may include information such as a timestamp.
It can be understood that, because the first service request in step 210 is initiated for multiple receiver clients, the multiple receiver clients may each perform a corresponding service operation; when there are multiple receiver clients executing corresponding service operations, the server may receive a second service request sent by the multiple receiver clients.
In the scenario of AA collection for a pay pal, the second service request may refer to a payment request, and specifically, the payment request may be triggered by the payer user clicking on the "pay about 20 m" button in fig. 3c, which may include information such as a timestamp. When multiple payer users click on the "pay about 20 dollars" button in FIG. 3c, the server may receive multiple payment requests.
Step 240, according to the second service request, selecting a transaction amount of the first number from the transaction amounts of the first number of unequal numbers.
Wherein, the step 240 may specifically be: determining the ranking rank of the second service request according to the timestamp of the second service request; selecting a transaction amount corresponding to the ranking from the sorted transaction amounts of the first number of unequal values; and taking the transaction amount corresponding to the ranking name as the transaction amount of the first numerical value.
For example, assuming that the server has received two second service requests before, and the timestamps corresponding to the two second service requests are "2015-08-01 _13: 01" and "2015-08-01 _13: 05", respectively, and the timestamp corresponding to the second service request currently received by the server is "2015-08-01 _13: 58", it may be determined that the ranking name of the currently received second service request is: and (3) third name. After determining the ranking rank of the second service request, the transaction amount of the 5 sorted unequal values is: 18, 19, 20, 21, 22, for example, the transaction amount corresponding to the ranked rank is "20," i.e., the transaction amount having "20" as the first value.
Therefore, in the application, the transaction amount is associated with the time of sending the second service request (i.e. the time of executing the service operation), for example, the transaction amount corresponding to the service operation executed at an earlier time is smaller, while the transaction amount corresponding to the service operation executed at a later time is larger, so as to promote the receiver user of the receiver client to complete the service operation in an earlier time, thereby improving the efficiency of implementing the service.
Certainly, in practical applications, the transaction amount of the first numerical value may also be selected in other manners, for example, identification information may be added to the ordered transaction amounts of the first number of unequal numerical values, initially, the identification information may be set as unselected, and then, if the transaction amount of any numerical value is selected, the corresponding identification information is set as selected; and traversing the sorted first quantity of transaction amounts with different numerical values from the beginning when the second service request is received, wherein if the identification information of the transaction amount traversed to a certain numerical value is not selected, the transaction amount of the certain numerical value can be selected, and the corresponding identification information is set to be selected.
Optionally, after the server selects the transaction amount of the first numerical value, it may determine whether the timestamp corresponding to the second service request exceeds a predetermined time, and if the timestamp exceeds the predetermined time, add another predetermined numerical value to the first numerical value correspondingly. For example, in a scenario of AA collection of a payer, when it is determined that a payment operation performed by a payer user exceeds a predetermined time, the payment amount of the payer user may be increased, for example, assuming that, for a collection request, the payment amount allocated by the server for the last received payment request is "22", that is, the payment amount allocated for the last user performing the payment operation is "22", if the user performs the payment operation after exceeding 1 day, the payment amount may be adjusted from "22" to "23" (i.e., increased by 1 yuan) to realize a certain reward and punishment system, thereby promoting the enthusiasm of the payer user. It will be appreciated that when the payment amount is adjusted, the amount actually charged by the payee will change accordingly, e.g., from "100" to "101" in the previous example (i.e., a corresponding 1-dollar increase).
Step 250, returning a request response containing the transaction amount of the first numerical value to the receiver client, so that the receiver client completes corresponding business operation according to the transaction amount of the first numerical value.
After the server selects the transaction amount of the first numerical value, the server can return a request response containing the transaction amount of the first numerical value to the receiver client, and after the receiver client receives the transaction amount of the first numerical value, the receiver client displays the transaction amount of the first numerical value to the receiver user, so that the receiver client executes corresponding business operation according to the transaction amount of the first numerical value.
Of course, in practical applications, it is also possible that the receiving client does not perform the business operation after receiving the request response, in which case the transaction amount of the first value returned as described above is not effectively used. In order to solve the problem that the returned transaction amount of the first numerical value is not effectively utilized, in the application, a threshold time may be set at the server, specifically, the server may start timing after returning a request response to the receiver client, and if it is determined that the receiver client does not perform a service operation within the threshold time, the transaction amounts of the first number of unequal numerical values may be reordered, that is, the transaction amount of the first numerical value is inserted after the transaction amount selected last time, and a timestamp corresponding to the recorded second service request corresponding to the transaction amount of the first numerical value is cleared; or, in the manner of selecting the transaction amount of the first value according to the identification information, the identification information corresponding to the transaction amount of the first value may be set to be unselected again.
When the embodiment of the application is applied to an AA collection scenario of a pay bank, a payment method may be as shown in fig. 4, where in fig. 4, the method may specifically include the following steps:
step 410, receiving a payment request sent by the client of the payee.
Wherein the collect request may include the total amount paid and the first amount of the payer. In addition, the receiving system may further include identification information for identifying the receiving service, a receiving party, and the like, where the receiving party refers to a user identification (for example, account information of the user, and the like) of the receiving party user on the receiving party client, and the receiving request may also include information of a corresponding paying party user, and the like. According to different practical application scenarios, the request may include corresponding information to facilitate smooth implementation of the payment receiving service, and so on.
It should be noted that the collection request may be sent by multiple payer clients, and when the multiple payer clients all perform the payment operation corresponding to the payment request, the collection service of the payee client is completed.
The steps of the payee client sending a collection request to a plurality of payer clients are as follows: clicking a 'plus' button at the lower right corner in a display interface of a group (comprising a plurality of users, such as a payee user), then selecting 'AA money collection' in a popped display interface, and then entering the display interface shown in FIG. 3a, wherein in FIG. 3a, a total payment amount (i.e. 'total amount') input by the payee user and a first number (i.e. 'total number') of receivers can be received; in addition, the payment method of the payer user input by the payee user can be received, and the payment method comprises the following steps: the payment method comprises the steps that the payment methods of the payer user input by the payee user are equal and unequal, when the payment methods of the payer user input by the payee user are equal, the payment operations executed by the payer user are not different, namely, the payment amounts corresponding to the payment operations are the same; when the payment modes of the payer users input by the payee users are unequal, the payment operations executed by the payer users have differences, that is, the payment amounts corresponding to the payment operations are different. It should be noted that, when the payment manner of the payer user input by the payee user is "unequal", a corresponding division algorithm may be further configured, that is, an algorithm for dividing the total payment amount into a first number of unequal payment amounts is configured, where the configured division algorithm may be the same as described above, and is not repeated herein.
In fig. 3a, after the payee user inputs "total amount", "total number" and "equal" or "unequal" payment methods (when the payment methods are "unequal", a division algorithm may be further configured), clicking the "ok" button triggers the payee client to send a collection request in a group, that is, after the payee client is triggered to send collection requests to a plurality of payer clients, the server may receive the collection requests sent by the payee clients, and after the server responds to the collection requests, the server may enter the display interface shown in fig. 3b, where the display interface displays collection messages corresponding to the collection requests, where the response of the server may include calculating "average payment amount" according to the "total amount" and the "total number". When the payer user clicks the receipt message in fig. 3b, the details interface shown in fig. 3c can be entered, and then the payer user can perform the corresponding payment operation.
It should be noted that, when the payee user configures a corresponding partition algorithm at the payee client, the collection request may further include the partition algorithm.
Step 420, the total payment amount is divided into a first number of unequal payment amounts according to a predefined division algorithm.
It is understood that the predefined partitioning algorithm herein may refer to the partitioning algorithm sent by the payee client, or may refer to the partitioning algorithm predefined by the server, and whether received from the recipient client or customized, the predefined partitioning algorithm may be described in reference to step 210, that is, it may include two types: linear division algorithm and non-linear division algorithm, when the predefined division algorithm is the linear division algorithm, the total payment amount is assumed as: 100, the first number is: 5, the predetermined values are: 1, the payment amounts of the 5 unequal numerical values obtained by dividing are respectively: 20, 21, 19, 22, 18; when the predefined division algorithm is a non-linear division algorithm, the payment amounts of the 5 unequal values obtained by division can be respectively as follows: 16, 19, 20, 21, 24.
It can be understood that, when the predefined partitioning algorithm is a predefined partitioning algorithm of the server, the payment request sent by the payee client may further include an "unequal" payment manner, so that the server partitions the total payment amount by using the predefined partitioning algorithm; and when the "unequal" payment method is not included, the server may divide the total payment amount according to a default division algorithm (e.g., averaging).
It should be noted that, the step 420 may be executed when the server responds to the receiving request of the receiving party client, or may be executed after the server responds to the receiving request of the receiving party client, which is not limited in this application.
Of course, in practical application, step 410 and step 420 may be replaced by: the method comprises the steps that a payee client receives a total payment amount and a first number of payers input by a payee user, and receives a division algorithm configured by the payee user; dividing the total payment amount into a first number of payment amounts with unequal values according to the division algorithm; and sending the payment sum with the first quantity of unequal values to the server, and storing the payment sum with the first quantity of unequal values by the server.
Optionally, after dividing the total payment amount into the payment amounts with the first number of unequal values, the payment amounts with the first number of unequal values may be sorted according to the order from small to large of the payment amounts, so as to obtain the sorted payment amounts with the first number of unequal values. As in the previous example, the payment amounts of the 5 unequal values obtained by dividing according to the linear division algorithm are sorted as follows: 18, 19, 20, 21, 22; and after the payment amounts of the 5 unequal values obtained by dividing according to the nonlinear division algorithm are sequenced, the following steps are carried out: 16, 19, 20, 21, 24.
Step 430, receiving a payment request sent by the payer client.
The payment request here may be initiated by the payer client when performing a payment operation for the payment request sent by the payee client, and is only used for requesting the server to allocate a corresponding payment amount for the payer client, and is not for implementing a real payment service. In one example, the payment request may include information such as a timestamp.
It can be understood that, because the collection request in step 410 is initiated for multiple payer clients, multiple payer clients may each perform a corresponding payment operation; when a plurality of payer clients execute corresponding payment operations, the server can receive payment requests sent by the plurality of payer clients. In one example, the payment request may be triggered by the payer user clicking on the "pay about 20 dollars" button in FIG. 3c, which may include information such as a timestamp. When multiple payer users click on the "pay about 20 dollars" button in FIG. 3c, the server may receive multiple payment requests.
Step 440, selecting a first number of payment amounts from the first number of unequal number of payment amounts based on the payment request.
Wherein, step 440 may specifically be: determining the ranking of the payment requests according to the time stamps of the payment requests; selecting a payment amount corresponding to the sorting ranking from the sorted payment amounts of the first number of unequal values; the transaction amount corresponding to the payment amount applied to the ranking name is taken as the first value.
For example, assuming that the server has received two payment requests before, and the timestamps corresponding to the two payment requests are "2015-08-01 _13: 01" and "2015-08-01 _13: 05", respectively, and the timestamp corresponding to the currently received payment request by the server is "2015-08-01 _13: 58", it may be determined that the ranking name of the currently received payment request is: and (3) third name. After determining the ranking rank of the payment request, the payment amounts of the 5 sorted unequal values are: 18, 19, 20, 21, 22, for example, the payment amount corresponding to the ranking name is "20", i.e., the payment amount having "20" as the first value.
Therefore, in the application, the payment amount is associated with the time of sending the payment request (i.e. the time of executing the payment operation), for example, the payment operation executed at an earlier time corresponds to a smaller payment amount, while the payment operation executed at a later time corresponds to a larger payment amount, so that the payer user at the payer client is promoted to complete the payment operation in an earlier time, and the efficiency of implementing the collection service is further improved.
Step 450, returning a request response containing the payment amount of the first value to the payer client, so that the payer client completes payment according to the payment amount of the first value.
After the server selects the payment amount of the first value, the server can return a request response containing the payment amount of the first value to the payer client, and after the payer client receives the payment amount of the first value, the payer client displays the payment amount of the first value to the payer user, so that the payer client executes corresponding payment operation according to the payment amount of the first value.
Corresponding to the foregoing service implementation method, an embodiment of the present application further provides a service implementation apparatus, as shown in fig. 5, the apparatus includes:
a receiving unit 501, configured to receive a first service request sent by a sender client, where the first service request includes a total transaction amount and a first number of recipients.
The dividing unit 502 is configured to divide the total transaction amount received by the receiving unit 501 into transaction amounts with a first number of unequal values according to a predefined division algorithm.
The dividing unit 502 may specifically be configured to:
dividing the total transaction amount into a first number of transaction amounts with unequal values according to a predefined linear division algorithm; alternatively, the first and second electrodes may be,
the total transaction amount is divided into a first number of transaction amounts of unequal value according to a predefined non-linear division algorithm.
The receiving unit 501 is further configured to receive a second service request sent by the receiving client.
The selecting unit 503 is configured to select a transaction amount of a first numerical value from the transaction amounts of the first number of unequal numerical values according to the second service request received by the receiving unit 501.
The sending unit 504 is configured to return a request response including the transaction amount of the first numerical value selected by the selecting unit 503 to the receiver client, so that the receiver client completes a corresponding service operation according to the transaction amount of the first numerical value.
Optionally, the apparatus may further include: the sorting unit 505 is configured to sort the transaction amounts with the first number of unequal values according to the descending order of the transaction amount values, so as to obtain the sorted transaction amounts with the first number of unequal values.
Optionally, the second service request may further include a timestamp;
the selecting unit 503 is specifically configured to:
determining the ranking of the second service request according to the time stamp;
selecting a transaction amount corresponding to the ranking from the sorted transaction amounts of the first number of unequal values;
and taking the transaction amount corresponding to the ranking name as the transaction amount of the first numerical value.
The functions of the functional modules of the device in the embodiment of the present application may be implemented through the steps in the method embodiment described above, and therefore, the specific working process of the device provided in the present application is not repeated herein.
In the service implementation apparatus provided in the embodiment of the present application, the receiving unit 501 receives a first service request sent by a client of a sender; the dividing unit 502 divides the total transaction amount into a first number of transaction amounts with unequal values according to a predefined dividing algorithm; the receiving unit 501 receives a second service request sent by the receiver client; the selecting unit 503 selects a transaction amount of a first numerical value from the transaction amounts of the first number of unequal numerical values according to the second service request; the sending unit 504 returns a request response including the transaction amount of the first value to the receiver client, so that the receiver client completes corresponding business operations according to the transaction amount of the first value. Therefore, the difference of each service operation aiming at the same service request is realized.
Corresponding to the above payment method, an embodiment of the present application further provides a payment apparatus, as shown in fig. 6, the apparatus includes:
the receiving unit 601 is configured to receive a collection request sent by a client of a collector, where the collection request includes a total payment amount and a first amount of a payer.
A dividing unit 602, configured to divide the total payment amount received by the receiving unit 601 into a first number of payment amounts with unequal values according to a predefined division algorithm.
The receiving unit 601 is further configured to receive a payment request sent by a payer client.
A selecting unit 603, configured to select a payment amount of a first numerical value from the payment amounts of the first number of unequal numerical values according to the payment request received by the receiving unit 601.
A sending unit 604, configured to return a request response including the payment amount of the first value selected by the selecting unit 603 to the payer client, so that the payer client completes payment according to the payment amount of the first value.
The functions of the functional modules of the device in the embodiment of the present application may be implemented through the steps in the method embodiment described above, and therefore, the specific working process of the device provided in the present application is not repeated herein.
In the payment device provided by the embodiment of the application, the receiving unit 601 receives a payment receiving request sent by a client of a payee; the dividing unit 602 divides the total payment amount into a first number of payment amounts with unequal values according to a predefined division algorithm; the receiving unit 601 receives a payment request sent by a payer client; the selecting unit 603 selects a payment amount of a first number from the payment amounts of the first number of unequal values according to the payment request; the sending unit 604 returns a request response including the payment amount of the first value to the payer client, so that the payer client completes payment according to the payment amount of the first value. Thereby achieving differentiation of payment operations for the same payment request.
Those skilled in the art will recognize that, in one or more of the examples described above, the functions described in this invention may be implemented in hardware, software, firmware, or any combination thereof. When implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium.
The above-mentioned embodiments, objects, technical solutions and advantages of the present invention are further described in detail, it should be understood that the above-mentioned embodiments are only exemplary embodiments of the present invention, and are not intended to limit the scope of the present invention, and any modifications, equivalent substitutions, improvements and the like made on the basis of the technical solutions of the present invention should be included in the scope of the present invention.
Claims (10)
1. A service implementation method, the method comprising:
receiving a first service request sent by a client of a sender, wherein the first service request comprises a total transaction amount and a first number of receivers;
dividing the total transaction amount into the transaction amounts of the first number of unequal values according to a predefined division algorithm;
receiving a second service request sent by a first receiver client and receiving a second service request sent by a second receiver client; the second service request sent by the first receiver client comprises a first timestamp, the second service request sent by the second receiver client comprises a second timestamp, and the first timestamp is earlier than the second timestamp;
selecting a transaction amount with a first numerical value from the transaction amounts with the first quantity of unequal numerical values according to a second service request sent by the first receiver client; selecting a transaction amount with a second numerical value from the transaction amounts with the first number of unequal numerical values according to a second service request sent by the second receiver client; wherein the first value is less than the second value;
returning a request response containing the transaction amount of the first numerical value to the first receiver client so that the first receiver client completes corresponding business operation according to the transaction amount of the first numerical value; returning a request response containing the transaction amount of the second numerical value to the second receiver client so that the second receiver client completes corresponding business operation according to the transaction amount of the second numerical value;
and after the first number of receiver clients finish corresponding service operation, completing the service execution corresponding to the first service request.
2. The method of claim 1, wherein prior to the receiving the second service request sent by the first recipient client, the method further comprises:
and sequencing the transaction amounts with the first number of unequal values according to the sequence of the transaction amount values from small to large to obtain the sequenced transaction amounts with the first number of unequal values.
3. The method of claim 2,
selecting a transaction amount with a first numerical value from the transaction amounts with the first number of unequal numerical values according to a second service request sent by the first receiver client, wherein the selecting comprises the following steps:
determining the ranking of a second service request sent by the first receiver client according to the first timestamp;
selecting a transaction amount corresponding to the ranking from the ranked transaction amounts of the first number of unequal values;
and taking the transaction amount corresponding to the sorting ranking as the transaction amount of the first numerical value.
4. A method according to claim 2 or 3, wherein said dividing said total transaction amount into said first number of transaction amounts of unequal value according to a predefined division algorithm comprises:
dividing the total transaction amount into the transaction amounts of the first number of unequal values according to a predefined linear division algorithm; alternatively, the first and second electrodes may be,
dividing the total transaction amount into the transaction amounts of the first number of unequal values according to a predefined non-linear division algorithm.
5. A method of payment, the method comprising:
receiving a collection request sent by a client of a collection party, wherein the collection request comprises a total payment amount and a first quantity of a payment party;
dividing the total payment amount into the payment amounts of the first number of unequal values according to a predefined division algorithm;
receiving a first payment request sent by a first payer client and receiving a second payment request sent by a second payer client; wherein the first payment request includes a first timestamp, the second payment request includes a second timestamp, and the first timestamp is earlier than the second timestamp;
selecting a payment amount with a first numerical value from the payment amounts with the first number of unequal numerical values according to the first payment request; selecting a payment amount of a second numerical value from the transaction amounts of the first quantity unequal numerical values according to the second payment request; wherein the first value is less than the second value;
returning a request response containing the payment amount of the first numerical value to the first payer client so that the first payer client completes payment according to the payment amount of the first numerical value; and returning a request response containing the payment amount of the second numerical value to the second payer client so that the second payer client completes payment according to the payment amount of the second numerical value;
and after the first number of payer client sides finish payment, the execution of the collection service of the payee client side is finished.
6. A service enablement device, the device comprising:
the system comprises a receiving unit, a sending unit and a receiving unit, wherein the receiving unit is used for receiving a first service request sent by a client of a sending party, and the first service request comprises a total transaction amount and a first number of receiving parties;
the dividing unit is used for dividing the transaction total amount received by the receiving unit into the transaction amounts with the first number of unequal values according to a predefined dividing algorithm;
the receiving unit is further configured to receive a second service request sent by the first receiver client; receiving a second service request sent by a second receiver client; the second service request sent by the first receiver client comprises a first timestamp, the second service request sent by the second receiver client comprises a second timestamp, and the first timestamp is earlier than the second timestamp;
the selecting unit is used for selecting the transaction amount of a first numerical value from the transaction amounts of the first number of unequal numerical values according to the second service request sent by the first receiver client and received by the receiving unit; selecting a transaction amount with a second numerical value from the transaction amounts with the first number of unequal numerical values according to a second service request sent by the second receiver client; wherein the first value is less than the second value;
the sending unit is used for returning a request response containing the transaction amount of the first numerical value selected by the selecting unit to the first receiver client so that the first receiver client completes corresponding business operation according to the transaction amount of the first numerical value; returning a request response containing the transaction amount of the second numerical value to the second receiver client so that the second receiver client completes corresponding business operation according to the transaction amount of the second numerical value;
and after the first number of receiver clients finish corresponding service operation, completing the service execution corresponding to the first service request.
7. The apparatus of claim 6, further comprising: and the sorting unit is used for sorting the transaction amounts with the first number of unequal values according to the sequence of the transaction amount values from small to large to obtain the sorted transaction amounts with the first number of unequal values.
8. The apparatus of claim 7,
the selecting unit is specifically configured to:
determining the ranking of a second service request sent by the first receiver client according to the first timestamp;
selecting a transaction amount corresponding to the ranking from the ranked transaction amounts of the first number of unequal values;
and taking the transaction amount corresponding to the sorting ranking as the transaction amount of the first numerical value.
9. The apparatus according to claim 7 or 8, wherein the dividing unit is specifically configured to:
dividing the total transaction amount into the transaction amounts of the first number of unequal values according to a predefined linear division algorithm; alternatively, the first and second electrodes may be,
dividing the total transaction amount into the transaction amounts of the first number of unequal values according to a predefined non-linear division algorithm.
10. A payment device, the device comprising:
the system comprises a receiving unit, a receiving unit and a processing unit, wherein the receiving unit is used for receiving a collection request sent by a collector client, and the collection request comprises a total payment amount and a first amount of a payer;
the dividing unit is used for dividing the total payment amount received by the receiving unit into the payment amounts with the first number of unequal values according to a predefined dividing algorithm;
the receiving unit is also used for receiving a first payment request sent by a first payer client and receiving a second payment request sent by a second payer client; wherein the first payment request includes a first timestamp, the second payment request includes a second timestamp, and the first timestamp is earlier than the second timestamp;
a selecting unit, configured to select a payment amount of a first numerical value from the payment amounts of the first number of unequal numerical values according to the first payment request received by the receiving unit; selecting a payment amount of a second numerical value from the transaction amounts of the first quantity unequal numerical values according to the second payment request; wherein the first value is less than the second value;
the sending unit is used for returning a request response containing the payment amount of the first numerical value selected by the selecting unit to the first payer client so that the first payer client can complete payment according to the payment amount of the first numerical value; and returning a request response containing the payment amount of the second numerical value to the second payer client so that the second payer client completes payment according to the payment amount of the second numerical value;
and after the first number of payer client sides finish payment, the execution of the collection service of the payee client side is finished.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610634419.1A CN106920083B (en) | 2016-08-05 | 2016-08-05 | Service implementation method, payment method and device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201610634419.1A CN106920083B (en) | 2016-08-05 | 2016-08-05 | Service implementation method, payment method and device |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN106920083A CN106920083A (en) | 2017-07-04 |
| CN106920083B true CN106920083B (en) | 2020-11-24 |
Family
ID=59454507
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201610634419.1A Active CN106920083B (en) | 2016-08-05 | 2016-08-05 | Service implementation method, payment method and device |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN106920083B (en) |
Families Citing this family (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111147348B (en) * | 2018-11-06 | 2021-08-20 | 腾讯科技（深圳）有限公司 | Instant message sending method, device and readable medium |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103500401A (en) * | 2013-09-27 | 2014-01-08 | 华为技术有限公司 | Payment method, device and system |
-
2016
- 2016-08-05 CN CN201610634419.1A patent/CN106920083B/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN103500401A (en) * | 2013-09-27 | 2014-01-08 | 华为技术有限公司 | Payment method, device and system |
Non-Patent Citations (1)
| Title |
|---|
| 微信AA收款怎么使用;用户Fynn_Lee;《百度经验》;20131218;第1-6页 * |
Also Published As
| Publication number | Publication date |
|---|---|
| CN106920083A (en) | 2017-07-04 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106355391B (en) | Service processing method and device | |
| WO2016131365A1 (en) | Information processing method, client, server and computer readable storage medium | |
| CN107231393B (en) | Session processing method and device | |
| CN107248070A (en) | The method and device for group's pre-paid of chatting | |
| CN102254238A (en) | Scalable billing with de-duplication in aggregator | |
| CN110705980A (en) | Method, device and storage medium for processing transaction payment operation based on data analysis | |
| JP2020522822A (en) | Methods, apparatus, and devices for tracking and monitoring software activity | |
| CN109949026B (en) | Red packet information generation method and device, terminal and server | |
| CN111008800B (en) | Data processing method, device, server and storage medium for distribution task | |
| CN110264172A (en) | Transaction processing method and device based on block chain | |
| CN109086289A (en) | A kind of media data processing method, client, medium and equipment | |
| CN111984733A (en) | Data transmission method and device based on block chain and storage medium | |
| WO2017128685A1 (en) | Transaction processing method and transaction system | |
| CN106920083B (en) | Service implementation method, payment method and device | |
| CN109302300A (en) | Data distributing method and device, data processing method and server | |
| CN110602215A (en) | Resource processing method based on alliance block chain and alliance block chain system | |
| CN108229133B (en) | Service operation method and device and service permission obtaining method and device | |
| CN113935821A (en) | Method, device, electronic equipment and medium for settling commission charge in banking business | |
| CN106452816B (en) | Information processing method, server and client | |
| CN105787791B (en) | Service request processing method and device | |
| CN108924145B (en) | Network transmission method, device and equipment | |
| CN115099801A (en) | Payment information processing method and device based on public cloud | |
| CN102254260A (en) | Scalable billing with de-duplication and sequencing | |
| CN109345219B (en) | Collection control method, device, server and readable storage medium | |
| CN114707980A (en) | Method and device for processing collection information based on block chain |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| REG | Reference to a national code |
Ref country code: HK Ref legal event code: DE Ref document number: 1238759 Country of ref document: HK |
|
| TA01 | Transfer of patent application right |
Effective date of registration: 20201015 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Innovative advanced technology Co.,Ltd. Address before: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant before: Advanced innovation technology Co.,Ltd. Effective date of registration: 20201015 Address after: Cayman Enterprise Centre, 27 Hospital Road, George Town, Grand Cayman Islands Applicant after: Advanced innovation technology Co.,Ltd. Address before: A four-storey 847 mailbox in Grand Cayman Capital Building, British Cayman Islands Applicant before: Alibaba Group Holding Ltd. |
|
| TA01 | Transfer of patent application right | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |