Detailed Description
Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the present specification. Rather, they are merely examples of apparatus and methods consistent with some aspects of the present description as detailed in the accompanying claims.
The terminology used in the description presented herein is for the purpose of describing particular embodiments only and is not intended to be limiting of the description. As used in this specification and the appended claims, the singular forms "a," "an," and "the" are intended to include the plural forms as well, unless the context clearly indicates otherwise. It should also be understood that the term "and/or" as used herein refers to and encompasses any or all possible combinations of one or more of the associated listed items.
It should be understood that although the terms first, second, third, etc. may be used in this specification to describe various information, these information should not be limited to these terms. These terms are only used to distinguish one type of information from another. For example, the first information may also be referred to as second information, and similarly, the second information may also be referred to as first information, without departing from the scope of the present description. The word "if" as used herein may be interpreted as "at … …" or "at … …" or "responsive to a determination", depending on the context.
The present disclosure provides an implementation scheme of resource deferred delivery, where a deferrer sends a resource deferred delivery request to a deferred platform, and when the deferred platform confirms that the deferred number does not exceed the credit number of the deferred party, the deferred delivery request is forwarded to a corresponding resource receiver, and when the receiver confirms the deferred delivery request, a resource bill to be delivered is generated for viewing by both the deferred parties, so as to implement online deferred delivery record.
The resources may refer to currency, virtual currency, goods, points, coupons, and the like.
Taking currency as an example, the resource deferred delivery request is typically a credit request.
For example, after a user goes to a restaurant for a meal, the user logs the meal fee off the store and then settles with the restaurant.
For another example, after the company purchases office supplies to the mall, the purchase cost is recorded on the account of the company, and the subsequent company is unified with the mall to settle accounts.
Taking the point as an example, a user may purchase props in a delayed delivery point during a game.
The deferred platform is typically deployed by a service provider that provides deferred recording, delivery reminder, resource delivery, etc., and its physical carrier is typically a server or a cluster of servers.
FIG. 1 is a flow diagram illustrating a method of deferred delivery of resources according to an exemplary embodiment of the present disclosure.
Referring to fig. 1, the method for resource deferred delivery may be applied to a deferred platform, and includes the following steps:
and 102, receiving a resource deferred delivery request sent by a deferrer, wherein the deferred delivery request comprises a resource receiver identifier and a deferred quantity.
In this embodiment, the deferrer may refer to a terminal device, such as a mobile phone, a tablet computer, etc., used by a user initiating the resource deferred delivery request. When applying for deferred delivery, a user can initiate a deferred delivery request, pay a bill of a resource to be delivered and the like through an Application (APP) loaded in the terminal device, for example, the user can log in based on a registered user account.
The resource receiver may refer to a party providing services, goods, virtual objects, etc. at a restaurant, mall, game store, etc.
In this embodiment, a user may access a delay information filling page corresponding to a resource receiver by scanning a two-dimensional code or the like provided by the resource receiver, and fill information such as delay quantity in the page to trigger a delay delivery request, where the delay delivery request carries a resource receiver identifier, and the resource receiver identifier may be information uniquely corresponding to the resource receiver, such as a resource receiver account number, a resource receiver ID, and the like.
And 104, judging whether the delay amount exceeds the credit giving amount of the delay party.
In this embodiment, the deferring platform may obtain credit information of the deferring party from the credit platform, and determine the number of credits of the deferring party. Generally, the better the credit information, the higher the amount of credit.
And step 106, if the delay delivery request is not exceeded, the delay delivery request is sent to the resource receiver.
And step 108, when receiving a confirmation instruction sent by the resource receiver for the deferred delivery request, generating a resource bill to be delivered for the resource receiver for the deferred party according to the deferred quantity.
In this embodiment, after receiving the deferred delivery request, the resource receiver may browse information such as the number of deferred in the deferred delivery request, and if it is confirmed that the information matches with the actual situation, a confirmation instruction may be returned.
And after receiving the confirmation instruction, the deferred platform can generate a resource bill to be delivered according to the deferred delivery request. The payment party of the resource bill is the delay party, the amount of the resource bill is the delay amount in the delay delivery request, and the resource bill can also comprise information such as delivery deadline, delay use, creation date and the like, which is not particularly limited in the specification.
In this embodiment, the deferring platform may further send the resource bill to the deferring party and the resource receiving party for viewing by the deferring party.
As can be seen from the above description, the deferrable party in the present specification may send a resource deferred delivery request to a deferring platform, where the deferring platform may forward the deferred delivery request to a corresponding resource receiver when confirming that the deferred quantity does not exceed the credit quantity of the deferrable party, and generate a resource bill to be delivered when the receiver confirms the deferred delivery request, so as to be checked by both the deferred parties, thereby implementing online deferred delivery record.
The charge realization process of the present specification is described below with reference to a specific application scenario, taking a charge request as a resource delay delivery request, a charge amount as a delay amount, a payee as a resource receiver, and a charge platform as an example.
Taking a restaurant as an example, the payee is a restaurant A, the restaurant can apply for the two-dimension code of the credit on the credit platform in advance, and print the two-dimension code of the credit and place the two-dimension code of the credit on the cash desk. The charge two-dimensional code is bound with the restaurant A, and can carry a URL (Uniform Resource Locator ) through which a charge information filling page corresponding to the restaurant A can be accessed.
Assuming that the xiaobai goes to restaurant a for dinner, the xiaobai wants to credit first, and pays the dinner to restaurant a after wage is issued for a few days from wage. After dining, the xiaobai can scan a credit two-dimensional code placed at a cash desk of the restaurant A, and further jump to a credit information filling page corresponding to the restaurant A.
In other examples, the access to the credit information fill page may also be achieved by clicking on a URL, e.g., the access to the website of restaurant a, clicking on a credit button on the website, etc., which is not particularly limited in this specification.
Referring to the example of fig. 2, based on the charge information, the page is filled in, and the charge amount and the like can be filled in.
Wherein, the payment amount can be a meal fee or less. Assuming that the meal fee is 300 yuan, the tabby can be totally credited, and 300 is filled in at the credited amount; the tabashes may also be partially credited, e.g., the tabashes may pay on site for 200 Yuan, credited for 100 Yuan, etc.
The payment term (i.e., delivery term) is the charge duration. The payment term may be filled by the xiaobai according to its own practical situation, for example, payouts are sent after 9 days, the xiaobai may fill the payment term as 9 days, 10 days, etc.
The payment terms may also be specified by a restaurant, e.g., a restaurant may specify several payment terms for a tabbed selection, e.g.: 10 days, 15 days, 30 days, etc.; the restaurant may also specify a maximum value of a payment term, for example, 30 days, and the xiaobai fills out a payment term of 30 days or less according to actual conditions, which is not particularly limited in this specification.
The charge purpose (namely delay purpose) can be the actual purpose of charge amount such as meal fee, service fee and the like, and can be used for subsequent check of charge parties.
In this embodiment, after the relevant information in the credit information filling page is filled, the send button may be clicked to trigger a credit request, where the credit request carries the relevant information filled in by the small white and the identification information of the restaurant a, for example, the account number of the restaurant a, etc.
Optionally, to ensure the security of the small white account number, after clicking the send button, the charge platform may also authenticate the small white, for example: the prompt xiaobai performs identity verification in the modes of face, fingerprint, password and the like. If the identity verification is passed, the subsequent steps can be executed; if the authentication fails, a rejection prompt for failing the authentication can be returned.
After receiving the charge request, the charge platform can firstly judge whether the small white authorizes the charge platform to call the credit platform to check the credit condition, and if the charge platform is authorized, the charge platform can be directly called to inquire the credit condition of the small white; if not, an authorization protocol can be returned to the xiaobai, and after the xiaobai is successfully authorized, a credit platform is called to inquire the credit condition of the xiaobai. If the xiaobai refuses the authorization, a prompt that the credit cannot be paid can be returned to the xiaobai.
In one example, the credit platform may return a small credit score to the credit platform after receiving the query request sent by the credit platform, and the credit platform determines a small credit limit according to the credit score. Generally, the higher the credit score, the higher the credit limit.
In another example, the credit platform may return a small credit line directly to the access platform after receiving the query request sent by the access platform. The credit limit determining algorithm may be negotiated with the credit platform in advance, which is not limited in this specification.
After the credit platform determines the credit line of the small credit, the credit platform can judge whether the credit amount in the credit request exceeds the credit line.
If the charge amount exceeds the charge amount, an excess prompt can be returned to the small white, and the small white can be retried by modifying the charge amount according to the prompt.
If the credit limit is not exceeded, whether the small white has a credit bill which is not paid yet at present can be inquired, whether the sum of the total amount of the credit bills which are not paid yet and the amount of the credit is exceeded or not is calculated, if the sum exceeds the credit limit, an excess prompt can be returned to the small white, and the small white can modify the amount of the credit according to the prompt for retry. Of course, in practical application, the credit platform can carry the residual credit line of the small white in the excess prompt to return, so as to facilitate the modification of the small white.
If the record is not exceeded, the method can also inquire whether the white is in the history of checking the record of checking the bill and the like, if the record exists, a prompt for refusing the checking the bill can be returned to the white.
If not, the white paper can be confirmed to pass the credit check. Of course, in practical application, the threshold of the number of violations may also be set, the credit is refused when the threshold of the number of violations is reached, and the credit is allowed when the threshold of the number of violations is not reached, which is not particularly limited in the specification.
The present specification is not limited to the above-described execution order of the judgment of the credit line and the judgment of the history violation, and in other examples, the violation judgment may be performed first, the parallel thread may be started, and the judgment may be started simultaneously.
In this embodiment, the credit request may be forwarded to restaurant A when the receipt is confirmed to pass the credit audit. For example, push to restaurant A based on restaurant A account.
After receiving the credit request, the staff of restaurant A can confirm the information in the credit request.
For example, it may be confirmed whether the charge amount is the same as the current meal or whether the charge amount plus the amount paid by the user is the same as the current meal.
For another example, it may be confirmed whether the payment deadline meets a restaurant-specified deadline, or the like.
If a certain item of information is found to be wrong, a rejection instruction can be returned to the credit platform, meanwhile, the rejection reason can be prompted, and the credit platform can further return the rejection instruction and the rejection reason to the xiaobai.
For example, assuming that the restaurant staff member finds that the charge amount is less than the current meal fee and the user has not paid the balance online, the charge can be rejected and the reject cause amount is sent to the charge platform and forwarded to the tabby the charge platform. The xiao bai can modify the credit amount after receiving the reject reason and can reinitiate the credit request after modification.
If the staff member confirms that all the information of the credit request is correct, a confirmation instruction can be sent to the credit platform and a small white store is allowed to leave.
After receiving the confirmation instruction, the charge platform can generate a corresponding charge bill according to the charge request, and the payment state of the charge bill is to be paid.
The charge bill may include: information such as credit amount, payment term, xiaobai identification, a restaurant identification, creation date, credit use, etc. The payer of the charge bill is a small white, and the payee is restaurant A.
The charge platform may push the charge bill to the small white and restaurant a for viewing.
Both the xiaobai restaurant a and the xiaobai restaurant a can query all charge bills and payment status thereof from the charge platform. For example, the tabbed white may query all of his individual's charge bills, and may also query charge summary information, such as charge total, charge total that has not yet been paid, credit limits, and the like; restaurant A may also query all of the credit bills of the restaurant, and may also query the A restaurant credit summary information, such as the total amount of credit, the amount of credit that has not been paid, and so on.
In this embodiment, the charge bill may be maintained using blockchain technology to ensure that the charge bill is accurate and not tampered with.
Aiming at the problem that the payment is forgotten by the buyer, the buyer is owed maliciously, the seller is not willing to pay for the account, and the like in the credit account, the credit account scheme recorded in the specification also provides measures such as bill payment reminding, bill deduction, credit punishment and the like.
Taking the foregoing description of the taking a restaurant for a meal, to avoid forgetting, when the payment period in the charge bill is reached, the charge platform may send a payment reminder to the taking, which may click to view the charge bill and make a payment. Of course, the timing of sending the payment reminder is not limited to the time of reaching the payment period, and in other examples, the charge platform may send the payment reminder before reaching the payment period, for example, send the payment reminder the day before reaching the payment period, which is not particularly limited in this specification.
In this embodiment, if the small white pays the credit bill on schedule, the credit platform may record the performance of the small white, and may return the performance to the credit platform, and the credit platform may forward update the credit score of the small white.
Alternatively, the credit platform may update the previously acquired credit score for the small white, which is not particularly limited in this specification.
If the small white is not paid on schedule, the credit platform can record the default behavior of the small white, and can return the default behavior to the credit platform, and the credit score of the small white is negatively updated by the credit platform. Meanwhile, if the charge platform receives the charge request sent by the small white again, a prompt for rejecting the charge is returned to the small white.
The foregoing charge platform and credit platform may be used for synchronizing the user's performance/default behavior offline, and the detailed description will not be repeated herein with reference to the synchronization method provided in the related art.
In this embodiment, if the small white authorized access platform deducts the access amount, when the payment period of the access bill is reached, the access platform may also deduct the access amount from the small white designated access account number to pay to restaurant a.
The bill paying reminding, bill deduction, credit punishment and other modes are used for restraining the charge party to pay the charge bill on schedule, so that the charge party is provided with the charge guaranteeing service, the benefit of the charge party is maintained, and the popularization of charge behavior is facilitated.
Optionally, the present specification also provides a single-free function. For a charge bill that has not been paid, the payee may be a charge party order free.
Taking the foregoing description of the take a restaurant for a small white, if the small white subsequently goes to the restaurant to calculate a meal fee, the staff member may send a no-order request (i.e., no-payment request) to the charge platform for the small white charge bill, e.g., the staff member may click a no-order button in a view page of the charge bill. After receiving the order-free request, the charge platform can modify the payment state of the charge bill from to-be-paid to paid.
Corresponding to the embodiments of the method for resource deferred delivery described above, the present description also provides embodiments of an apparatus for resource deferred delivery.
Embodiments of the apparatus for deferred delivery of resources of the present specification may be applied to a server. The apparatus embodiments may be implemented by software, or may be implemented by hardware or a combination of hardware and software. Taking software implementation as an example, the device in a logic sense is formed by reading corresponding computer program instructions in a nonvolatile memory into a memory by a processor of a server where the device is located. In terms of hardware, as shown in fig. 3, a hardware structure diagram of a server where a device for deferred delivery of resources in this specification is located is shown, and in addition to a processor, a memory, a network interface, and a nonvolatile memory shown in fig. 3, the server where the device is located in an embodiment generally includes other hardware according to an actual function of the server, which is not described herein again.
Fig. 4 is a block diagram of an apparatus for deferred delivery of resources according to an exemplary embodiment of the present disclosure.
Referring to fig. 4, the apparatus 300 for deferred delivery of resources may be applied to the server shown in fig. 3, and includes: a deferred request unit 301, a trust judgment unit 302, a deferred transmission unit 303, a bill generation unit 304, a credit update unit 305, a refusal deferred unit 306, a no-payment unit 307, and a page return unit 308.
The deferred request unit 301 receives a resource deferred delivery request sent by a deferrer, where the deferred delivery request includes a resource receiver identifier and a deferred number;
a trust judgment unit 302, configured to judge whether the delay amount exceeds the trust amount of the delay party;
a deferred sending unit 303, configured to send the deferred delivery request to the resource receiver if the deferred delivery request does not exceed the deferred delivery request;
and the bill generating unit 304 generates a resource bill to be delivered for the resource receiver according to the delay quantity when receiving a confirmation instruction sent by the resource receiver for the delay delivery request.
Optionally, the deferred delivery request further includes a delivery deadline;
the apparatus further comprises:
and a credit updating unit 305, configured to forward update credit information of the deferrer if the deferrer delivers the resource bill on schedule, where the credit information is used to determine the credit amount of the deferrer.
And a refusing deferring unit 306, if the deferrer does not deliver the resource bill according to the time, returning a prompt of refusing deferring to the deferrer when receiving the resource deferring delivery request sent by the deferrer again.
And a delivery-free unit 307 for updating the delivery status of the resource bill to delivered in response to the delivery-free request sent by the resource receiving party for the resource bill to be delivered.
A page returning unit 308, configured to return a deferred information filling page corresponding to the resource receiver to the deferring party in response to the deferring party triggering a deferred page access request corresponding to the resource receiver through a specified path;
the deferred delivery request is sent by a deferrer to fill out a page based on the deferred information.
Optionally, the specified pathway includes one or more of:
scanning a two-dimensional code bound with the resource receiver, and clicking a URL bound with the resource receiver.
Optionally, the bill generation unit 304 maintains the resource bill based on a blockchain technique.
The implementation process of the functions and roles of each unit in the above device is specifically shown in the implementation process of the corresponding steps in the above method, and will not be described herein again.
For the device embodiments, reference is made to the description of the method embodiments for the relevant points, since they essentially correspond to the method embodiments. The apparatus embodiments described above are merely illustrative, wherein the elements illustrated as separate elements may or may not be physically separate, and the elements shown as elements may or may not be physical elements, may be located in one place, or may be distributed over a plurality of network elements. Some or all of the modules may be selected according to actual needs to achieve the purposes of the present description. Those of ordinary skill in the art will understand and implement the present invention without undue burden.
The system, apparatus, module or unit set forth in the above embodiments may be implemented in particular by a computer chip or entity, or by a product having a certain function. A typical implementation device is a computer, which may be in the form of a personal computer, laptop computer, cellular telephone, camera phone, smart phone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or a combination of any of these devices.
Corresponding to the foregoing embodiments of the method for delivering a resource delay, the present disclosure further provides an apparatus for delivering a resource delay, where the apparatus includes: a processor and a memory for storing machine executable instructions. Wherein the processor and the memory are typically interconnected by means of an internal bus. In other possible implementations, the device may also include an external interface to enable communication with other devices or components.
In this embodiment, the processor is caused to, by reading and executing the machine-executable instructions stored by the memory corresponding to the logic of the resource deferral delivery:
receiving a resource deferred delivery request sent by a deferrer, wherein the deferred delivery request comprises a resource receiver identifier and a deferred quantity;
judging whether the delay quantity exceeds the credit giving quantity of the delay party or not;
if the delay delivery request does not exceed the delay delivery request, the delay delivery request is sent to the resource receiver;
when a confirmation instruction sent by the resource receiver for the deferred delivery request is received, generating a resource bill to be delivered for the resource receiver for the deferred party according to the deferred quantity.
Optionally, the deferred delivery request further includes a delivery deadline;
the processor is further caused to:
and if the delay party delivers the resource bill on schedule, forward updating the credit information of the delay party, wherein the credit information is used for determining the credit giving quantity of the delay party.
Optionally, the processor is further caused to:
and if the deferrer does not deliver the resource bill according to the schedule, returning a prompt for refusing the deferring to the deferrer when the resource deferring delivery request sent by the deferrer is received again.
Optionally, the processor is further caused to:
and in response to a no-delivery request sent by the resource receiving party aiming at the resource bill to be delivered, updating the delivery state of the resource bill to be delivered.
Optionally, the processor is further caused to:
responding to a deferring party to trigger a deferring page access request corresponding to the resource receiver through a designated approach, and returning a deferring information filling page corresponding to the resource receiver to the deferring party;
the deferred delivery request is sent by a deferrer to fill out a page based on the deferred information.
Optionally, the specified pathway includes one or more of:
scanning a two-dimensional code bound with the resource receiver, and clicking a URL bound with the resource receiver.
Optionally, the processor is further caused to:
the resource bill is maintained based on a blockchain technique.
Corresponding to the embodiments of the method of resource deferred delivery described above, the present description also provides a computer-readable storage medium having stored thereon a computer program which, when executed by a processor, performs the steps of:
receiving a resource deferred delivery request sent by a deferrer, wherein the deferred delivery request comprises a resource receiver identifier and a deferred quantity;
judging whether the delay quantity exceeds the credit giving quantity of the delay party or not;
if the delay delivery request does not exceed the delay delivery request, the delay delivery request is sent to the resource receiver;
when a confirmation instruction sent by the resource receiver for the deferred delivery request is received, generating a resource bill to be delivered for the resource receiver for the deferred party according to the deferred quantity.
Optionally, the deferred delivery request further includes a delivery deadline;
the method further comprises the steps of:
and if the delay party delivers the resource bill on schedule, forward updating the credit information of the delay party, wherein the credit information is used for determining the credit giving quantity of the delay party.
Optionally, the method further comprises:
and if the deferrer does not deliver the resource bill according to the schedule, returning a prompt for refusing the deferring to the deferrer when the resource deferring delivery request sent by the deferrer is received again.
Optionally, the method further comprises:
and in response to a no-delivery request sent by the resource receiving party aiming at the resource bill to be delivered, updating the delivery state of the resource bill to be delivered.
Optionally, the method further comprises:
responding to a deferring party to trigger a deferring page access request corresponding to the resource receiver through a designated approach, and returning a deferring information filling page corresponding to the resource receiver to the deferring party;
the deferred delivery request is sent by a deferrer to fill out a page based on the deferred information.
Optionally, the specified pathway includes one or more of:
scanning a two-dimensional code bound with the resource receiver, and clicking a URL bound with the resource receiver.
Optionally, the method further comprises:
the resource bill is maintained based on a blockchain technique.
The foregoing describes specific embodiments of the present disclosure. Other embodiments are within the scope of the following claims. In some cases, the actions or steps recited in the claims can be performed in a different order than in the embodiments and still achieve desirable results. In addition, the processes depicted in the accompanying figures do not necessarily require the particular order shown, or sequential order, to achieve desirable results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
The foregoing description of the preferred embodiments is provided for the purpose of illustration only, and is not intended to limit the scope of the disclosure, since any modifications, equivalents, improvements, etc. that fall within the spirit and principles of the disclosure are intended to be included within the scope of the disclosure.