CN114997938A

CN114997938A - Invoice request processing method, device and equipment

Info

Publication number: CN114997938A
Application number: CN202210593337.2A
Authority: CN
Inventors: 舒杰
Original assignee: Alipay Hangzhou Information Technology Co Ltd
Current assignee: Alipay Hangzhou Information Technology Co Ltd
Priority date: 2022-05-27
Filing date: 2022-05-27
Publication date: 2022-09-02
Also published as: WO2023226799A1

Abstract

The embodiment of the specification discloses an invoice request processing method, device and equipment. The scheme can comprise the following steps: after obtaining a billing request message for requesting a target transaction to provide invoice information corresponding to the target transaction to a second party by a first party, judging whether the first party provides the invoice information within a first time after the initiation time of the billing request message, and if not, processing the first party.

Description

Invoice request processing method, device and equipment

Technical Field

The present application relates to the field of invoice technologies, and in particular, to an invoice request processing method, apparatus, and device.

Background

With the continuous progress of internet technology, electronic commerce has been rapidly developed. People are gradually starting to perform various business activities based on transaction applications, payment applications and the like in an internet open network environment to realize transaction activities between consumers and merchants. Currently, after a consumer completes a transaction with a merchant, the merchant may need to provide corresponding invoice information to the consumer to ensure the consumer's rights, but some merchants have a condition of delaying invoice provision.

Based on this, how to improve the processing efficiency of the merchant for the invoice request becomes a technical problem to be solved urgently.

Disclosure of Invention

The invoice request processing method, device and equipment provided by the embodiment of the specification can improve the processing efficiency of a merchant on an invoice request.

In order to solve the above technical problem, the embodiments of the present specification are implemented as follows:

an invoice request processing method provided by an embodiment of the present specification includes:

acquiring an invoicing request message aiming at a target transaction; the invoicing request message is used for requesting a first party of the target transaction to provide invoice information corresponding to the target transaction to a second party;

determining the initiation time of the billing request message;

judging whether the first party provides the invoice information to the second party within a first time after the initiation time to obtain a first judgment result;

and if the first judgment result shows that the first party does not provide the invoice information to the second party within a first time period after the initiation time, processing the first party.

An invoice request processing apparatus provided in an embodiment of the present specification includes:

the first acquisition module is used for acquiring an invoicing request message aiming at the target transaction; the invoicing request message is used for requesting a first party of the target transaction to provide invoice information corresponding to the target transaction to a second party;

the determining module is used for determining the initiation time of the billing request message;

a first judging module, configured to judge whether the first party provides the invoice information to the second party within a first time period after the initiation time, to obtain a first judgment result;

and the processing module is used for processing the first party if the first judgment result shows that the first party does not provide the invoice information to the second party within a first time period after the initiation time.

at least one processor; and the number of the first and second groups,

a memory communicatively coupled to the at least one processor; wherein,

the memory stores instructions executable by the at least one processor to enable the at least one processor to:

acquiring an invoicing request message aiming at target transaction; the invoicing request message is used for requesting a first party of the target transaction to provide invoice information corresponding to the target transaction to a second party;

determining the initiation time of the billing request message;

At least one embodiment provided in the present specification can achieve the following advantageous effects:

after obtaining a billing request message for requesting a target transaction to provide invoice information corresponding to the target transaction to a second party by a first party, judging whether the first party provides the invoice information within a first time after the initiation time of the billing request message, and if not, processing the first party. Therefore, the first party can provide the invoice corresponding to the target transaction to the second party within the specified time period, the situation that the first party delays providing the invoice is reduced, the processing efficiency of the first party on the invoice request of the second party is improved, meanwhile, the response rate of the first party on the invoice request of the second party is improved, and the second party can obtain the invoice corresponding to the target transaction.

Drawings

In order to more clearly illustrate the embodiments of the present specification or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the description below are only some embodiments described in the present application, and for those skilled in the art, other drawings may be obtained according to the drawings without creative efforts.

Fig. 1 is a schematic view of an application scenario of an invoice request processing method provided in an embodiment of the present specification;

FIG. 2 is a flowchart illustrating an invoice request processing method according to an embodiment of the present disclosure;

FIG. 3 is a swim lane flow diagram corresponding to the invoice request processing method in FIG. 2, provided by an embodiment of the present specification;

FIG. 4 is a schematic structural diagram of an invoice request processing apparatus corresponding to FIG. 2 provided in an embodiment of the present specification;

fig. 5 is a schematic structural diagram of an invoice request processing apparatus corresponding to fig. 2 provided in an embodiment of the present specification.

Detailed Description

To make the objects, technical solutions and advantages of one or more embodiments of the present disclosure more apparent, the technical solutions of one or more embodiments of the present disclosure will be described in detail and completely with reference to the specific embodiments of the present disclosure and the accompanying drawings. It is to be understood that the embodiments described are only a few embodiments of the present specification, and not all embodiments. All other embodiments that can be derived by a person skilled in the art from the embodiments given herein without making any creative effort fall within the scope of protection of one or more embodiments of the present specification.

The technical solutions provided by the embodiments of the present description are described in detail below with reference to the accompanying drawings.

In the prior art, a consumer and a merchant can conduct transactions based on transaction application, payment application and the like, and the consumer and the merchant can communicate with each other according to invoice issuing items, so that invoice information required by the merchant is agreed. However, some merchants have the condition of delaying or even refusing to provide invoices, which not only seriously affects the rights and benefits of consumers, but also affects the use experience of consumers for the e-commerce technology. Therefore, how to improve the processing efficiency of the merchant on the invoice request of the consumer to ensure that the consumer can quickly obtain the invoice becomes a problem which needs to be solved urgently.

In order to solve the defects in the prior art, the scheme provides the following embodiments:

fig. 1 is a schematic application scenario diagram of an invoice request processing method provided in an embodiment of the present specification.

As shown in fig. 1, a payment application and a transaction application may be installed in a device 101 of a second party (e.g., a consumer) of a target transaction, and the second party may conduct the target transaction with a first party (e.g., a merchant) based on the payment application and the transaction application, and send an invoicing request message for the target transaction to a target server 102; the invoicing request message may be for requesting the first party to provide invoice information corresponding to the target transaction to the second party.

The target server 102 may generate invoice order information according to the invoicing request message, and send the invoice order information to the device 103 of the first party, so that the first party knows and processes the invoice order information, thereby providing invoice information to the second party in response to the invoicing request message.

Target server 102 may also determine an origination time of the invoice request message; judging whether the first party provides the invoice information to the second party within a first time after the initiation time, if so, processing the first party is not needed, and skipping to the end; if not, the first participant can be processed. The target server 102 may also generate the processing result for the first party to the first party's device 103 to let the first party know the processing result.

Next, an invoice request processing method provided by the embodiments of the specification will be specifically described with reference to the accompanying drawings:

fig. 2 is a flowchart illustrating an invoice request processing method according to an embodiment of the present disclosure. From a program perspective, the execution subject of the flow may be the target server, or an application hosted at the target server. The target server may be a server of a target application, where the target application may include: the second party is directed to a payment application used to pay for the target transaction or the second party executes a transaction application used for the target transaction.

As shown in fig. 2, the process may include the following steps:

step 202: acquiring an invoicing request message aiming at a target transaction; the invoicing request message is used for requesting a first party of the target transaction to provide invoice information corresponding to the target transaction to a second party.

In the embodiments of the present description, the first party is typically a merchant, and the second party is typically a consumer. After the second party and the first party perform the target transaction, the second party may request the first party to provide an invoice corresponding to the target transaction, so that the target server obtains an invoicing request message for the target transaction.

The invoice (invoice) may refer to the business certificate issued and collected by a unit or an individual in purchasing and selling goods, providing or receiving services, and performing other business activities. Typically, printing, purchase, issuing, obtaining, keeping, and reimbursement of invoices are managed and supervised by authorities.

In practical applications, the second party may request the first party to invoice all the transaction contents of the target transaction, or may request the first party to invoice part of the transaction contents of the target transaction, which is not limited in particular.

Step 204: and determining the initiation time of the billing request message.

In this embodiment of the present specification, the target server needs to identify whether the first party provides the second party with the invoice corresponding to the target transaction within a specified time period, and therefore, the start time and the end time of the specified time period need to be determined. In general, the starting time of the invoicing request message can be used as the starting time of the specified time period, and the time which is after the starting time and has the first time interval can be used as the ending time of the specified time period. The first time period may be preset according to actual requirements, and is not particularly limited to this, for example, the first time period is 10 days, 15 days, and the like.

Step 206: and judging whether the first party provides the invoice information to the second party within a first time after the initiation time to obtain a first judgment result.

In this embodiment of the present specification, the first party may provide the invoice information to the second party using the merchant client, or the first party may upload, at the merchant client, proof information that may characterize that the first party has provided the invoice information to the second party, so that the target server may determine whether the first party provided the invoice information to the second party within a first time period after the initiation time. The merchant client may be an application program provided by a service provider of the transaction application and used by a first participant for managing the target transaction, or a payment application used by a second participant for paying for the target transaction, or an application program or applet developed and deployed by the first participant by itself and used for managing the target transaction; in practical applications, the merchant client in the form of an applet may be installed in a transaction application or a payment application.

Step 208: and if the first judgment result shows that the first party does not provide the invoice information to the second party within a first time period after the initiation time, processing the first party.

In this embodiment of the present specification, if it is determined that the first party does not provide the invoice information to the second party within the first time period after the initiation time, it may generally indicate that the first party has a condition of delaying providing the invoice, and therefore, the first party may be processed according to a preset processing policy. The preset processing strategy may be set according to actual requirements, which is not specifically limited. For example, the predetermined processing policy may be to penalize a first party and/or to compensate a second party, etc., so as to prompt the first party to provide an invoice to the second party as scheduled to ensure the efficiency of the first party's processing of the invoice request.

In this embodiment, step 206 may further include: step 210: if the first determination result indicates that the first party provides the invoice information to the second party within a first time period after the initiation time, the processing of the first party may be prohibited, and the process may skip to the end. This is because in this case it can generally be said that the first party has provided the invoice as due within a reasonable period of time, and therefore there is no need to deal with the first party and to compensate the second party. Meanwhile, since the first party has provided the invoice to the second party, it may indicate that the invoice order for the target transaction is completed, i.e., the response to the invoice request message has been completed, and thus may jump to the end.

In the method in fig. 2, after obtaining a billing request message for requesting a target transaction, where a first party provides invoice information corresponding to the target transaction to a second party, if it is determined that the first party does not provide the invoice information within a first time period after the initiation time of the billing request message, the first party may be processed. Therefore, the first party can provide the invoice corresponding to the target transaction to the second party within the specified time period, the situation that the first party delays providing the invoice is reduced, the processing efficiency of the first party on the invoice request of the second party is improved, meanwhile, the response rate of the first party on the invoice request of the second party is improved, and the second party can obtain the invoice corresponding to the target transaction.

Based on the method in fig. 2, some specific embodiments of the method are also provided in the examples of this specification, which are described below.

In the embodiments of the present description, there are various ways to execute the target transaction between the second party and the first party.

Transaction mode one

The target transaction may be a transaction between the first party and the second party initiated by the second party using the transaction application. In particular, the second party may invoke a payment application based on the transaction application to make payment for the target transaction using the individual's resources at the payment application. Wherein the transaction application comprises: an e-commerce platform and an applet deployed by the first party at the payment application.

Trade mode two

The target transaction may be an offline transaction. Specifically, a payment code image of the second party may be generated using the payment application and presented to the first party for payment for the target transaction.

In practice, the second party may generate a first payment code image at the payment application for making a payment with the resource in the second party's personal payment account for making a payment for the target transaction.

Alternatively, if the second user has acquired the usage right for the resource in the payment account of the first user at the payment application, the second user may generate a second payment code image for making a payment using the resource in the payment account of the first user at the payment application to make a payment for the target transaction. For example, the first user may be a business where the second user is located, and if the target transaction is a transaction executed by the second user by public and the first user can apply for reimbursement, the second user may use the second payment code image for payment based on the resource in the payment account of the first user to pay for the target transaction, so as to simplify the reimbursement process. At this time, both the first user and the second user may act as second parties.

In this embodiment of the present description, because there are various ways of performing the target transaction between the second party and the first party, the second party may request to invoice information of the target transaction in various ways, and accordingly, there may be various ways of implementing obtaining the invoice request message for the target transaction. This is explained for ease of understanding.

Implementation mode one

Step 202: acquiring an invoicing request message for a target transaction, specifically, the acquiring may include:

acquiring a first invoicing request message aiming at a target transaction; the first ticketing request message is generated based on a triggering operation of the second participant for a first ticketing control at a target application, the first ticketing control being a control that is presented after the target transaction is in a completed state. And the first invoicing control is used for requesting to invoice information corresponding to the target transaction.

Correspondingly, step 204: the determining the initiation time of the billing request message specifically includes:

determining the occurrence time of the triggering operation.

In this specification, the target application may include: the second party is directed to a payment application used for payment of the target transaction and/or the second party executes a transaction application used for the target transaction.

This is because, typically, the target transaction will be in a completed state after the money paid by the second party for the target transaction is released to the first party. The transaction information display page at the transaction application of the second participant and the bill information display page at the payment application can display the transaction information of the target transaction for reference, and at the moment, the transaction information display page and the bill information display page can also display a first billing control corresponding to the transaction information of the target transaction.

When the second party needs to make the first party provide an invoice corresponding to the target transaction, the first invoicing control can be triggered, so that the server of the e-commerce platform obtains a first invoicing request message for the target transaction. Specifically, if the target server monitors a trigger event for the first invoicing control, it may be determined that the first invoicing request message for the target transaction is obtained.

In this embodiment of the specification, because the first invoicing control is a control that is displayed after the target transaction is in the completed state, and after the target transaction is in the completed state, the first party can invoice the target transaction, so that when the second party triggers the first invoicing control, the invoicing time consumption timing can be performed, so as to subsequently determine whether the first party provides the second party with invoice information corresponding to the target transaction within a specified time period. Based on this, the occurrence time of the triggering operation of the second party on the first ticketing control can be used as the initiation time of the ticketing request message for the target transaction, that is, the occurrence time of the triggering operation of the second party on the first ticketing control can be used as the starting time of the specified time period.

In practical applications, the ending time of the specified time period may be a time that is a first time after the occurrence time of the triggering operation for the first invoicing control. And the time interval between the current time and the end time of the specified time period can be used as the remaining time period for which the first party should provide the invoice information corresponding to the target transaction. To enhance the experience of the second participant, the remaining duration may also be exposed at the target application of the second participant.

Implementation mode two

acquiring a second invoicing request message aiming at the target transaction; the second invoicing request message is generated based on a state change operation of the target transaction to a completed state, the target transaction is a transaction in which the second participant executes a trigger operation on a second invoicing control at the target application, and the second invoicing control is a control displayed before the target transaction is in the completed state.

Correspondingly, step 204: determining the initiation time of the billing request message may specifically include:

determining an occurrence time of the state change operation.

In this embodiment of the present specification, the second party may also perform an operation of requesting to issue invoice information corresponding to the target transaction before the target transaction is not completed, and then, after the target transaction is changed to the completed state, the time consumed for issuing the invoice may be counted, so as to determine whether the first party provides the invoice information corresponding to the target transaction to the second party within a specified time period.

In practical application, a second invoicing control can be arranged in a commodity display page at the transaction application of the second party, so that when the second party initiates the target transaction, the second party triggers the second invoicing control to execute the operation of requesting to invoice information corresponding to the target transaction, and the operation is convenient and fast.

Or, the transaction information display page at the transaction application of the second party and the bill information display page at the payment application may display the transaction information of the target transaction for reference, and a second invoicing control corresponding to the transaction information of the target transaction may be provided, so that the second party performs the operation of requesting to invoice the corresponding invoice information of the target transaction by triggering the second invoicing control after paying for the target transaction but before the money is not issued to the first party, thereby improving the execution flexibility of the user applying for the invoicing operation.

In practical applications, since the target transaction is changed from the incomplete state to the complete state after the money paid by the second party for the target transaction is issued to the first party, that is, the state change operation for changing the target transaction to the complete state is performed, if the target server monitors an event that the money paid by the second party for the target transaction is issued to the first party or an event that the target transaction is completed, it may be determined that the second invoicing request message for the target transaction is acquired.

Correspondingly, the occurrence time of the state change operation for changing the target transaction into the completed state may be used as the initiation time of the invoicing request message of the target transaction (i.e. the time when the target server listens to the above event is used as the initiation time of the invoicing request message for the target transaction), so as to facilitate the subsequent determination of whether the first party provides the second party with invoice information corresponding to the target transaction within the specified time period. The starting time of the specified time period may be the occurrence time of the state change operation, and the ending time of the specified time period may be a time that is a first time interval after the occurrence time of the state change operation.

In practical application, a time interval between the current time and the end time of the specified time period may be used as a remaining time length for which the first party should provide invoice information corresponding to the target transaction, so as to improve experience of the second party, and prompt information of the remaining time length may be displayed at the target application of the second party.

In this embodiment of the present specification, each of the first billing control and the second billing control may include a single control, or may include multiple controls, which is not limited in particular. For example, when the second party has entered the relevant information such as the name of the purchaser, the taxpayer identification number of the purchaser, the invoice type and the like at the target application, the target application may set a single control as the first billing control or the second billing control, thereby implementing the one-key billing function, which is beneficial to simplifying the billing operation of the second party. Or, the first invoicing control and the second invoicing control may also both include a control for inputting related invoice information and a confirmation control, so that the second party may input related invoice information in real time based on the controls, and may request to invoice corresponding to the target transaction by triggering the confirmation control, which is more flexible.

In practical application, the display of the first billing control and the second billing control at the target application of the second participant can be controlled according to the setting information of the first participant. For example, based on the setting information of the first party, a second billing control may be presented in a merchandise presentation page at the target application; or the first invoicing control and the second invoicing control can be displayed in the transaction information display page at the target application based on the setting information of the first party. Or, based on the setting information of the first participant, both the first billing control and the second billing control are displayed, which is not particularly limited.

In the embodiment of the present specification, when performing an operation of requesting to issue an invoice, the second party usually needs to provide information such as buyer information and invoice type in the invoice, and in practical applications, the second party may have a need to modify the information.

Based on this, step 202: after obtaining the invoicing request message for the target transaction, the method may further include:

acquiring an invoice change request message of the second party for the target transaction; the invoice change request message is generated based on an invoice information change operation performed by the second party at the target application, the invoice information change operation requesting a change to the invoice information.

The determining the initiation time of the billing request message specifically includes:

and determining the occurrence time of the invoice information change operation.

In this embodiment, the invoice information change operation performed by the second party at the target application may include: a partial refund operation for the target transaction, and a modification operation for variable information in the invoice information.

Specifically, when the second party performs a partial refund for the target transaction, the goods information and the tax amount information in the invoice information are affected, so that the invoice information of the target transaction needs to be modified. Based on this, when the target server monitors that the second party performs a partial refund operation for the target transaction, it may be determined that the invoice change request message for the target transaction by the second party is acquired. Of course, the first party may also actively perform a partial refund for the target transaction, and at this time, if the target server monitors a partial refund operation of the first party for the target transaction, it may also be determined that the invoice change request message for the target transaction by the second party is obtained.

Or, an invoice modification control can be further arranged in the transaction information display page at the transaction application and the bill information display page at the payment application, and the second party can modify and submit variable information in the invoice information by triggering the invoice modification control. Based on this, when the target server monitors the operation information of the second party on the invoice modification control, it may be determined that the invoice change request message of the second party on the target transaction is obtained. Wherein, the variable information in the invoice information may include but is not limited to: the name of the purchaser, the address, the account, the taxpayer identification number, the invoice type and the like.

Because the invoice information needs to be modified when the invoice change request message for the target transaction is acquired, the second party initiates the invoicing request message again, and based on the invoice change request message, the time consumed for providing the invoice information for the target transaction by the first party can be set to zero and the time can be counted again to ensure the rights and interests of the first party. Specifically, the occurrence time of the invoice information change operation may be used as the initiation time of the updated invoice request message, and correspondingly, in step 206, it may be determined whether the first party provides the invoice information of the target transaction to the second party within a first time period after the occurrence time of the invoice information change operation, so as to obtain a first determination result.

In practical application, the second party can execute the invoice information change operation before the invoice corresponding to the target transaction is obtained, so that the problem that the invoice issued by the first party does not meet the requirement of the second party is avoided. Or, the second party may also execute the invoice information change operation after acquiring the invoice corresponding to the target transaction, so as to ensure that the second party acquires the required invoice; for the invoice already acquired by the second party, the first party may invalidate the invoice counterpulsation operation through the invoice, so as to ensure normal operation of the invoice service, which is not specifically limited. However, if the invoice information change operation is executed after step 208, since the scheme in fig. 2 has been executed, it is not necessary to use the occurrence time of the invoice information change operation as the initiation time of the updated invoice request message, and it is also not necessary to change the processing result for the first party, so as to ensure the rationality of the processing for the first party.

In this embodiment of the present description, if the first party recognizes that there is an obvious error in the variable information in the invoice information submitted by the second party, the first party may also reject to invoice, and cause the second party to perform a modification operation on the variable information in the invoice information, so as to ensure that the first party can invoice correctly.

Based on this, before the obtaining the invoice change request message for the target transaction by the second party, the method may further include:

and acquiring a ticket refusing instruction of the first participant for the target transaction.

Responding to the order of refusing to invoice, and sending invoice change prompt information to equipment of the second party; and the invoice change prompt message is used for prompting the second party to change the invoice message.

In this embodiment of the present specification, the first party may display the invoice order information of the target transaction at the merchant client, so that the first party performs invoice management based on the invoice order information. In practical application, a negative invoicing control corresponding to the invoice order information of the target transaction may be displayed at the merchant client, and the first party may trigger the negative invoicing control to send a negative invoicing instruction for the target transaction to the target server.

In practice, the first party will usually need to provide a reason for the rejection of the invoice in order for the second party to specify the information that needs to be modified. Based on this, the invoice change prompting message sent by the target server to the second party can reflect the reason for refusing to invoice and/or the modification suggestion, so that the second party can execute the invoice change operation by referring to the invoice change prompting message.

In practical applications, if the first party rejects invoicing and the second party needs to modify the relevant invoice information, the second party is usually required to modify within a preset time limit, and if the second party does not modify within the preset time limit, the second party can be considered as no longer requiring invoicing, so that the process can be skipped to the end without being directed to the first party.

Based on this, after the sending the invoice alteration prompting message to the device of the second party, the method may further include:

and judging whether the invoice change request message is acquired within a second time length after the invoice drawing rejection instruction is generated, and acquiring a second judgment result.

If the second determination result indicates that the invoice change request message is acquired within a second time period after the invoice rejection instruction is generated, step 204 may determine the occurrence time of the invoice information change operation corresponding to the invoice change request message as the initiation time of the updated invoice change request message, and step 206 may determine whether the first party provides the invoice information of the target transaction to the second party within a first time period after the occurrence time of the invoice information change operation.

And if the second judgment result shows that the invoice change request message is not acquired within a second time length after the invoice drawing rejection instruction is generated, forbidding the first party from processing, and skipping to the end.

In this embodiment of the present description, the first party may have a plurality of implementation manners for issuing an invoice, and the invoice type may also have a plurality of types, and correspondingly, the target server may also have a plurality of implementation manners for verifying whether the first party provides the invoice to the second party.

Based on this, step 206: determining whether the first party provides the invoice information to the second party within a first time period after the initiation time may specifically include:

judging whether invoice information corresponding to the target transaction is generated according to an invoice issuing instruction of the first participant within a first time length after the initiation time; and/or the presence of a gas in the gas,

determining whether the first party submitted invoice information corresponding to the target transaction within a first time period after the initiation time.

In the embodiment of the present specification, there are various implementations of invoicing by the first party. For example, the first party may invoice based on the merchant client's invoicing function. Specifically, the first party needs to input an invoice issuing instruction in the merchant client, so that the merchant client and the target server automatically issue invoice information corresponding to the target transaction based on the invoice issuing instruction. Since the generation process of this invoice information can be controlled and identified by the target server, step 206 can determine whether the invoice information corresponding to the target transaction is generated according to the invoice issuing instruction of the first party within a first time period after the initiation time.

Or, the first party may also issue an invoice based on Enterprise management software (ERP), or certainly, may also issue an invoice online based on other manners, at this time, the first party needs to submit invoice information corresponding to the target transaction to the merchant client and the target server, so as to prove that the first party has generated the invoice information, or so as to transmit the invoice information to the second party. In practical applications, the enterprise management software may obtain information such as invoice Application details and accurate invoicing amount of the second party from the target server in an Application Programming Interface (API) manner, and return an invoicing result (e.g., invoice code information, electronic invoice image, paper invoice image) to the target server in an API manner after invoicing. Based on this, step 206 may determine whether the first party submitted invoice information corresponding to the target transaction within a first time period after the initiation time.

In this embodiment, in addition to determining whether the first party has generated the invoice information corresponding to the target transaction, it may also be necessary to determine whether the first party actually delivers the invoice information to the second party in step 206.

Based on this, step 206: determining whether the first party provided the invoice information to the second party within a first time period after the initiation time, may further include:

determining whether the first party submitted proof of delivery information for the paper invoice within a first length of time after the initiation time.

In the embodiment of the present specification, the invoice information corresponding to the target transaction may be an electronic invoice or a paper invoice. If the paper invoice is the paper invoice, the paper invoice can be transmitted to a second participant through a mailing mode, or other offline delivery modes can be agreed by both parties, and certainly, both parties can agree that the paper invoice and the like do not need to be delivered. Based on the method, the delivery order number, the mailing voucher or the delivery appointment information between the two parties can be used as delivery certification information to avoid cheating of the first party, so that the rights and interests of the second party are further guaranteed.

In practical applications, if the invoice information corresponding to the target transaction is an electronic invoice, the electronic invoice image may be sent to the target application of the second party based on the target server, or may also be sent to the second party based on an email, a short message, an instant messaging tool, or the like. Since the target server is utilized to perform the operation of delivering the invoice information, it is not necessary to provide delivery certification information for the invoice information. Of course, an email, an application screenshot, etc. of the delivered electronic invoice may also be used as the delivery certification information for the electronic invoice, and based on this, step 206 may further include determining whether the first party submits the delivery certification information for the electronic invoice within a first time period after the initiation time, so as to further guarantee the rights and interests of the second party.

In this embodiment of the present specification, if the target server obtains an invoicing event, an invoice information entry event, or a delivery certification information entry event of the first party in the specified event segment, it may be determined that the second party provides the invoice information in the specified event segment by the first party. Therefore, the invoice application process and the delayed invoicing claim payment process are decoupled through an event monitoring technology.

In this embodiment of the present description, if a first party delays providing an invoice, in order to reduce loss of a second party, part of resources of the first party may be transferred to the second party, so that it is beneficial to reduce a situation that the first party delays providing a method, and it is also beneficial to guarantee rights and interests of the second party.

Based on this, step 208: the processing of the first participant may specifically include:

and determining the amount of the resources to be transferred according to the transaction information of the target transaction.

Deducting the resources of the amount of resources to be transferred from the resource pool of the first participant.

And issuing the resource of the resource amount to be transferred to the account of the second party.

In this embodiment of the present description, a first party generally needs to transfer a certain amount of resources to a target server in advance to generate a resource pool of the first party, and the first party may also authorize a transfer authority of the target server for the resources in the resource pool in advance, so that after it is determined that the first party does not provide an invoice on schedule, the resources of the amount of resources to be transferred of the first party may be transferred to an account of a second party, which is convenient and fast.

In practical applications, the amount of the resource to be transferred may be a transaction amount of a target transaction in a preset ratio, for example, assuming that the transaction amount of the target transaction is 100 yuan, and the preset ratio is 10%, the amount of the resource to be transferred may be 10 yuan. Alternatively, the amount of the resource to be transferred may be a specified value corresponding to a value interval in which the transaction amount of the target transaction falls, for example, if the transaction amount of the target transaction falls within (0,100], the amount of the resource to be transferred may be 10 yuan, and if the transaction amount of the target transaction falls within (100,1000], the amount of the resource to be transferred may be 20 yuan.

In practical applications, when the resource of the amount of the resource to be transferred is released to the account of the second party, the fund of the amount of the resource to be transferred may be released to the payment account of the second party at the payment application. Alternatively, the credit for the amount of the resource to be transferred may be issued to the registered account of the second party at the transaction application in the form of credit, so that the second party may purchase goods or enjoy other benefits based on the credit in the registered account at the transaction application, which is not particularly limited.

In this embodiment, before the processing operation of the first party in step 208 is performed, interception verification is also required to avoid penalizing errors and damaging the rights and interests of the first party.

Based on this, step 208: before processing the first participant, the method may further include:

judging whether the billing request message meets an interception condition or not to obtain a third judgment result; the interception condition includes: and at least one of a participant identity condition, a non-invoicing condition and a deduplication condition.

Correspondingly, the processing of the first participant may specifically include: and if the third judgment result shows that the billing request message does not meet the interception condition, processing the first participant.

Meanwhile, if the third judgment result shows that the billing request message meets the interception condition, the first party may be prohibited from being processed, and the process may be skipped to the end.

In this embodiment of the present specification, there may be a plurality of occasions for performing interception verification on the billing request message, that is, there may be a plurality of occasions for determining whether the billing request message satisfies an interception condition. For example, the interception verification may be performed after the billing request message is acquired in step 202, and step 204 and subsequent operations are performed after it is determined that the billing request message does not satisfy the interception condition, so as to reduce processing of unnecessary billing request messages and save device resources. And, the interception verification can be performed after determining that the first party does not provide the invoice to the second party within the specified time period in step 206, and the invoice issuing request message is processed for the first party after determining that the invoice issuing request message does not satisfy the interception condition, so as to avoid performing a wrong penalty operation to guarantee the rights and interests of the first party.

In this embodiment of the present specification, the interception conditions involved in performing interception verification may include: and at least one of a participant identity condition, a non-invoicing condition and a deduplication condition.

Wherein a deduplication condition may refer to the existence of multiple identical invoicing request messages for a target transaction. In practical applications, due to system jitter and other factors, multiple identical invoicing request messages may be repeatedly initiated for a target transaction, and in order to guarantee normal operation of a service, only one of the invoicing request messages (for example, the invoicing request message with the earliest reception time) needs to be responded, and no other invoicing request message needs to be responded.

The participant identity condition may mean that the first participant is located in the interception merchant list. In practical application, the target server may only need to process the behavior of delaying invoice provision for some merchants, and based on this, the identification information of other merchants may be added to the intercepted merchant list, so that the merchants are not processed no matter whether the merchants provide invoices within a preset time limit in the intercepted merchant list or not. Specifically, the merchants in the intercepted merchant list may include merchants who do not participate in the invoicing supervision activity, or include merchants who have special conditions and suspend participating in the invoicing supervision activity, for example, merchants who do not currently have invokable quota, or merchants who cannot provide invoices due to ineligibility, and the like.

The conditions for forbidding invoicing can be various, and the conditions for forbidding invoicing required to be used for carrying out interception verification at different times can also be different. For example, if the interception verification is performed after the invoicing request message is acquired in step 202, the condition for prohibiting invoicing may include: the completion time of the target transaction is earlier than the initiation time of the invoicing supervision activity, the target transaction is in an incomplete state, the first party is processed based on the target transaction, the invoiceable amount is 0, effective blue tickets are issued, and the like.

If it is determined in step 206 that the first party does not provide the second party with the invoice within the specified time period, the condition for prohibiting invoicing may include, in addition to the above conditions: and acquiring a full refund instruction of the first party for the target transaction within a first time period after the initiation time of the invoice request message, and acquiring a cancellation billing request message of the second party for the target transaction within a first time period after the initiation time of the invoice request message. And therefore, under the condition that the target transaction is refunded in full or the second party does not require invoicing, the first party is prohibited from being processed so as to guarantee the rights and interests of the first party.

In practical applications, when the target server obtains the full refund instruction and the invoice cancellation request message for the target transaction, it may also be determined that processing for the first party is prohibited, and a transition is made to end without executing step 206 and step 208, which is beneficial to saving device resources. Specifically, if the target server acquires a full-amount refund event for the target transaction, it may be determined that the full-amount refund instruction for the target transaction is acquired. And if the target server acquires the invoicing canceling event for the target transaction, determining to acquire the invoicing canceling request message for the target transaction. Therefore, the invoice application process and the invoice request processing process are decoupled through an event monitoring technology.

In this embodiment, when the target server executes the invoice request processing method in fig. 2 and the embodiment thereof, a workflow engine may be specifically used to implement, for example, an open source workflow framework OSWorkflow with better flexibility and higher operation efficiency. The target server can trigger the execution of the invoice request processing method by monitoring transaction related events, buyer and merchant application operation events and invoicing events. And the target server can also intercept when a new invoice request processing flow is triggered and started by an event, and/or intercept when the event triggers the intermediate state circulation, so that the processing of unnecessary invoice drawing request messages is reduced based on preset interception conditions, equipment resources can be saved, and the execution of wrong punishment operation can be avoided, so that the rights and interests of a first participant are guaranteed.

FIG. 3 is a swim lane flow diagram corresponding to the invoice request processing method in FIG. 2, provided in an embodiment of the present disclosure. As shown in FIG. 3, the invoice request processing flow may involve a first party, a second party, a target server, etc. executing a principal.

In a stage of applying for invoicing, a second party can execute a trigger operation for a first invoicing control at a target application, the first invoicing control is a control displayed after a target transaction is in a finished state, and based on the trigger operation, a target server can obtain a first invoicing request message for the target transaction. Or, the second participant may also perform a trigger operation for a second invoicing control at the target application, where the second invoicing control is a control displayed before the target transaction is in a completed state, and based on the trigger operation, after obtaining a state change operation in which the target transaction is changed to the completed state, the subsequent target server may determine that the second invoicing request message for the target transaction is obtained.

In the invoice request processing stage, the target server may first determine whether the first/second invoicing request message satisfies the interception condition, if so, the process may jump to the end, and if not, the initiation time of the first/second invoicing request message may be determined, for example, the occurrence time of the trigger operation executed for the first invoicing control may be used as the initiation time of the invoicing request message, or the occurrence time of the state change operation in which the target transaction is more likely to be completed may be used as the initiation time of the invoicing request message.

Subsequently, if the target server obtains an invoicing rejection instruction for the target transaction sent by the first party, the invoicing change prompt message can be sent to the second party in response to the invoicing rejection instruction. The second party may then perform an invoice information change operation at the target application based on the invoice change cue information. Of course, the second party may also actively perform the invoice information change operation when the invoice change prompting information is not acquired. However, in both cases, the destination server may update the time of initiation of the invoice request message to the time of occurrence of the invoice information change operation.

The target server can also judge whether the first party provides invoice information corresponding to the target transaction to the second party within a first time after the updated initiation time of the invoicing request message based on the updated initiation time of the invoicing request message, if so, the target server can skip to the end, and if not, the target server can judge whether the invoicing request message meets the interception condition again. If the billing request message is determined to meet the interception condition, skipping to the end, and if the billing request message is determined not to meet the interception condition, determining the amount of the resources to be transferred according to the transaction information of the target transaction; deducting resources of the amount of the resources to be transferred from the resource pool of the first participant; and issuing the resource of the resource amount to be transferred to the account of the second party.

In practical applications, if a full refund instruction for the target transaction by the first party is acquired within a first time period after the initiation time of the target server invoicing request message, or if the invoicing request message for the target transaction by the second party is canceled, the process may directly jump to the end (not shown in fig. 3), so as to save device resources.

Based on the same idea, the embodiment of the present specification further provides a device corresponding to the above method. Fig. 4 is a schematic structural diagram of an invoice request processing apparatus corresponding to fig. 2 provided in an embodiment of the present specification. As shown in fig. 4, the apparatus may include:

a first obtaining module 402, configured to obtain an invoicing request message for a target transaction; the invoicing request message is used for requesting a first party of the target transaction to provide invoice information corresponding to the target transaction to a second party.

A determining module 404, configured to determine an initiation time of the billing request message.

A first determining module 406, configured to determine whether the first party provides the invoice information to the second party within a first time period after the initiation time, so as to obtain a first determination result.

A processing module 408, configured to process the first party if the first determination result indicates that the first party does not provide the invoice information to the second party within a first time period after the initiation time.

The examples of this specification also provide some specific embodiments of the apparatus based on the apparatus of fig. 4, which is described below.

Optionally, the first obtaining module 402 may be specifically configured to:

acquiring a first invoicing request message aiming at a target transaction; the first ticketing request message is generated based on a triggering operation of the second participant for a first ticketing control at a target application, the first ticketing control being a control that is presented after the target transaction is in a completed state.

Correspondingly, the determining module 404 may be specifically configured to: determining the occurrence time of the triggering operation.

Optionally, the first obtaining module 402 may be specifically configured to:

acquiring a second invoicing request message aiming at the target transaction; the second invoicing request message is generated based on a state change operation of the target transaction to a completed state, the target transaction is a transaction in which the second participant executes a trigger operation on a second invoicing control at a target application, and the second invoicing control is a control displayed before the target transaction is in the completed state;

correspondingly, the determining module 404 may be specifically configured to: determining an occurrence time of the state change operation.

Optionally, the target application may include: a payment application used by the second party to make payment for the target transaction or a transaction application used by the second party to execute the target transaction.

Optionally, the apparatus in fig. 4 may further include:

the second acquisition module is used for acquiring the invoice change request message of the second party for the target transaction; the invoice alteration request message is generated based on an invoice information alteration operation performed by the second party at the target application, the invoice information alteration operation requesting alteration of the invoice information.

Correspondingly, the determining module 404 may be specifically configured to: and determining the occurrence time of the invoice information change operation.

Optionally, the apparatus in fig. 4 may further include:

and the third acquisition module is used for acquiring the order of refusing to invoice for the target transaction by the first participant.

The sending module is used for responding to the order of refusing to make an invoice and sending the prompting information of making an invoice to the equipment of the second party; and the invoice change prompt message is used for prompting the second party to change the invoice message.

Optionally, the apparatus in fig. 4 may further include:

and the second judgment module is used for judging whether the invoice change request message is acquired within a second time length after the invoice drawing refusing instruction is generated, so as to obtain a second judgment result.

And the prohibition processing module is configured to prohibit processing on the first party if the second determination result indicates that the invoice change request message is not acquired within a second time period after the invoice drawing rejection instruction is generated.

Optionally, the invoice information changing operation may include: a partial refund operation for the target transaction, and a modification operation for variable information in the invoice information.

Optionally, the first determining module 406 may include:

and the first judgment unit is used for judging whether the invoice information corresponding to the target transaction is generated according to the invoice issuing instruction of the first party within a first time length after the initiation time.

And the second judging unit is used for judging whether the first party submits invoice information corresponding to the target transaction within a first time length after the initiation time.

If the invoice information comprises a paper invoice; optionally, the first determining module 406 may further include:

and the third judging unit is used for judging whether the first participant submits delivery certification information aiming at the paper invoice within a first time length after the initiation time.

Optionally, the processing module 408 may include:

and the determining unit is used for determining the amount of the resources to be transferred according to the transaction information of the target transaction.

And the deduction unit is used for deducting the resource of the resource amount to be transferred from the resource pool of the first participant.

And the issuing unit is used for issuing the resource of the resource amount to be transferred to the account of the second party.

Optionally, the apparatus in fig. 4 may further include:

the third judgment module is used for judging whether the billing request message meets the interception condition or not to obtain a third judgment result; the interception condition includes: and at least one of a participant identity condition, a non-invoicing condition and a deduplication condition.

The processing module 408 may be further configured to process the first party if the third determination result indicates that the billing request message does not satisfy the interception condition.

Optionally, the billing prohibition condition may include: and acquiring a full refund instruction of the first party for the target transaction within a first time length after the initiation time, or acquiring a cancellation billing request message of the second party for the target transaction within the first time length after the initiation time.

Based on the same idea, the embodiment of the present specification further provides a device corresponding to the method.

Fig. 5 is a schematic structural diagram of an invoice request processing apparatus corresponding to fig. 2 provided in an embodiment of the present specification. As shown in fig. 5, the apparatus 500 may include:

at least one processor 510; and the number of the first and second groups,

a memory 530 communicatively coupled to the at least one processor; wherein,

the memory 530 stores instructions 520 executable by the at least one processor 510 to enable the at least one processor 510 to:

determining the initiation time of the billing request message;

The embodiments in the present specification are described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. In particular, for the apparatus shown in fig. 5, since it is substantially similar to the method embodiment, the description is simple, and for the relevant points, reference may be made to part of the description of the method embodiment.

In the 90 s of the 20 th century, improvements in a technology could clearly distinguish between improvements in hardware (e.g., improvements in circuit structures such as diodes, transistors, switches, etc.) and improvements in software (improvements in process flow). However, as technology advances, many of today's process flow improvements have been seen as direct improvements in hardware circuit architecture. Designers almost always obtain the corresponding hardware circuit structure by programming an improved method flow into the hardware circuit. Thus, it cannot be said that an improvement in the process flow cannot be realized by hardware physical modules. For example, a Programmable Logic Device (PLD), such as a Field Programmable Gate Array (FPGA), is an integrated circuit whose Logic functions are determined by programming the Device by a user. A digital character system is "integrated" on a PLD by the designer's own programming without requiring the chip manufacturer to design and fabricate a dedicated integrated circuit chip. Furthermore, nowadays, instead of manually making an Integrated Circuit chip, such Programming is often implemented by "logic compiler" software, which is similar to a software compiler used in program development and writing, but the original code before compiling is also written by a specific Programming Language, which is called Hardware Description Language (HDL), and HDL is not only one but many, such as abel (advanced Boolean Expression Language), ahdl (alternate Hardware Description Language), traffic, pl (core universal Programming Language), HDCal (jhdware Description Language), lang, Lola, HDL, laspam, hardward Description Language (vhr Description Language), vhal (Hardware Description Language), and vhigh-Language, which are currently used in most common. It will also be apparent to those skilled in the art that hardware circuitry for implementing the logical method flows can be readily obtained by a mere need to program the method flows with some of the hardware description languages described above and into an integrated circuit.

The controller may be implemented in any suitable manner, for example, the controller may take the form of, for example, a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro) processor, logic gates, switches, an Application Specific Integrated Circuit (ASIC), a programmable logic controller, and an embedded microcontroller, examples of which include, but are not limited to, the following microcontrollers: the ARC625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic for the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in purely computer readable program code means, the same functionality can be implemented by logically programming method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers and the like. Such a controller may thus be considered a hardware component, and the means included therein for performing the various functions may also be considered as a structure within the hardware component. Or even means for performing the functions may be conceived to be both a software module implementing the method and a structure within a hardware component.

The systems, devices, modules or units illustrated in the above embodiments may be implemented by a computer chip or an entity, or by a product with certain functions. One typical implementation device is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a cellular telephone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

For convenience of description, the above devices are described as being divided into various units by function, and are described separately. Of course, the functionality of the units may be implemented in one or more software and/or hardware when implementing the present application.

As will be appreciated by one skilled in the art, embodiments of the present invention may be provided as a method, system, or computer program product. Accordingly, the present invention may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present invention may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present invention has been described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

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

The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.

Computer-readable media, including both permanent and non-permanent, removable and non-removable media, may implement the information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transmission medium, which can be used to store information that can be accessed by a computing device. As defined herein, a computer readable medium does not include a transitory computer readable medium such as a modulated data signal and a carrier wave.

It should also be noted that the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in the process, method, article, or apparatus that comprises the element.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The application may be described in the general context of computer-executable instructions, such as program modules, being executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. The application may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.

The above description is only an example of the present application and is not intended to limit the present application. Various modifications and changes may occur to those skilled in the art. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. An invoice request processing method, comprising:

determining the initiation time of the billing request message;

2. The method according to claim 1, wherein the obtaining of the invoice request message for the target transaction specifically includes:

acquiring a first invoicing request message aiming at a target transaction; the first invoicing request message is generated based on a triggering operation of the second participant for a first invoicing control at a target application, the first invoicing control being a control that is presented after the target transaction is in a completed state;

determining the occurrence time of the triggering operation.

3. The method according to claim 1, wherein the obtaining of the invoice request message for the target transaction specifically includes:

determining an occurrence time of the state change operation.

4. The method of claim 2 or 3, after obtaining the invoicing request message for the target transaction, further comprising:

acquiring an invoice change request message of the second party for the target transaction; the invoice change request message is generated based on an invoice information change operation performed by the second party at the target application, the invoice information change operation requesting a change to the invoice information;

5. The method of claim 4, prior to said obtaining an invoice change request message for said second party to said target transaction, further comprising:

obtaining a bill refusing instruction of the first participant for the target transaction;

responding to the order of refusing to make an invoice, and sending invoice change prompt information to the equipment of the second party; and the invoice change prompt message is used for prompting the second party to change the invoice message.

6. The method of claim 5, after sending the invoice change prompting message to the second party's device, further comprising:

judging whether the invoice change request message is acquired within a second time length after the invoice drawing rejection instruction is generated, and acquiring a second judgment result;

and if the second judgment result indicates that the invoice change request message is not acquired within a second time length after the invoice drawing rejection instruction is generated, the first party is prohibited from being processed.

7. The method of claim 4, the invoice information alteration operation comprising: a partial refund operation for the target transaction, and a modification operation for variable information in the invoice information.

8. The method according to claim 1, wherein the determining whether the first party provides the invoice information to the second party within a first time period after the initiation time comprises:

judging whether invoice information corresponding to the target transaction is generated according to an invoice issuing instruction of the first participant within a first time length after the initiation time; or,

9. The method of claim 8, wherein the invoice information comprises a paper invoice;

the determining whether the first party provided the invoice information to the second party within a first time period after the initiation time, further comprising:

10. The method according to claim 1, wherein the processing the first participant specifically comprises:

determining the amount of resources to be transferred according to the transaction information of the target transaction;

deducting the resource of the amount of the resource to be transferred from the resource pool of the first participant;

11. The method of claim 10, prior to processing the first participant, further comprising:

judging whether the billing request message meets an interception condition or not to obtain a third judgment result; the interception condition includes: at least one of a participant identity condition, a non-invoicing condition and a deduplication condition;

the processing the first party specifically includes:

and if the third judgment result shows that the billing request message does not meet the interception condition, processing the first party.

12. The method of claim 11, the conditions for prohibiting invoicing comprising: and acquiring a full refund instruction of the first party for the target transaction within a first time length after the initiation time, or acquiring a cancellation billing request message of the second party for the target transaction within the first time length after the initiation time.

13. The method of claim 2 or 3, the target application comprising: a payment application used by the second party to make payment for the target transaction or a transaction application used by the second party to execute the target transaction.

14. An invoice request processing apparatus comprising:

a first determining module, configured to determine whether the first party provides the invoice information to the second party within a first time after the initiation time, to obtain a first determination result;

15. The apparatus of claim 14, wherein the first obtaining module is specifically configured to:

the determining module is specifically configured to:

and determining the occurrence time of the trigger operation.

16. The apparatus of claim 14, wherein the first obtaining module is specifically configured to:

acquiring a second invoicing request message aiming at the target transaction; the second invoicing request message is generated based on a state change operation of the target transaction to a completed state, the target transaction is a transaction of which the second participant executes a trigger operation on a second invoicing control at the target application, and the second invoicing control is a control displayed before the target transaction is in the completed state;

the determining module is specifically configured to:

determining an occurrence time of the state change operation.

17. The apparatus of claim 15 or 16, further comprising:

the second acquisition module is used for acquiring the invoice change request message of the second party for the target transaction; the invoice alteration request message is generated based on an invoice information alteration operation performed by the second party at the target application, the invoice information alteration operation requesting alteration of the invoice information;

the determining module is specifically configured to:

18. The apparatus of claim 17, further comprising:

the third acquisition module is used for acquiring an invoicing rejection instruction of the first participant for the target transaction;

the sending module is used for responding to the order of refusing to invoice and sending the invoice change prompt message to the equipment of the second party; and the invoice change prompt message is used for prompting the second party to change the invoice message.

19. The apparatus of claim 18, further comprising:

the second judgment module is used for judging whether the invoice change request message is acquired within a second time length after the invoice drawing rejection instruction is generated, and acquiring a second judgment result;

and the prohibition processing module is configured to prohibit processing on the first party if the second determination result indicates that the invoice change request message is not obtained within a second duration after the generation of the invoice charge rejection instruction.

20. The apparatus of claim 14, the first determining module comprising:

the first judgment unit is used for judging whether invoice information corresponding to the target transaction is generated according to an invoice issuing instruction of the first party within a first time length after the initiation time;

21. The apparatus of claim 20, said invoice information comprising a paper invoice; the first determining module further includes:

and the third judging unit is used for judging whether the first party submits delivery certification information aiming at the paper invoice within a first time length after the initiation time.

22. The apparatus of claim 14, the processing module comprising:

the determining unit is used for determining the amount of the resources to be transferred according to the transaction information of the target transaction;

a deduction unit, configured to deduct resources of the amount of resources to be transferred from a resource pool of the first participant;

23. The apparatus of claim 22, further comprising:

the third judgment module is used for judging whether the billing request message meets the interception condition or not to obtain a third judgment result; the interception condition includes: at least one of a participant identity condition, a non-invoicing condition and a deduplication condition;

the processing module is further configured to:

24. The apparatus of claim 15 or 16, the target application comprising: a payment application used by the second party to make payment for the target transaction or a transaction application used by the second party to execute the target transaction.

25. An invoice request processing apparatus comprising:

at least one processor; and the number of the first and second groups,

a memory communicatively coupled to the at least one processor; wherein,

determining the initiation time of the billing request message;