CN110264232B

CN110264232B - Data processing method and device for delayed verification of ticket

Info

Publication number: CN110264232B
Application number: CN201910362231.XA
Authority: CN
Inventors: 卓韦攸; 周健; 赵大成
Original assignee: Advanced New Technologies Co Ltd
Current assignee: Advanced New Technologies Co Ltd; Advantageous New Technologies Co Ltd
Priority date: 2019-04-30
Filing date: 2019-04-30
Publication date: 2023-10-27
Anticipated expiration: 2039-04-30
Also published as: CN110264232A

Abstract

The specification provides a data processing method and device for delayed verification of a ticket, which are used for realizing delayed recovery of the ticket by setting the recovery time of the ticket to be the preset recovery time and overlapping the delay time of the ticket, and do not need to redefine the life cycle of the ticket and do not influence the definition of the validity period of the ticket: the effective time and the dead time do not introduce the life cycle definition of the new ticket. The coupon delay verification is supported, the outside is not perceived, only the coupon platform is needed to perceive and adapt to the support, all access scenes are not influenced, and the delay verification capability can be opened for all coupons. And according to the actual transaction time, the inquiry and verification of the ticket are carried out, so that the delayed verification of the ticket is realized in an externally transparent mode, and the verification accuracy of the ticket is ensured.

Description

Data processing method and device for delayed verification of ticket

Technical Field

The specification belongs to the technical field of computers, and particularly relates to a data processing method and device for delayed verification of coupons.

Background

In business marketing, coupons are a relatively common marketing tool, and coupons may represent notes that are used in a business environment, representing certain interests, such as: cash vouchers, full vouchers, discount vouchers, and the like. The validation of the ticket may indicate that the ticket is in use, and the delayed validation of the ticket may indicate that payment validation is not immediately requested when payment actually occurs, and that a period of time has elapsed before payment validation is requested. For example: in the asynchronous transaction scene such as bus subway payment, a user takes bus and subway companies to send a receipt payment request to a third party payment platform after taking bus, and the situation of delayed up-sending exists because the machine tool support of the mechanism end code brushing is offline. Delayed up-feed may result in the ticket being revoked, not fulfilling the promise to the user, affecting the user experience. How to realize the delayed verification of the ticket and ensure the accuracy of the verification of the ticket is a technical problem which needs to be solved in the field.

Disclosure of Invention

The embodiment of the specification aims to provide a data processing method and device for delayed verification of a ticket, which realize accurate verification of the ticket.

In one aspect, an embodiment of the present disclosure provides a data processing method for delayed verification of a ticket, including:

receiving a transaction request, and acquiring actual transaction time according to the transaction request;

inquiring a target ticket conforming to a use rule in a user account according to the actual transaction time, wherein the recovery time of the target ticket is set as a ticket preset recovery time plus a delay time;

and verifying the target ticket.

In another aspect, the present specification provides a data processing apparatus for delayed verification of coupons, comprising:

the actual transaction time acquisition module is used for receiving a transaction request and acquiring actual transaction time according to the transaction request;

the ticket inquiry module is used for inquiring a target ticket conforming to the use rule in the user account according to the actual transaction time, wherein the recovery time of the target ticket is set to be ticket preset recovery time plus delay time;

and the ticket verifying and verifying module is used for verifying and verifying the target ticket.

In yet another aspect, the present specification provides a data processing system for delayed validation of coupons, comprising:

The template creation module is used for creating a coupon template, and the recovery time of the template is set to be the preset recovery time plus the delay time of the template;

the ticket issuing module is used for generating a ticket according to the template, setting the recovery time of the ticket as the preset recovery time of the ticket plus the delay time, and issuing the generated ticket;

the ticket consulting module is used for acquiring actual transaction time according to the transaction request, inquiring the ticket in the effective period according to the actual transaction time, and checking the use frequency limit of the inquired ticket according to the actual transaction time to acquire a target ticket meeting preset conditions;

the ticket verifying and verifying module is used for obtaining the actual transaction time according to the transaction request, verifying whether the target ticket inquired by the ticket verifying and inquiring module is in the effective period according to the actual transaction time, verifying the limit of the using times of the target ticket according to the actual transaction time, verifying and verifying the target ticket passing verification, and updating and recording the using times of the target ticket.

In still another aspect, the present specification provides a data processing apparatus for ticket delayed cancellation, comprising: at least one processor and a memory for storing processor-executable instructions that when executed implement the data processing method for ticket delay verification described above.

The data processing method, the device, the system and the processing equipment for delayed verification of the ticket provided by the specification realize delayed recovery of the ticket by setting the recovery time of the ticket to be the preset recovery time superposition delay time of the ticket, do not need redefining the life cycle of the ticket and do not influence the validity period definition of the ticket: the effective time and the dead time do not introduce the life cycle definition of the new ticket. The coupon delay verification is supported, the outside is not perceived, only the coupon platform is needed to perceive and adapt to the support, all access scenes are not influenced, and the delay verification capability can be opened for all coupons. And according to the actual transaction time, the inquiry and verification of the ticket are carried out, so that the delayed verification of the ticket is realized in an externally transparent mode, and the verification accuracy of the ticket is ensured.

Drawings

In order to more clearly illustrate the embodiments of the present description or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some of the embodiments described in the present description, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.

FIG. 1 is a flow diagram of a method of data processing for coupon delay verification according to one embodiment of the present disclosure;

FIG. 2 is a schematic flow diagram of template creation in one embodiment of the present description;

FIG. 3 is a schematic flow chart of ticket issuing in one embodiment of the present specification;

FIG. 4 is a schematic flow chart of coupon consulting in one embodiment of the present specification;

FIG. 5 is a schematic flow chart of ticket validation in one embodiment of the present disclosure;

FIG. 6 is a block diagram of one embodiment of a data processing apparatus for delayed ticket cancellation provided in the present specification;

FIG. 7 is a block diagram of the hardware architecture of a data processing server for ticket delay verification in one embodiment of the present description.

Detailed Description

In order to make the technical solutions in the present specification better understood by those skilled in the art, the technical solutions in the embodiments of the present specification will be clearly and completely described below with reference to the drawings in the embodiments of the present specification, and it is obvious that the described embodiments are only some embodiments of the present specification, not all embodiments. All other embodiments, which can be made by one of ordinary skill in the art without undue burden from the present disclosure, are intended to be within the scope of the present disclosure.

Coupons are often used in marketing scenarios where the lifecycle of each coupon typically corresponds to an validation time and a expiration time, after which the coupon is recovered to release funds occupied by the coupon, and thus the expiration time may also be understood as a recovery time. The coupons described in the embodiments of the present specification are generally referred to as electronic coupons, rather than paper coupons. If the user performs a transaction before the expiration time, but only requests the ticket verification after the expiration time, the ticket is recovered, so that the ticket cannot be verified, the ticket verification is wrong, the user does not enjoy the corresponding benefit, and the user experience is affected.

The embodiment of the specification provides a data processing method for delayed verification of a ticket, which sets the recovery time of the ticket to be the preset recovery time superposition delay time of the ticket, realizes delayed recovery of the ticket, inquires and verifies the ticket according to the actual transaction time, realizes the delayed verification of the ticket in an externally transparent mode, ensures the accuracy of verification of the ticket, practically fulfills the ticket use promise for a user, and improves the user experience.

The data processing method for the ticket delay verification in the specification can be applied to a client or a server, and the client can be electronic equipment such as a smart phone, a tablet personal computer, intelligent wearable equipment (a smart watch, virtual reality glasses, virtual reality helmets and the like), intelligent vehicle-mounted equipment and the like.

Specifically, fig. 1 is a schematic flow chart of a data processing method for ticket delay verification in an embodiment of the present disclosure, and as shown in fig. 1, the data processing method for ticket delay verification provided in an embodiment of the present disclosure may include:

step 102, receiving a transaction request, and acquiring actual transaction time according to the transaction request.

The data processing method for the ticket delay verification in the embodiment of the specification can be applied to a payment platform, a merchant can be connected into the payment platform, after the merchant conducts transaction with a user, the merchant uploads a transaction request, and the payment platform conducts transaction deduction or transfer processing and the like according to the transaction request. In the implementation process, after a user carries out a transaction on a merchant platform (such as a bus, a subway and the like), the merchant platform can send a transaction request, namely an order-receiving payment request, to a payment platform to request the payment platform to carry out transaction deduction. The transaction request may include: actual transaction time, transaction commodity, user account name of both transaction parties, transaction bill number, transaction amount, etc. In the embodiment of the present disclosure, the actual transaction time corresponding to the transaction request is acquired according to the transaction request, and the actual transaction time may not be consistent with the time when the transaction request is received. Such as: some business scenario merchant platforms can send transaction requests to the payment platform in real time, and the actual transaction time and the time for receiving the transaction requests can be the same; while some business scenarios are as follows: in asynchronous transaction scenes such as buses and subways, the situation that a transaction request is sent in a delayed mode may occur, and the actual transaction time is different from the time of receiving the transaction request.

For example: and a certain user takes the bus in a payment mode of a third party in 1 st and 2 nd of 2019, and the bus company platform transmits a transaction request to the payment platform of the third party in 1 st and 3 rd of 2019 to request to pay for the receipt. And after the third party payment platform receives the transaction request reported by the public transport company platform, acquiring the actual transaction time according to the transaction request.

It should be noted that, the actual transaction time may represent a time period, such as: the day of the actual transaction. Such as: the actual transaction time of the user obtained according to the transaction request is 10 am of 1 month 2 days in 2019, and the actual transaction time can be understood as 1 month 2 days in 2019. The actual transaction time may also represent a time point, and the actual transaction time may be specifically set according to actual needs, which is not specifically limited in the embodiments of the present disclosure.

In some embodiments of the present disclosure, the obtaining the actual transaction time according to the transaction request includes:

acquiring a sales product code and/or a contracted merchant number according to the transaction request;

and if the sales product code or the contracted merchant number is in the delay verification list, acquiring the actual transaction time from the transaction request.

In a specific implementation process, the actual transaction time is generally uploaded by a merchant platform accessed by a payment platform, and the actual transaction time uploaded by the merchant has a certain possibility of black ash production, i.e. the actual transaction time uploaded by the merchant may be inaccurate. In some embodiments of the present disclosure, a delayed cancellation list may be established according to a merchant credit, where the delayed cancellation list may include a merchant allowing delayed cancellation or a product of the merchant, and the delayed cancellation list may specifically include a sales product code, a contracted merchant number, a merchant user name, and the like. The sales product code may represent a character string or two-dimensional code or bar code for uniquely marking the sales product, and the contracted merchant number may represent a merchant number of a merchant contracted or resident on the transaction platform, which may be used to uniquely mark the character string or other information of the merchant. Delay verification may be allowed in the delay verification list, and not in the list, delay verification may not be allowed or the actual transaction time of the upload may need to be further verified. According to the embodiment in the specification, the sales product code and/or the contracted merchant number corresponding to the current transaction can be obtained according to the transaction request, the obtained sales product code or contracted merchant number is matched with the sales product code and contracted merchant number of the delayed cancel list, if the obtained sales product code or contracted merchant number is in the delayed cancel list, the reliability of the current transaction merchant is higher, the uploading actual transaction time is accurate, and the delayed cancel of the ticket is allowed. The actual transaction time may be obtained from the transaction request. The sales product code and the sign-up merchant number are not changed generally, corresponding transaction data can be obtained based on the sales product code and/or the sign-up merchant number, the actual transaction time is obtained from the transaction data, management and control of the actual transaction time are enhanced, the accuracy of obtaining the actual transaction time is improved, and a data base is provided for accurate verification and verification of follow-up coupons.

And 104, inquiring a target ticket meeting the use rule in the user account according to the actual transaction time, wherein the recovery time of the target ticket is set as the preset recovery time of the ticket plus the delay time.

In a specific implementation process, the recovery time of the ticket in the embodiment of the present disclosure is preset to be the preset recovery time of the ticket plus the delay time, where the preset recovery time of the ticket may represent the normal recovery time of the ticket, such as: the failure time and the delay time can represent the time of delayed recovery or delayed verification, and can be specifically set according to service requirements, for example: set to 3 days or 7 days or 10 days, etc. For example: the validation time of a coupon is 2019, 1 and the expiration time is 2019, 1, 7, wherein the expiration time is understood as the reclamation time. Normally, the coupon would be recycled if not used on day 1 and 7 of 2019. In the embodiment of the present disclosure, the preset coupon recycling time is set to be the preset coupon recycling time plus the delay time, the preset coupon recycling time is set to be 2019, 1 month and 7 days, if the set delay time is set to be 7 days, the coupon recycling time is set to be 2019, 1 month and 14 days, and if the coupon is not used all the time, the coupon is invalidated in 2019, 1 month and 7 days, but is not recycled immediately, and is recycled again in 2019, 1 month and 14 days. If the user conducts a transaction conforming to the ticket usage rules before 1 month 7 of 2019, but does not immediately cancel the ticket usage rules, the ticket usage rules can be cancelled before 14 of 2019. The present embodiments do not require redefining the lifecycle of the ticket as: redefining and understanding the failure time of the ticket, directly setting the recovery time of the ticket as the preset recovery time of the ticket and overlapping the delay time, realizing the delay verification of the ticket, having simple data processing and improving the data processing efficiency of ticket generation and verification.

Each ticket corresponds to a usage rule, i.e. what transaction conditions are met to use the ticket. According to the embodiment of the specification, according to the obtained actual transaction time, the target ticket conforming to the use rule in the user account is inquired, the user account can be understood as a transaction user in the transaction request, and whether the ticket conforming to the use rule exists in the user account at the actual transaction time can be inquired. Compliance with the usage rules may include: when the actual transaction time is within the validity period, or the current transaction request meets the requirement of the transaction scene, or whether the current transaction amount reaches the use rule of the ticket, or the use times of the actual transaction time meets the conditions, etc., the use rule of the ticket can be specifically set according to the actual requirement, and the embodiment of the specification is not limited specifically.

And 106, verifying and verifying the target ticket.

After the target ticket meeting the use rule in the user account is queried, the target ticket can be verified, namely, the target ticket is used for deducting the corresponding fee for the transaction of the transaction request.

In some embodiments of the present disclosure, after verifying the target ticket, the verification sum of the usage number limit may be updated according to the actual usage time. Such as: checking whether the usage number of the target ticket exceeds the allowable usage number limit in the actual transaction time, if the usage number limit is exceeded, the usage number limit check fails, and at this time, the ticket verification operation also fails. Similarly, the updated results of the number of ticket uses are synchronized with the results of ticket verification.

For example: and a certain user takes the bus in a payment mode of a third party in 1 st and 2 nd of 2019, and the bus company platform transmits a transaction request to the payment platform of the third party in 1 st and 3 rd of 2019 to request to pay for the receipt. After receiving the transaction request reported by the public transport company platform, the third party payment platform obtains the actual transaction time of 2019, 1 month and 2 days according to the transaction request, inquires the target ticket in the transaction user account, and then verifies the target ticket. After the ticket is approved, checking whether the using times of the ticket reaches the limit of the using times or not on the 1 st month 2 th year of 2019, if the ticket is allowed to be used once a day, checking that the user does not pass the ticket on the 1 st month 2 th year of 2019, and recording that the ticket is used 1 time on the 1 st month 2 th year of 2019 instead of recording that the ticket is used 1 time on the 1 st month 3 th year of 2019. If the usage rule of the ticket is that the ticket can only be used once a day within the validity period, if the usage times of 1 month and 2 days in 2019 are recorded as 1 time of 1 day and 3 days in 2019, the ticket can not be used again if the user takes the bus in 1 month and 3 days in 2019, so that ticket verification errors are caused, and user experience is reduced.

According to the embodiment of the specification, the limit of the number of times of use of the target ticket is checked based on the actual transaction time, the number of times of use of the target ticket is updated and recorded, and the current time, namely the time for receiving the transaction request, is not adopted, so that the number of times of use of the target ticket is updated, the accuracy of the number of times of use record of the ticket is improved, and the accuracy of ticket verification and verification is further improved.

In the embodiment of the present disclosure, 1, 2 or more target coupons may be queried, and when the target coupons are 2 or more target coupons, one target coupon may be selected for verification, a coupon closest to the expiration date may be selected for verification, or a coupon with the earliest validation time may be selected for verification, or a user may be notified to send a coupon verification, and the user may select which coupon to verify.

According to the data processing method for delayed verification and verification of the ticket, the delayed recovery of the ticket is realized by setting the recovery time of the ticket to be the preset recovery time of the ticket and overlapping the delay time, the life cycle of the ticket is not required to be redefined, and the complexity of data processing for ticket generation and verification is reduced. And according to the actual transaction time, the inquiry and verification of the ticket are carried out, so that the delayed verification of the ticket is realized in an externally transparent mode, and the verification accuracy of the ticket is ensured.

Based on the above embodiments, in some embodiments of the present disclosure, the querying, according to the actual transaction time, a target ticket in a user account according to a usage rule includes:

inquiring a valid ticket in the user account, wherein the valid ticket is in the valid period at the actual transaction time;

And according to the actual transaction time, checking the use frequency limit of the effective ticket corresponding to the actual transaction time, and taking the ticket meeting the use frequency limit as the target ticket.

In a specific implementation process, after a transaction request is received and an actual transaction time is obtained according to the transaction request, a valid ticket in the user account with the actual transaction time within a valid period can be queried according to the actual transaction time, for example: it is possible to query what of the actual transaction times is covered by the validity period of the ticket in the user account. The validity period indicates the effective time to the dead time of the ticket, and the embodiment of the specification performs the ticket inquiry in the validity period based on the actual transaction time instead of the current time, so that the accuracy of the ticket inquiry result can be improved. Such as: if the validity period of a coupon is from 1 st 2019 to 1 st 7 st 2019, the actual transaction time is from 1 st 2019 to 7 st 2019, and the current time is from 1 st 2019 to 8 th 2019, the coupon is in the validity period at the actual transaction time and can be used as a valid coupon, and if the valid coupon is queried at the current time, the coupon is considered as an invalid coupon, so that the coupon cannot be verified.

In some embodiments of the present disclosure, if the ticket is a ticket that allows delayed cancellation, the ticket is provided with a delayed cancellation flag;

Accordingly, the querying the user account for the valid ticket that is within the validity period at the actual transaction time may include:

and taking the ticket with the current time in the validity period and the delayed verification mark as the valid ticket.

In a specific implementation process, the method can inquire the valid ticket in the user account by marking the ticket with a delayed cancel mark and inquiring the ticket with the delayed cancel mark when the current time is in the validity period. If the ticket is determined to be allowed to be delayed and approved when the ticket is issued, the ticket can be marked with the delayed and approved ticket, and when the valid ticket is inquired, the ticket with the current time in the validity period and the ticket with the delayed and approved ticket can be obtained as the valid ticket. After the valid ticket is obtained, the ticket with the delayed cancel mark can be screened, and whether the ticket with the delayed cancel mark is in the delayed cancel time range or not can be determined according to the actual transaction time. For example: the expiration date of a ticket is from 2019, 1, to 2019, 1, 7, and if the ticket allows delayed cancellation, the ticket may be marked with delayed cancellation. When the valid ticket in the user account is queried, the ticket with the delay verification mark and the current time in the valid period can be queried, and the queried ticket is taken as the valid ticket. It is also possible to inquire whether the delay time of the ticket with the delay verification flag is within the actual transaction time range, if so, it is reserved, and if not, it is deleted.

By marking the delayed verification mark, the effective ticket can be quickly searched, and the ticket searching efficiency and accuracy are improved.

After the effective ticket corresponding to the actual transaction time is inquired, checking the limit of the using times of the effective ticket according to the actual transaction time, namely checking whether the using times of the effective ticket reach the limit of the using times or not when the effective ticket is in the actual transaction time, and taking the effective ticket as a target ticket if the using times of the effective ticket do not reach the limit of the using times. For example: the actual transaction time is 2019 1 month 2 days, and 2019 1 month 3 days initiate to a payment platform to request receipt payment, and inquire that a valid ticket in the effective time of the actual transaction time exists in a user account, wherein the using frequency of the valid ticket is limited to be used only once a day. It is checked whether the number of times of use of the effective ticket in 2019, 1, 2, reaches the limit of the number of times of use, that is, whether the ticket is used in 2019, 1, 2, or not, if it has been used, it is impossible to use the ticket as a target ticket, and if it has not been used, it is possible to use the ticket as a target ticket. The embodiment of the specification performs the verification of the ticket use times based on the actual transaction time, instead of the verification of the ticket use times based on the current time, such as: the above embodiment checks the number of times of using the ticket of 1 month and 2 days in 2019, instead of checking the number of times of using the ticket of 1 month and 3 days in 2019, so that the accuracy of checking the number of times of using the ticket can be improved.

According to the embodiment of the specification, when the ticket is inquired, the validity period and the using times of the ticket are checked based on the actual transaction time, but not the ticket validity period is inquired based on the current time, so that the accuracy of the ticket inquiry result is improved, and an accurate data basis is provided for the verification of the follow-up ticket.

On the basis of the above embodiments, in some embodiments of the present specification, the verifying the target ticket may include:

before verifying the target ticket, checking whether the target ticket is in an effective period or not in the actual transaction time according to the actual transaction time, and checking whether the target ticket reaches a limit of the using times in the actual transaction time or not;

and if the target ticket is in the effective period in the actual transaction time and the limit of the using times is not reached in the actual transaction time, verifying the target ticket.

In a specific implementation process, a certain time difference may exist between ticket verification and ticket inquiry, and in the embodiment of the present disclosure, when ticket verification is performed after a target ticket meeting a usage rule is inquired, the inquired target ticket may be checked for a second time, so as to ensure accuracy of ticket verification. When the ticket checking and the verifying are carried out, the actual transaction time can be acquired according to the received transaction request, and the validity period verification is carried out on the inquired target ticket according to the actual transaction time, namely, whether the target ticket is in the validity period or not is verified, if so, the use frequency limit of the target ticket is verified according to the actual transaction time, and whether the ticket reaches the use frequency limit or not is verified. The ticket verification and the ticket inquiry can have a certain time difference, the ticket use condition or the ticket state can change in the time, and the target ticket is checked for the second time before the ticket verification, so that the ticket verification accuracy is improved. And if the target ticket is confirmed to be in the validity period by the secondary verification and the using times do not reach the using times limit, verifying and verifying the target ticket.

For example: a certain user takes a bus in a mode of using a third party payment at 10 am in 1 month 2 a year 2019, and the bus company platform transmits a transaction request to a third party payment platform to request to pay a receipt at 11 am in 1 month 2 a year 2019. After receiving the transaction request reported by the public transport company platform, the third party payment platform obtains the actual transaction time of 2019, 1 month and 2 days according to the transaction request, and inquires a target ticket conforming to the use rule in the transaction user account after receiving the transaction request. After the target ticket is inquired, the ticket verification is not performed immediately, and the ticket verification is performed at 2 pm in 2019 1 month 2. Before verifying the ticket, the inquired target ticket is verified for the second time according to the actual transaction time, and in the second verification, the user is found to take the bus at 12 noon in 1 month 2 in 2019 and uses a third party payment mode, the transaction is already settled, the inquired target ticket is verified in the transaction at 12 noon in 1 month 2 in 2019, and the use times of the target ticket are limited to only one time in one day. And then, at 2 pm in 1 month and 2 days in 2019, performing secondary verification when verifying the ticket, and determining that the inquired target ticket reaches the use frequency limit and cannot be used, wherein the ticket verification fails.

According to the embodiment of the specification, when the ticket verification is carried out, the target ticket inquired by the ticket is subjected to secondary verification, so that the ticket verification accuracy is improved.

Based on the above embodiments, in some embodiments of the present specification, the ticket issuing may be performed by the following method before the ticket delay verification is performed:

creating a coupon template, wherein the recovery time of the coupon template is set as template preset recovery time plus the delay time;

and generating a ticket according to the ticket template, wherein the ticket recovery time is set to be the ticket preset recovery time plus the delay time, and issuing the generated ticket.

In a particular implementation, a ticket template may be created based on business activities, which may include the format of the ticket, the expiration date of the ticket, rules for use of the ticket, and the like. In this embodiment of the present disclosure, when a coupon template is created, the recovery time of the coupon template is set to be a preset recovery time of the template, and the preset recovery time of the template may be set according to a business activity, for example: setting the time of ending the business activity as the template recovery time, wherein the delay time can be set according to actual needs and is generally the same as the delay time of the ticket, such as: 3 days, 7 days, 10 days, etc. After the ticket template is established, the ticket can be generated according to the security template, the generated ticket is issued to the corresponding user account, and when the ticket is generated, the recovery time of the ticket is set to be the preset recovery time of the ticket, and the delay time is superposed. The form of issuing the ticket may be active, or may be issued by the user after participating in a certain activity or performing certain tasks to meet the standard of issuing the ticket, or may be issued in the form of applying for the ticket by the user, or may be issued according to actual needs, and the embodiment of the present disclosure is not limited specifically.

For example: a merchant or paymate expects to issue 100 coupons for a business campaign to promote. The business activity time is from 1 st of 2019 to 31 st of 2019, and then a ticket template can be created according to the needs of the business activity, wherein the preset recovery time of the template of the ticket template can be set to 31 st of 2019. In the embodiment of the present disclosure, the service party may further set a delay time, for example, 10 days, according to actual needs, and the recovery time of the coupon template is a preset recovery time of 2019, 1 month and 31 days, and the superimposed delay time is 10 days, that is, 2019, 2 months and 10 days. After creating the coupon templates from the business activity, coupons can be generated from the security templates, such as: the validation time of the ticket can be the generation time of the ticket, and the invalidation time of the ticket can be set according to actual needs, such as: the expiration time of the ticket is set according to the expiration date of the ticket. For example: when a user completes a designated task in 2019 1 month 3, applies for getting a ticket, a corresponding ticket can be generated according to a security template, and if the validity period of the ticket is preset to be 7 days, a ticket which is valid in 2019 1 month 3 and is invalid in 2019 1 month 10 can be generated according to the security template. In the embodiment of the present disclosure, the recovery time of the ticket may be further set to be a preset recovery time stacking delay time of the ticket, and then the recovery time of the ticket generated in the above example is a preset recovery time of the ticket, which is 2019, 1 month, 10 days, and 2019, 1 month, 20 days.

According to the embodiment of the specification, when the ticket template is created and the ticket is issued, the recovery time is set to be the preset recovery time and the delay time is overlapped, so that the recovery action of the template and the ticket can be performed after the longest delay time allowed by the service, and the delayed recovery of the template and the ticket is realized. After the ticket is invalid, the ticket can be verified and approved within a delay time, so that the ticket verification accuracy is ensured. And the life cycle of the ticket is not required to be redefined, and the validity period definition of the ticket is not influenced: the effective time, the failure time and the like do not introduce new coupon life cycle definitions which need external understanding, the applicability is relatively wide, and the data processing is simple.

Fig. 2 to 5 are data processing flows corresponding to different periods in the ticket life cycle in the embodiment of the present specification, fig. 2 is a schematic flow diagram of creation of a template in one embodiment of the present specification, fig. 3 is a schematic flow diagram of ticket issuance in one embodiment of the present specification, fig. 4 is a schematic flow diagram of ticket consultation in one embodiment of the present specification, fig. 5 is a schematic flow diagram of ticket verification in one embodiment of the present specification, and the following description will describe a specific procedure of the data processing method of ticket delay verification in the embodiment of the present specification from the viewpoint of the ticket life cycle in combination with fig. 2 to 4:

1. Creating a template: the security template recovery time is set to overlap with service delay time (namely delay time recorded in the embodiment), namely, the recovery time of the security template is set as template preset recovery time plus delay time, so that the template recovery action is ensured to occur after the longest delay time allowed by the service, and the delay recovery of the template is realized.

2. Ticket issuing: setting the ticket recycling time and overlapping service delay time, namely, the ticket recycling time is the ticket preset recycling time plus delay time, ensuring that the ticket recycling action occurs after the service-allowed longest delay time, and realizing the delayed recycling of the ticket; the ticket can also be delayed for verification within the longest delay time allowed by the service after the ticket expires.

3. Coupon consultation (i.e., the coupon query described in the above embodiment):

1. the actual use time, that is, the actual transaction time described in the above embodiment, is obtained from the request and is used in the subsequent step. The actual service time is generally uploaded by merchants accessed by a payment platform, and a certain possibility of black ash production exists. In the embodiment of the specification, the actual use time can be accurately controlled by combining the sales product code, the sign-up merchant number and the like. The request is understood as a transaction request, an order payment request, or the like described in the above embodiments.

2. Inquiring the ticket in the validity period according to the actual use time: instead of querying the database for the ticket currently in the expiration date, the database is adapted to query for the ticket whose actual usage time is in the ticket expiration date.

3. Ticket rule checking and filtering: and (3) checking whether the ticket inquired in the step (2) can be used or not according to rules of template configuration and the like, such as checking whether the ticket is in an effective period or not, checking whether the using rules of the ticket meet business requirements or not and the like.

4. And (3) carrying out ticket use times limit check according to the actual use time: the ticket use number limit check is not performed according to the current time, but is adjusted to be performed according to the actual use time. For example: coupons that can only be used once a day are actually used for 2019-01-02, 2019-01-03 initiate order receipt payment requests to the paymate, and the embodiment of the specification directly verifies that 2019-01-02 reaches the limit of times, rather than verifying that 2019-01-03.

4. Ticket verification:

1. the actual use time, that is, the actual transaction time described in the above embodiment, is obtained from the request and is used in the subsequent step. The actual use time is uploaded by merchants accessed by the payment platform, and a certain possibility of black ash production exists. In the embodiment of the specification, the actual use time can be controlled by combining the sales product code with the sign-up merchant number and the like. The ticket consultation and ticket verification may have time differences, and in the embodiment of the present specification, the ticket obtained in the ticket consultation step may be secondarily verified using the actual use time, that is, the actual transaction time, during the data processing process of the ticket verification.

2. Checking whether the ticket is in the validity period according to the actual use time: the ticket is no longer checked for the current expiration date, but is adjusted to check if the actual usage time is within the ticket expiration date.

3. Ticket verification: and verifying the ticket by verifying and verifying the ticket. If there are a plurality of verified coupons, any one of the coupons may be verified, the coupon closest to the expiration date may be selected for verification, or the coupon with the earliest validation time may be selected for verification, or the user may be notified of the verification of the coupon, and the user may select which coupon to verify.

4. And (3) carrying out checksum updating on the ticket using times according to the actual using time: the checksum update of the ticket use times is not performed according to the current time, but is adjusted to the checksum update of the ticket use times limitation according to the actual use time. For example: the ticket can only be used once a day, the actual use time is 2019-01-02, 2019-01-03 initiates a receipt payment request to a payment platform, and then the ticket is directly checked to see if 2019-01-02 reaches the time limit, and the ticket is not checked to see 2019-01-03 any more. At the same time, after ticket validation, record 2019-01-02 uses ticket 1 time, rather than record 2019-01-03 using ticket 1 time.

In some embodiments of the present disclosure, as shown in fig. 5, the ticket verification may be performed first, and then the checksum update for the ticket usage limit may be performed. However, it should be noted that the checksum update for the ticket verification and ticket usage limit fails or succeeds simultaneously, such as: if the verification result of the limit of the number of times of use of the ticket fails after the ticket is verified, that is, the number of times of use of the ticket to be verified exceeds the limit of the number of times of use of the ticket, the ticket verification will also fail, that is, the ticket cannot be verified.

The present description embodiment internalizes the externally strong perceived coupon lifecycle problem into a generic capability problem for coupons. The delayed recovery of the template/ticket is realized while the effective use of marketing funds is ensured to the maximum extent by overlapping the recovery time of the template/ticket with the delay time. And according to the actual use time, the inquiry, the second verification of the validity period, the number of times limit check and the billing of the ticket are carried out, and the delayed verification and the sale of the ticket are realized in an externally transparent mode. The delayed verification capability of the ticket in the embodiments of the present description is a generic capability of the ticket, and can be directly opened to all ticket verification, and practically fulfilling the ticket use commitments to the user. The validity period definition of the ticket is not affected: the effective time and the dead time do not introduce the life cycle definition of the new ticket. The coupon delay verification is supported, the outside is not perceived, only the coupon platform is required to perceive and adapt to support, all access scenes are not influenced, the delay verification capability can be opened for all coupons, and the coupon use commitment to the user is practically fulfilled.

In the present specification, each embodiment of the method is described in a progressive manner, and the same and similar parts of each embodiment are referred to each other, and each embodiment mainly describes differences from other embodiments. Reference is made to the description of parts of the method embodiments where relevant.

Based on the above-mentioned data processing method for the delayed ticket verification, one or more embodiments of the present disclosure further provide a data processing device for delayed ticket verification. The apparatus may include a system (including a distributed system), software (applications), modules, components, servers, clients, etc. that employ the methods described in the embodiments of the present specification in combination with the necessary apparatus to implement the hardware. Based on the same innovative concepts, the embodiments of the present description provide means in one or more embodiments as described in the following embodiments. Because the implementation schemes and methods of the device for solving the problems are similar, the implementation of the device in the embodiments of the present disclosure may refer to the implementation of the foregoing method, and the repetition is omitted. As used below, the term "unit" or "module" may be a combination of software and/or hardware that implements the intended function. While the means described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and contemplated.

Specifically, fig. 6 is a schematic block diagram of an embodiment of a data processing apparatus for ticket delay verification provided in the present specification, and as shown in fig. 6, the data processing apparatus for ticket delay verification provided in the present specification may include: an actual transaction time acquisition module 61, a ticket inquiry module 62, a ticket verification module 63, wherein:

the actual transaction time acquisition module 61 may be configured to receive a transaction request, and acquire an actual transaction time according to the transaction request;

the ticket inquiry module 62 may be configured to inquire, according to the actual transaction time, a target ticket in the user account that accords with the usage rule, where the recovery time of the target ticket is set to be a preset recovery time plus a delay time of the ticket;

the ticket verification module 63 may be configured to verify the target ticket.

According to the data processing device for delayed verification and verification of the ticket, provided by the embodiment of the specification, the delayed recovery of the ticket is realized by setting the recovery time of the ticket to be the preset recovery time and overlapping the delay time of the ticket, the life cycle of the ticket is not required to be redefined, and the complexity of data processing for ticket generation and verification is reduced. And according to the actual transaction time, the inquiry and verification of the ticket are carried out, so that the delayed verification of the ticket is realized in an externally transparent mode, and the verification accuracy of the ticket is ensured.

On the basis of the above embodiments, in some embodiments of the present specification, the ticket verifying module is further configured to:

after verifying the target ticket, updating the check sum of the limit of the using times of the target ticket according to the actual using time.

According to the embodiment of the specification, the verification of the limit of the use times of the target ticket is performed based on the actual transaction time, the update record is performed on the use times of the target ticket, and the verification and update of the limit of the use times of the target ticket are performed without adopting the current time, namely the time for receiving the transaction request, so that the accuracy of the record of the use times of the ticket is improved, and the accuracy of ticket verification and verification is further improved.

In some embodiments of the present disclosure, the coupon query module is specifically configured to:

When the embodiment of the specification queries the ticket, the validity period and the use times of the ticket are checked based on the actual transaction time, but not the current time, so that the accuracy of the ticket query result is improved, and an accurate data basis is provided for the verification of the follow-up ticket.

On the basis of the above embodiments, in some embodiments of the present specification, if the ticket is a ticket that allows delayed cancellation, the ticket is provided with a delayed cancellation flag; correspondingly, the coupon inquiry module is specifically configured to:

According to the embodiment of the specification, the effective ticket can be rapidly inquired in a delayed verification and verification marking mode, and the ticket inquiry efficiency and accuracy are improved.

On the basis of the above embodiment, the actual transaction time acquisition module is specifically configured to:

According to the embodiment of the specification, the actual transaction time can be obtained from the transaction data based on the sales product code and/or the contracted merchant number, so that the control of the actual transaction time is enhanced, the accuracy of obtaining the actual transaction time is improved, and a data basis is provided for the accurate verification of follow-up coupons.

accordingly, the verifying the target ticket includes:

When the ticket verification is carried out, the target ticket inquired by the ticket is subjected to secondary verification, so that the ticket verification accuracy is improved.

On the basis of the above embodiments, in some embodiments of the present disclosure, the apparatus further includes a ticket issuing module, where the ticket issuing module is specifically configured to issue a ticket, before performing the ticket delay verification, by:

It should be noted that the above description of the apparatus according to the method embodiment may also include other implementations. Specific implementation manner may refer to the description of the corresponding method embodiments, which is not described herein in detail.

The embodiment of the specification also provides a data processing system for delayed verification of the ticket, which can perform corresponding data processing for different stages of the lifecycle of the ticket, and specifically comprises:

It should be noted that the above description of the system according to the method embodiment may also include other implementations. Specific implementation manner may refer to the description of the corresponding method embodiments, which is not described herein in detail.

The embodiments of the present specification also provide a data processing apparatus for ticket delay verification, including: at least one processor and a memory for storing processor-executable instructions that when executed implement the data processing method of the ticket delay verification of the above embodiment, such as:

inquiring a target ticket conforming to a use rule in a user account according to the actual transaction time, wherein the recovery time of the target ticket is set as ticket preset recovery time plus delay time;

and verifying the target ticket.

It should be noted that the description of the processing apparatus according to the method embodiment described above may also include other implementations. Specific implementation may refer to descriptions of related method embodiments, which are not described herein in detail.

The data processing device or processing equipment or system for delayed verification of the ticket provided by the specification can also be applied to various data analysis processing systems. The system or apparatus or processing device may include a data processing apparatus for delayed cancellation of coupons in any of the above embodiments. The system or device or processing apparatus may be a separate server, or may include a server cluster, a system (including a distributed system), software (applications), an actual operating device, a logic gate device, a quantum computer, etc. using one or more of the methods or one or more of the embodiments of the present description, in combination with necessary terminal devices that implement hardware. The detection system for reconciling discrepancy data may comprise at least one processor and a memory storing computer executable instructions that when executed by the processor perform the steps of the method described in any one or more of the embodiments described above.

The method embodiments provided in the embodiments of the present specification may be performed in a mobile terminal, a computer terminal, a server, or similar computing device. Taking the example of running on a server, fig. 7 is a block diagram of the hardware structure of a data processing server for ticket delay verification in one embodiment of the present specification, which may be the data processing apparatus for ticket delay verification or the data processing device for ticket delay verification in the above embodiment. As shown in fig. 7, the server 10 may include one or more (only one is shown in the figure) processors 100 (the processors 100 may include, but are not limited to, a microprocessor MCU, a processing device such as a programmable logic device FPGA), a memory 200 for storing data, and a transmission module 300 for communication functions. It will be appreciated by those of ordinary skill in the art that the configuration shown in fig. 7 is merely illustrative and is not intended to limit the configuration of the electronic device described above. For example, server 10 may also include more or fewer components than shown in FIG. 7, for example, may also include other processing hardware such as a database or multi-level cache, a GPU, or have a different configuration than that shown in FIG. 5.

The memory 200 may be used to store software programs and modules of application software, such as program instructions/modules corresponding to the data processing method of ticket delay verification in the embodiment of the present specification, and the processor 100 executes the software programs and modules stored in the memory 200 to perform various functional applications and data processing. Memory 200 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some examples, memory 200 may further include memory located remotely from processor 100, which may be connected to the computer terminal via a network. Examples of such networks include, but are not limited to, the internet, intranets, local area networks, mobile communication networks, and combinations thereof.

The transmission module 300 is used to receive or transmit data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider of a computer terminal. In one example, the transmission module 300 includes a network adapter (Network Interface Controller, NIC) that can connect to other network devices through a base station to communicate with the internet. In one example, the transmission module 300 may be a Radio Frequency (RF) module for communicating with the internet wirelessly.

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 method or apparatus according to the above embodiments provided in the present specification may implement service logic by a computer program and be recorded on a storage medium, where the storage medium may be read and executed by a computer, to implement the effects of the schemes described in the embodiments of the present specification.

The storage medium may include physical means for storing information, typically by digitizing the information before storing it in an electronic, magnetic, or optical medium. The storage medium may include: means for storing information using electrical energy such as various memories, e.g., RAM, ROM, etc.; devices for storing information using magnetic energy such as hard disk, floppy disk, magnetic tape, magnetic core memory, bubble memory, and USB flash disk; devices for optically storing information, such as CDs or DVDs. Of course, there are other ways of readable storage medium, such as quantum memory, graphene memory, etc.

The data processing method or device for ticket delay verification provided in the embodiments of the present disclosure may be implemented in a computer by executing corresponding program instructions by a processor, for example, implemented on a PC side using the c++ language of a windows operating system, implemented on a linux system, or implemented on an intelligent terminal using, for example, android, iOS system programming languages, and implemented based on processing logic of a quantum computer.

It should be noted that, the descriptions of the apparatus, the computer storage medium, and the system according to the related method embodiments described in the foregoing description may further include other implementations, and specific implementation manners may refer to descriptions of corresponding method embodiments, which are not described herein in detail.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are referred to each other, and each embodiment is mainly described in a different manner from other embodiments. In particular, for a hardware + program class embodiment, the description is relatively simple as it is substantially similar to the method embodiment, and reference is made to the partial description of the method embodiment where relevant.

Embodiments of the present description are not limited to situations in which industry communication standards, standard computer data processing and data storage rules are required or described in one or more embodiments of the present description. Some industry standards or embodiments modified slightly based on the implementation described by the custom manner or examples can also realize the same, equivalent or similar or predictable implementation effect after modification of the above examples. Examples of data acquisition, storage, judgment, processing, etc., using these modifications or variations may still fall within the scope of alternative implementations of the examples of this specification.

In the 90 s of the 20 th century, improvements to one technology could clearly be distinguished as improvements in hardware (e.g., improvements to circuit structures such as diodes, transistors, switches, etc.) or software (improvements to the process flow). However, with the development of technology, many improvements of the current method flows can be regarded as direct improvements of hardware circuit structures. Designers almost always obtain corresponding hardware circuit structures by programming improved method flows into hardware circuits. Therefore, an improvement of a method flow cannot be said to be realized by a hardware entity module. For example, a programmable logic device (Programmable Logic Device, PLD) (e.g., field programmable gate array (Field Programmable Gate Array, FPGA)) is an integrated circuit whose logic function is determined by the programming of the device by a user. A designer programs to "integrate" a digital system onto a PLD without requiring the chip manufacturer to design and fabricate application-specific integrated circuit chips. Moreover, nowadays, instead of manually manufacturing integrated circuit chips, such programming is mostly implemented by using "logic compiler" software, which is similar to the software compiler used in program development and writing, and the original code before the compiling is also written in a specific programming language, which is called hardware description language (Hardware Description Language, HDL), but not just one of the hdds, but a plurality of kinds, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), lava, lola, myHDL, PALASM, RHDL (Ruby Hardware Description Language), etc., VHDL (Very-High-Speed Integrated Circuit Hardware Description Language) and Verilog are currently most commonly used. It will also be apparent to those skilled in the art that a hardware circuit implementing the logic method flow can be readily obtained by merely slightly programming the method flow into an integrated circuit using several of the hardware description languages described above.

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, application specific integrated circuits (Application Specific Integrated Circuit, ASIC), programmable logic controllers, and embedded microcontrollers, examples of which include, but are not limited to, the following microcontrollers: ARC 625D, atmel AT91SAM, microchip PIC18F26K20, and Silicone Labs C8051F320, the memory controller may also be implemented as part of the control logic of the memory. Those skilled in the art will also appreciate that, in addition to implementing the controller in a pure computer readable program code, it is well possible to implement the same functionality by logically programming the method steps such that the controller is in the form of logic gates, switches, application specific integrated circuits, programmable logic controllers, embedded microcontrollers, etc. Such a controller may thus be regarded as a kind of hardware component, and means for performing various functions included therein may also be regarded as structures within the hardware component. Or even means for achieving the various functions may be regarded as either software modules implementing the methods or structures within hardware components.

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. One typical implementation is a computer. In particular, the computer may be, for example, a personal computer, a laptop computer, a car-mounted human-computer interaction device, a cellular telephone, a camera phone, a smart phone, 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.

Although one or more embodiments of the present description provide method operational steps as described in the embodiments or flowcharts, more or fewer operational steps may be included based on conventional or non-inventive means. The order of steps recited in the embodiments is merely one way of performing the order of steps and does not represent a unique order of execution. When implemented in an actual device or end product, the instructions may be executed sequentially or in parallel (e.g., in a parallel processor or multi-threaded processing environment, or even in a distributed data processing environment) as illustrated by the embodiments or by the figures. 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, it is not excluded that additional identical or equivalent elements may be present in a process, method, article, or apparatus that comprises a described element. The terms first, second, etc. are used to denote a name, but not any particular order.

For convenience of description, the above devices are described as being functionally divided into various modules, respectively. Of course, when one or more of the present description is implemented, the functions of each module may be implemented in the same piece or pieces of software and/or hardware, or a module that implements the same function may be implemented by a plurality of sub-modules or a combination of sub-units, or the like. The above-described apparatus embodiments are merely illustrative, for example, the division of the units is merely a logical function division, and there may be additional divisions when actually implemented, for example, multiple units or components may be combined or integrated into another system, or some features may be omitted or not performed. Alternatively, the coupling or direct coupling or communication connection shown or discussed with each other may be an indirect coupling or communication connection via some interfaces, devices or units, which may be in electrical, mechanical or other form.

The present invention is 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 flowchart illustrations and/or block diagrams, and combinations of flows and/or blocks in the flowchart illustrations 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 one typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.

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

Computer readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement 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 storage media for a computer 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, read only compact disc read only memory (CD-ROM), digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage, graphene 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. Computer-readable media, as defined herein, does not include transitory computer-readable media (transmission media), such as modulated data signals and carrier waves.

One skilled in the relevant art will recognize that one or more embodiments of the present description may be provided as a method, system, or computer program product. Accordingly, one or more embodiments of the present description may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Moreover, one or more embodiments of the present description can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) having computer-usable program code embodied therein.

One or more embodiments of the present specification 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. One or more embodiments of the present specification 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.

In this specification, each embodiment is described in a progressive manner, and identical and similar parts of each embodiment are referred to each other, and each embodiment is mainly described in a different manner from other embodiments. In particular, for system embodiments, the description is relatively simple as it is substantially similar to method embodiments, and reference is made to the section of the method embodiments where relevant. In the description of the present specification, a description referring to terms "one embodiment," "some embodiments," "examples," "specific examples," or "some examples," etc., means that a particular feature, structure, material, or characteristic described in connection with the embodiment or example is included in at least one embodiment or example of the present specification. In this specification, schematic representations of the above terms are not necessarily directed to the same embodiment or example. Furthermore, the particular features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples. Furthermore, the different embodiments or examples described in this specification and the features of the different embodiments or examples may be combined and combined by those skilled in the art without contradiction.

The foregoing is merely an example of one or more embodiments of the present specification and is not intended to limit the one or more embodiments of the present specification. Various modifications and alterations to one or more embodiments of this description will be apparent to those skilled in the art. Any modification, equivalent replacement, improvement, or the like, which is within the spirit and principles of the present specification, should be included in the scope of the claims.

Claims

1. A data processing method for delayed validation of coupons, comprising:

delaying the verification of the target ticket based on the recovery time of the target ticket;

according to the actual transaction time, inquiring a target ticket conforming to a use rule in a user account, wherein the target ticket comprises the following components:

according to the actual transaction time, checking the use frequency limit of the effective ticket corresponding to the actual transaction time, and taking the ticket meeting the use frequency limit as the target ticket;

If the ticket is a ticket allowing delayed verification, the ticket is provided with a delayed verification mark;

accordingly, the querying the valid ticket in the user account that is in the valid period at the actual transaction time includes:

taking a ticket with the current time in the validity period and a ticket with the delay verification mark as the valid ticket;

after a target ticket meeting the use rule is inquired, performing secondary verification on the target ticket, and performing delay verification on the target ticket after the secondary verification.

2. The method of claim 1, the method further comprising:

after verifying the target ticket, updating the check sum of the limit of the use times of the target ticket according to the actual transaction time.

3. The method of claim 1, the obtaining an actual transaction time from the transaction request comprising:

4. The method of claim 1, the verifying the target coupon comprising:

5. The method of any one of claims 1-4, further comprising: prior to the delayed validation of the ticket, the ticket is issued using the following method:

6. A data processing apparatus for delayed verification of coupons, comprising:

A ticket verification module for performing delayed verification of the target ticket based on the recovery time of the target ticket;

7. The apparatus of claim 6, the coupon verification module further to:

8. The apparatus of claim 6, the coupon query module is specifically configured to:

9. The apparatus of claim 8, wherein if the ticket is a ticket that allows delayed cancellation, the ticket is provided with a delayed cancellation flag; correspondingly, the coupon inquiry module is specifically configured to:

and taking the ticket with the current time in the validity period and the ticket with the delayed verification mark as the valid ticket.

10. The apparatus of claim 6, wherein the actual transaction time acquisition module is specifically configured to:

11. The apparatus of claim 6, the coupon verification module further to:

Accordingly, the verifying the target ticket includes:

12. The apparatus of any of claims 6-11, further comprising a ticket issuing module, the ticket issuing module being specifically configured to, prior to the ticket delay verification, issue a ticket by:

13. A data processing system for delayed validation of coupons, comprising:

the ticket consulting module is used for acquiring actual transaction time according to the transaction request, and inquiring a valid ticket in the user account in the validity period of the actual transaction time according to the actual transaction time; according to the actual transaction time, checking the use frequency limit of the effective ticket corresponding to the actual transaction time, and taking the ticket meeting the use frequency limit as a target ticket; wherein, if the ticket is a ticket allowing delayed verification, the ticket is provided with a delayed verification mark; accordingly, the querying the valid ticket in the user account that is in the valid period at the actual transaction time includes: taking a ticket with the current time in the validity period and a ticket with the delay verification mark as the valid ticket; after a target ticket conforming to a use rule is inquired, carrying out secondary verification on the target ticket, and after the secondary verification, carrying out delay verification on the target ticket;

The ticket verifying and verifying module is used for obtaining actual transaction time according to the transaction request, verifying whether the target ticket inquired by the ticket verifying and inquiring module is in the effective period according to the actual transaction time, verifying the limit of the using times of the target ticket according to the actual transaction time, delaying verifying and verifying the verified target ticket based on the recovery time of the target ticket, and updating and recording the using times of the target ticket.

14. A data processing apparatus for delayed validation of coupons, comprising: at least one processor and a memory for storing processor-executable instructions which, when executed, implement the method of any one of claims 1-5.