Payment method, system, device and medium

Abstract

The invention relates to a payment method, system and device and a medium, and the method comprises the steps: obtaining the historical transaction information of an object in a payment system when a payment behavior occurs; determining whether the object belongs to a target object based on the historical transaction information; when the object belongs to the target object, displaying a preset payment option; and when a trigger operation for the preset payment option is received, calling the payment system to initiate payment. Through the payment method provided by the invention, the problem that the identity of the user cannot be verified due to the fact that the identity information of the user is difficult to obtain can be effectively solved.

Description

Technical Field

[0001] The present application relates to the field of computers, and in particular to a payment method, system, device and medium. Background Art

[0002] In the electronic transaction scenario within a mobile device, in order to control the distribution of value-added subscription products and attract new users, the content service provider corresponding to the application will provide new users with preferential purchase restrictions. In order to prevent some users from frequently registering new users and repeatedly obtaining preferential rights, the device binding method is proposed as a screening condition for new users. That is, if an application on a device has registered or logged in a user and obtained the corresponding preferential purchase restriction service, when other users order the same preferential purchase restriction service on the device, they will no longer have the corresponding purchase qualification.

[0003] However, on some mobile devices, all electronic transactions must use the transaction system provided by the mobile device manufacturer. In addition, the mobile device manufacturer, for the purpose of protecting the privacy of users using its mobile devices, does not provide the device with the identity information of the corresponding user and the identification information of the mobile device.

[0004] Therefore, in this case, some users who like to "take advantage of the situation" will use this mechanism to repeatedly register new accounts with content service providers, and use the above-mentioned devices to repeatedly obtain corresponding preferential products. There is even an industry that sells new accounts that enjoy preferential services in this way. On the one hand, it undermines the fairness of normal users, and on the other hand, it seriously affects the rights and interests of content service providers. In the long run, it will be detrimental to the healthy development of the entire market. Summary of the invention

[0005] The present application provides a payment method, system, device and medium to solve the problem in traditional payment methods that the identity information of mobile device users cannot be identified due to the privacy protection policy of the transaction system provided by the mobile device manufacturer. Without infringing the privacy of users, it ensures that normal users use the services of content service providers fairly and impartially, while maintaining the accuracy and effectiveness of the preferential subscription services of content providers and reducing losses.

[0006] In a first aspect, the present application provides a payment method, comprising:

[0007] When a payment occurs, obtain the historical transaction information of the object in the payment system;

[0008] determining whether the object belongs to a target object based on the historical transaction information;

[0009] When the object belongs to the target object, displaying a preset payment option;

[0010] When a trigger operation for the preset payment option is received, the payment system is called to initiate payment.

[0011] In some embodiments of the present application, obtaining historical transaction information of an object in a payment system includes:

[0012] Querying the target bill corresponding to the target business in the historical transaction information of the object through the payment system;

[0013] The determining whether the object belongs to a target object based on the historical transaction information includes:

[0014] Determining whether the object belongs to the target object according to whether the target bill corresponding to the target business in the historical transaction information is empty;

[0015] When the query result is that the target ticket is empty, it is determined that the object belongs to the target object.

[0016] In some embodiments of the present application, the method further comprises:

[0017] When the query result is that the target bill is not empty, determining whether the target bill contains an original transaction number;

[0018] When the original transaction number does not exist in the target note, it is determined that the object belongs to the target object.

[0019] In some embodiments of the present application, the method further comprises:

[0020] When the original transaction number exists in the target note, the original transaction number is used to determine whether the object belongs to the target object.

[0021] In some embodiments of the present application, determining whether the object belongs to the target object by using the original transaction number includes:

[0022] Calling the query interface of the payment system to query whether the validity status of the original transaction number is a predetermined value;

[0023] When the valid state returned by the query interface is a predetermined value, it is determined that the object belongs to the target object.

[0024] In some embodiments of the present application, the method further comprises:

[0025] When the original transaction number does not exist in the target bill, sending a query request for the object to the server, wherein the query request is used to query whether the object meets a preset condition; receiving a query result returned by the server in response to the query request;

[0026] When the query result indicates that the object meets a preset condition, it is determined that the object belongs to a target object.

[0027] In some embodiments of the present application, preset payment options are displayed, including:

[0028] Determine the identity information of the target object, and send the identity information to the payment system, so that the payment system adds the identity information to the payment request to obtain a preset payment option;

[0029] Receive and display the preset payment options sent by the payment system.

[0030] In a second aspect, the present application provides a payment system, characterized by comprising:

[0031] The information acquisition module is used to obtain the historical transaction information of the object in the payment system when the payment behavior occurs;

[0032] A target object determination module, configured to determine whether the object belongs to a target object based on the historical transaction information;

[0033] a payment display module, for displaying preset payment options when the object belongs to a target object;

[0034] The payment execution module is used to call the payment system to initiate payment when receiving a trigger operation for the preset payment option.

[0035] In a third aspect, the present application provides a computer device: at least one communication interface; at least one bus connected to the at least one communication interface; at least one processor connected to the at least one bus; at least one memory connected to the at least one bus, wherein the processor is configured to execute any one of the payment methods described above.

[0036] In a fourth aspect, the present application also provides a computer storage medium storing computer executable instructions, wherein the computer executable instructions are used to execute the payment method described in any one of the above items of the present application.

[0037] The above technical solution provided by the embodiment of the present application has the following advantages over the prior art: the method provided by the embodiment of the present application confirms whether the user is a new user who meets the requirements of the preferential service by obtaining the historical transaction information of the user in the predetermined payment system, and thus confirms whether the user is a new user without obtaining the identity information involving the user's privacy. This effectively solves the obstacles to identifying new users caused by the payment mechanism and privacy protection strategy of some devices, and further ensures the fairness of users on different device platforms and the accuracy of the preferential services of content service providers. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and, together with the description, serve to explain the principles of the invention.

[0039] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative labor.

[0040] One or more embodiments are exemplarily described by pictures in the corresponding drawings, and these exemplified descriptions do not constitute limitations on the embodiments. Elements with the same reference numerals in the drawings represent similar elements, and unless otherwise stated, the figures in the drawings do not constitute proportional limitations.

[0041] Figure 1 A schematic diagram of a payment method provided in an embodiment of the present application;

[0042] Figure 2 A schematic diagram of a process for determining a target user based on ticket information provided in an embodiment of the present application;

[0043] Figure 3 A schematic diagram of a process for confirming a target user based on an original transaction number provided in an embodiment of the present application;

[0044] Figure 4 A schematic diagram of a process for confirming a target user by querying the authenticity of an original transaction number provided in an embodiment of the present application;

[0045] Figure 5 A schematic diagram of a process for confirming a target user based on a service end of a content service provider provided in an embodiment of the present application;

[0046] Figure 6 A flow chart of associating a user's identity information with a payment behavior when a payment behavior occurs, provided in an embodiment of the present application;

[0047] Figure 7 A schematic diagram of the structure of a payment system provided in an embodiment of the present application;

[0048] Figure 8 A schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0049] In order to make the purpose, technical solution and advantages of the embodiments of the present application clearer, the technical solution in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0050] The disclosure below provides many different embodiments or examples to implement different structures of the present invention. In order to simplify the disclosure of the present invention, the parts and settings of specific examples are described below. Of course, they are only examples, and the purpose is not to limit the present invention. In addition, the present invention can repeat reference numbers and / or letters in different examples. This repetition is for the purpose of simplification and clarity, and does not itself indicate the relationship between the various embodiments and / or settings discussed.

[0051] This application aims to solve the problem of in-app purchases in traditional applications, where all in-app purchases can only be paid for using the payment system provided by the device manufacturer on some devices where the application is located. However, due to the privacy protection policy of the device manufacturer, the content service provider corresponding to the application cannot obtain the identity information of the user using the corresponding device, and thus cannot determine whether it is a new device, resulting in the abuse of the corresponding preferential policy on this type of device.

[0052] Figure 1 A payment method provided in an embodiment of the present application includes:

[0053] Step S1: when a payment occurs, obtain the historical transaction information of the object in the payment system;

[0054] Step S2: determining whether the object belongs to the target object based on the historical transaction information;

[0055] Step S3: when the object belongs to the target object, display the preset payment option;

[0056] Step S4: upon receiving a trigger operation for the preset payment option, calling the payment system to initiate payment.

[0057] In the embodiments of the present application, the payment behavior refers to a series of operations initiated by an application in a mobile device in response to a user's operation to purchase a certain product or service.

[0058] The object refers to the user who uses the corresponding application. When using the application, the user will register a corresponding account in the system formed by the application and the content service provider. The user obtains the content of the content service provider through the account, and uses the account as authentication information with the content service provider to purchase the right to use the relevant content of the content service provider.

[0059] The payment system refers to the payment system provided by the manufacturer of the mobile device or terminal device where the application is located, or the payment system provided by the corresponding operating system embedded in the mobile device, or other third-party payment systems installed on the same mobile device or terminal device as the application. Historical transaction information refers to the information related to the historical payments of the corresponding user using the payment system; it should be noted that the user also has a corresponding payment account in the payment system, that is, the account registered by the user in the payment system. Furthermore, historical transaction information refers to the information related to the historical payments corresponding to the user's account in the payment system, such as corresponding transaction records and other information; when a user has multiple accounts in the payment system, the corresponding historical transaction information refers to the historical transaction information corresponding to the payment account logged in by the user on the mobile device.

[0060] The target object refers to the user who meets the target service purchase qualifications provided by the content service provider, for example, a content service provider requires the use of a specific mobile device and the user has not purchased a certain content service.

[0061] Payment options refer to the graphical interface provided by the application for users to choose. The graphical interface includes the payment amount after the discount. When the user clicks on the payment option, the application will call the corresponding payment system to initiate payment. The content displayed in the payment option can vary according to different scenarios. For example, it can display a specific currency amount or the corresponding virtual asset value. This application does not specifically limit its content.

[0062] A trigger operation refers to an interactive action performed by a user on a mobile device according to the interactive characteristics of the corresponding mobile device, which triggers the subsequent procedure of the payment option provided by the application.

[0063] In step S1, when the user triggers the payment behavior provided by the application according to the content provided by the application and based on the interactive action corresponding to the mobile device, the historical transaction information of the user in the payment system corresponding to the mobile device is obtained.

[0064] In an embodiment of the present application, historical transaction information can be obtained through the payment system of the mobile device where the application is located when the payment behavior occurs. It can also be obtained through the payment system before the payment behavior occurs. The two methods are determined according to the payment method of the payment option. For example, if the corresponding payment behavior requires a response speed, a corresponding query request can be initiated to the payment system of the mobile device where the application is located at any time before the user initiates the payment behavior to obtain the user's historical transaction information in the payment system, and save it to the local storage space of the application, or on the back-end server of the content service provider. When the user initiates the payment behavior, the saved historical transaction information is obtained from the corresponding storage space.

[0065] In some embodiments of the present application, due to the way of obtaining and saving historical transaction information in advance, there will be information delay. For example, if there is no corresponding transaction record in the historical transaction information obtained in advance, it may be considered to meet the judgment conditions of a new user. However, after the user has purchased the same product or service on other devices of the same type, the user is no longer a new user. However, since the historical transaction information obtained in advance is not updated in time, it may cause the user to be misjudged as meeting the conditions of a new user when initiating payment again on the device, and enjoy the corresponding preferential payment conditions again. To this end, each time the user initiates a corresponding payment behavior, the payment system on the mobile device can be accessed first, and the historical transaction information of the payment account logged in by the user on the payment system can be obtained through the corresponding interface on the payment system.

[0066] In step S2, after obtaining the historical transaction information returned by the payment system, the user's historical transaction information is used to determine whether the user meets the conditions for using the corresponding payment option, that is, to confirm whether the user is a target user. Specifically, if a certain payment behavior is only provided for new users using a certain brand of mobile device, and it is determined through historical transaction information that the user does not have a corresponding payment behavior record on the device, and meets the judgment conditions for new users, then it can be considered that the user meets the payment conditions and is a target user. Alternatively, if there is a corresponding transaction record in the historical transaction information, it can be proved that the user has purchased the corresponding service or product, which indirectly indicates that the user is not a new user and does not meet the conditions for subsequent activation of the payment option.

[0067] In step S3, if it is confirmed that the user is qualified to purchase the corresponding product or service, the corresponding payment option is provided to the user. Specifically, when the corresponding application obtains the corresponding historical transaction information through the payment system and confirms that the user meets the payment conditions, the corresponding payment option is displayed.

[0068] In some embodiments of the present application, the display of payment options can be embodied according to different graphic implementation methods. For example, after confirming that the user is the target user, the corresponding payment option (preferential payment option) can be popped up, or the corresponding payment option can be popped up. However, through the graphic display control, only when the user is confirmed as the target user, the corresponding payment option is activated, that is, it can be selected. When the user is not the target user, the corresponding payment option is displayed, but cannot be selected, or after being selected, it will not trigger subsequent payment behavior.

[0069] In step S4, when the user responds to the payment option displayed by the application and selects the payment option through the input device provided by the mobile device or terminal device, the application calls the corresponding payment system to initiate payment.

[0070] It should be noted that initiating payment through the payment system means purchasing the services or products of the content service provider corresponding to the application through the payment system. The payment system and the corresponding content service provider have already realized the corresponding payment functions for the corresponding services or products. For example, taking Apple's payment system as an example, the in-app purchase items (virtual products or services) of the application located on the Apple device must be purchased using Apple's payment system. When the content service provider releases the application in Apple's software ecosystem, users using Apple devices can download and install the corresponding application. If there are corresponding in-app purchase items in the application, the content service provider needs to release the corresponding in-app purchase item products or services in Apple's payment system. Only in this way, when the user wants to purchase the corresponding in-app purchase item, he chooses to purchase it through the payment option provided in the corresponding application. After receiving the user's confirmation purchase operation, the application calls the Apple payment system on the Apple device to initiate payment. According to the payment logic of the Apple payment system, after the payment is successful, the Apple system will transfer the payment paid by the user for the product or service purchased in the Apple system to the account of the content service provider, and inform the content service provider that the payment behavior initiated by the corresponding Apple device is completed. The content service provider provides content services to the application on the corresponding Apple device according to the corresponding product or service.

[0071] like Figure 2 As shown, in some embodiments of the present application, obtaining historical transaction information of an object in a payment system includes:

[0072] Step S21, querying the target bill corresponding to the target business in the historical transaction information of the object through the payment system;

[0073] The determining whether the object belongs to a target object based on the historical transaction information includes:

[0074] Step S21, determining whether the object belongs to the target object according to whether the target bill corresponding to the target business in the historical transaction information is empty;

[0075] Step S23: When the query result shows that the target ticket is empty, determine that the object belongs to the target object.

[0076] In this embodiment, the target business refers to a product or service provided by the application, that is, the content service business provided by the corresponding content service provider. The target ticket is the transaction information provided by the corresponding payment system for the in-app purchase item in a certain application. In some payment systems, if the corresponding user has purchased a product or service of a certain application, a corresponding target ticket will be generated in the payment system. Therefore, when the target object is set to a user who has not purchased a certain product or service, the target ticket of the corresponding payment system can be used to confirm whether the corresponding user meets the conditions.

[0077] Specifically, when the corresponding application system provides payment options for the corresponding user, it first sends a request to the payment system to obtain the target bill of the target business. The target bill is used to determine whether the corresponding user is the target user. That is, if the corresponding target bill does not exist, it is considered that the user using the application at this time has not purchased the corresponding product or service before and meets the payment conditions. If the corresponding target bill exists, it means that the user has purchased the same product or service before and is no longer a satisfied target user. For example, taking Apple's payment system as an example, when a user purchases a membership subscription or certain content through the application of a content service provider, if the content service provider stipulates that the first purchase of a certain service or product can enjoy the corresponding preferential policy. It is possible to obtain whether the user has a target bill on the product or service through Apple's payment system. If the target bill fed back by the Apple payment system is empty, it means that the user has not purchased the corresponding product or service, meets the corresponding preferential policy conditions, and is a target user. If it is not empty, it means that the user may have purchased the corresponding product or service (it is possible that the user repeatedly registers the account of the content service provider and repeatedly logs in to the corresponding application to realize the preferential policy service), and the user does not meet the target user conditions.

[0078] like Figure 3 As shown, in some embodiments of the present application, the method further includes:

[0079] Step S31: when the query result shows that the target bill is not empty, determine whether there is an original transaction number in the target bill;

[0080] Step S32: When the original transaction number does not exist in the target note, determine that the object belongs to the target object.

[0081] In this embodiment, as described in the above example, if the corresponding bill information is obtained through the corresponding payment system, in some cases, the bill information of the payment system may be abnormal. For example, in some cases, although the feedback bill information of the payment system can be obtained, the corresponding user may not have purchased the corresponding product or service through the payment system.

[0082] Therefore, after obtaining the corresponding target bill, further determine whether the target bill has the corresponding original transaction number (Original Transaction ID). The original transaction number is a unique identifier generated by the corresponding payment system to ensure the uniqueness and traceability of each transaction. If the corresponding original transaction number does not exist in the target bill, it means that the target bill obtained is indeed an erroneous target bill obtained due to an error in the payment system. The user should enjoy the corresponding preferential policies and is a target user.

[0083] In some embodiments of the present application, the method further comprises:

[0084] When the original transaction number exists in the target note, the original transaction number is used to determine whether the object belongs to the target object.

[0085] In this implementation, when the original transaction number exists in the target ticket, it means that the user may have purchased the corresponding product or service. Then the corresponding user should not be the target user.

[0086] like Figure 4 As shown, in some embodiments of the present application, using the original transaction number to determine whether the object belongs to the target object includes:

[0087] Step S42: calling the query interface of the payment system to query whether the validity status of the original transaction number is a predetermined value;

[0088] Step S43: When the valid state returned by the query interface is a predetermined value, determine that the object belongs to the target object.

[0089] In this embodiment, although the target bill is obtained through the payment system and the original transaction number exists in the target bill, it is sometimes impossible to accurately determine that the corresponding user has purchased the corresponding product or service. This is because when obtaining the target bill corresponding to the user in the target business, although the original transaction number exists in the corresponding target bill, the original transaction number does not match the user's payment account and the device where the application is located, that is, the information anomaly is caused by the information processing logic inside the payment system. Taking Apple's payment system as an example, the original transaction number of Apple's payment system is generated based on an Apple device and an Apple account. When the user switches to a new device or uses other Apple users on the old device (a user buys a second-hand Apple mobile phone and registers an Apple account to log in to the second-hand Apple mobile phone), in this case, when the application obtains the user's target bill, it may get a bill with the original transaction number. However, the actual user may have changed. If the user cannot obtain the corresponding preferential policy, it may affect the user's service experience of the content service provider and even cause customer loss.

[0090] Therefore, in this embodiment, after obtaining the target ticket with the original transaction number, it is necessary to query the interface provided by the Apple payment system whether the transaction number is related to the current user and device. If the result fed back by the payment system is true, that is, the original transaction number is the original transaction number corresponding to the current device (the device where the application currently initiating the payment is located) and the current user (Apple payment system account), it means that the user has indeed purchased the same product or service and no longer meets the conditions of a new user. Then the user is not the target user.

[0091] Furthermore, if the query result fed back by the corresponding payment system is false, it means that the original transaction number does not match the payment system account on the current device and the current device. The original transaction number does not belong to the user. Then the user is a target user and can enjoy the relevant preferential policies provided by the content service provider.

[0092] like Figure 5 As shown, in some embodiments of the present application, the method further includes:

[0093] Step S51: when the original transaction number does not exist in the target bill, sending a query request for the object to the server, wherein the query request is used to query whether the object meets a preset condition; and receiving a query result returned by the server in response to the query request;

[0094] Step S52: When the query result indicates that the object meets a preset condition, determine that the object belongs to a target object.

[0095] In this embodiment, if the original transaction number does not exist in the target bill, it can be confirmed that the user has not purchased the corresponding product or service through the corresponding payment system. The conditions of the corresponding preferential policy are met. However, in some scenarios, due to the user account served by the content service provider, the corresponding application can be used on different platforms to obtain content. At the same time, it may also happen that the user purchases the product or service corresponding to the target business on different platforms without using a unified payment system. Or the user has replaced the account and device of the payment system in the corresponding payment system. For example, a user has both an Apple device and an Android device, and has purchased a product or service of a content service provider on the Android device, but has not purchased the same product or service on the Apple device and the corresponding payment system. When obtaining the corresponding target bill and the original transaction number through the Apple payment system, the original transaction number may be empty, or the target bill may be empty. Therefore, when encountering this situation, the application sends a query request to the service end of the content service provider to determine whether the user meets the first purchase of the product or service corresponding to the target business.

[0096] If the result of the server feedback shows that the user has not purchased the product or service corresponding to the target business, it means that the user is a target user.

[0097] like Figure 6 As shown, in some embodiments of the present application, preset payment options are displayed, including:

[0098] S61, determining the identity information of the target object, and sending the identity information to the payment system, so that the payment system adds the identity information to the payment request to obtain a preset payment option;

[0099] S62: Receive and display the preset payment options sent by the payment system.

[0100] In this embodiment, the identity information of the target object refers to the account information registered by the target user in the content service provider. After confirming that the user is not the target user, when initiating a payment request through the corresponding payment system, the account information of the target user is added to the token of the payment request. The token is the authentication information specified by the payment system for verifying the identity of the person initiating the payment request (the user's payment account identity). For example, taking the Apple system as an example, when an application initiates payment for its in-app purchase items on an Apple device (such as products or services of the target business), the application calls the payment program on the Apple device and calls the interface of the payment program to add the user's account information to the corresponding token, so that when the payment program initiates payment to Apple's payment system, it will carry the token and send it to the service end of Apple's payment system through the network. After the server verifies the payment information and completes the deduction of the Apple payment account, it sends the payment result (including the token) and the corresponding deduction to the service end of the content service provider. After obtaining the corresponding payment result, the content service provider parses the corresponding account information that initiates the payment from the token, and can use this as a voucher to provide the corresponding user with content services with relevant permissions.

[0101] Furthermore, after sending the user's account information registered with the content service provider to the corresponding payment system, the corresponding response result of the payment system is accepted, and the corresponding preset payment option is displayed for the user to select the payment option through the corresponding input device for payment.

[0102] The above technical solution provided by the embodiment of the present application has the following advantages over the prior art: the method provided by the embodiment of the present application confirms whether the user is a new user who meets the requirements of the preferential service by obtaining the historical transaction information of the user in the predetermined payment system, and thus confirms whether the user is a new user without obtaining the identity information involving the user's privacy. This effectively solves the obstacles to identifying new users caused by the payment mechanism and privacy protection strategy of some devices, and further ensures the fairness of users on different device platforms and the accuracy of the preferential services of content service providers.

[0103] like Figure 7 As shown, in a second aspect, the present application provides a payment system, characterized in that it includes:

[0104] Information acquisition module 1, used to obtain historical transaction information of the object in the payment system when the payment behavior occurs;

[0105] A target object determination module 2, configured to determine whether the object belongs to a target object based on the historical transaction information;

[0106] A payment display module 3, used for displaying preset payment options when the object belongs to a target object;

[0107] The payment execution module 4 is used to call the payment system to initiate payment when receiving a trigger operation for the preset payment option.

[0108] like Figure 8 As shown, the embodiment of the present application provides a computer device, including a processor 811, a communication interface 812, a memory 813 and a communication bus 814, wherein the processor 811, the communication interface 812, and the memory 813 communicate with each other through the communication bus 814.

[0109] Memory 813, used for storing computer programs;

[0110] In one embodiment of the present application, the processor 811 is used to implement the payment method provided by any one of the above method embodiments when executing the program stored in the memory 813, including:

[0111] When a payment occurs, obtain the historical transaction information of the object in the payment system;

[0112] determining whether the object belongs to a target object based on the historical transaction information;

[0113] When the object belongs to the target object, displaying a preset payment option;

[0114] When a trigger operation for the preset payment option is received, the payment system is called to initiate payment.

[0115] In some embodiments of the present application, obtaining historical transaction information of an object in a payment system includes:

[0116] Querying the target bill corresponding to the target business in the historical transaction information of the object through the payment system;

[0117] The determining whether the object belongs to a target object based on the historical transaction information includes:

[0118] Determining whether the object belongs to the target object according to whether the target bill corresponding to the target business in the historical transaction information is empty;

[0119] When the query result is that the target ticket is empty, it is determined that the object belongs to the target object.

[0120] In some embodiments of the present application, the method further comprises:

[0121] When the query result is that the target bill is not empty, determining whether the target bill contains an original transaction number;

[0122] When the original transaction number does not exist in the target note, it is determined that the object belongs to the target object.

[0123] In some embodiments of the present application, the method further comprises:

[0124] When the original transaction number exists in the target note, the original transaction number is used to determine whether the object belongs to the target object.

[0125] In some embodiments of the present application, determining whether the object belongs to the target object by using the original transaction number includes:

[0126] Calling the query interface of the payment system to query whether the validity status of the original transaction number is a predetermined value;

[0127] When the valid state returned by the query interface is a predetermined value, it is determined that the object belongs to the target object.

[0128] In some embodiments of the present application, the method also includes: when the original transaction number does not exist in the target note, sending a query request for the object to the server, wherein the query request is used to query whether the object meets a preset condition; receiving a query result returned by the server in response to the query request; and when the query result is that the object meets the preset condition, determining that the object belongs to the target object.

[0129] In some embodiments of the present application, displaying a preset payment option includes: determining the identity information of the target object, sending the identity information to the payment system, so that the payment system adds the identity information to the payment request to obtain the preset payment option; receiving the preset payment option sent by the payment system and displaying it.

[0130] The present application also provides a computer-readable storage medium on which a computer program is stored. When the computer program is executed by a processor, the payment method provided by any one of the above method embodiments is implemented, including:

[0131] When a payment occurs, obtain the historical transaction information of the object in the payment system;

[0132] determining whether the object belongs to a target object based on the historical transaction information;

[0133] When the object belongs to the target object, displaying a preset payment option;

[0134] When a trigger operation for the preset payment option is received, the payment system is called to initiate payment.

[0135] In some embodiments of the present application, obtaining historical transaction information of an object in a payment system includes:

[0136] Querying the target bill corresponding to the target business in the historical transaction information of the object through the payment system;

[0137] The determining whether the object belongs to a target object based on the historical transaction information includes:

[0138] Determining whether the object belongs to the target object according to whether the target bill corresponding to the target business in the historical transaction information is empty;

[0139] When the query result is that the target ticket is empty, it is determined that the object belongs to the target object.

[0140] In some embodiments of the present application, the method further comprises:

[0141] When the query result is that the target bill is not empty, determining whether the target bill contains an original transaction number;

[0142] When the original transaction number does not exist in the target note, it is determined that the object belongs to the target object.

[0143] In some embodiments of the present application, the method further comprises:

[0144] When the original transaction number exists in the target note, the original transaction number is used to determine whether the object belongs to the target object.

[0145] In some embodiments of the present application, determining whether the object belongs to the target object by using the original transaction number includes:

[0146] Calling the query interface of the payment system to query whether the validity status of the original transaction number is a predetermined value;

[0147] When the valid state returned by the query interface is a predetermined value, it is determined that the object belongs to the target object.

[0148] In some embodiments of the present application, the method further comprises:

[0149] When the original transaction number does not exist in the target bill, sending a query request for the object to the server, wherein the query request is used to query whether the object meets a preset condition; receiving a query result returned by the server in response to the query request;

[0150] When the query result indicates that the object meets a preset condition, it is determined that the object belongs to a target object.

[0151] In some embodiments of the present application, preset payment options are displayed, including:

[0152] Determine the identity information of the target object, and send the identity information to the payment system, so that the payment system adds the identity information to the payment request to obtain a preset payment option;

[0153] Receive and display the preset payment options sent by the payment system.

[0154] The device embodiments described above are merely illustrative, wherein the units described as separate components may or may not be physically separated, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to achieve the purpose of the solution of this embodiment.

[0155] Through the description of the above implementation methods, those skilled in the art can clearly understand that each implementation method can be implemented by means of software plus a general hardware platform, and of course, by hardware. Based on this understanding, the above technical solution is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, a disk, an optical disk, etc., including a number of instructions for a computer device (which can be a personal computer, a server, or a network device, etc.) to execute the methods described in each embodiment or some parts of the embodiments.

[0156] It should be understood that the terms used herein are only for the purpose of describing specific example embodiments and are not intended to be limiting. Unless the context clearly indicates otherwise, the singular forms "one", "an" and "said" as used herein may also be meant to include plural forms. The terms "include", "comprise", "contain", and "have" are inclusive, and therefore specify the existence of stated features, steps, operations, elements and / or parts, but do not exclude the existence or addition of one or more other features, steps, operations, elements, parts, and / or combinations thereof. The method steps, processes, and operations described herein are not interpreted as necessarily requiring them to be performed in the specific order described or illustrated, unless the execution order is clearly indicated. It should also be understood that additional or alternative steps may be used.

[0157] The foregoing is merely a specific embodiment of the present invention, which enables those skilled in the art to understand or implement the present invention. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present invention. Therefore, the present invention will not be limited to the embodiments shown herein, but rather to the widest scope consistent with the principles and novel features claimed herein.

Claims

1. A payment method, characterized in that: include: When a payment occurs, obtain the historical transaction information of the object in the payment system; determining whether the object belongs to a target object based on the historical transaction information; When the object belongs to the target object, displaying a preset payment option; When a trigger operation for the preset payment option is received, the payment system is called to initiate payment.

2. The method according to claim 1, characterized in that The acquisition of historical transaction information of the object in the payment system includes: Querying the target bill corresponding to the target business in the historical transaction information of the object through the payment system; The determining whether the object belongs to a target object based on the historical transaction information includes: Determining whether the object belongs to the target object according to whether the target bill corresponding to the target business in the historical transaction information is empty; When the query result is that the target ticket is empty, it is determined that the object belongs to the target object.

3. The method according to claim 2, characterized in that The method further comprises: When the query result is that the target bill is not empty, determining whether the target bill contains an original transaction number; When the original transaction number does not exist in the target note, it is determined that the object belongs to the target object.

4. The method according to claim 3, characterized in that: The method further comprises: When the original transaction number exists in the target note, the original transaction number is used to determine whether the object belongs to the target object.

5. The method according to claim 4, characterized in that The determining whether the object belongs to the target object by using the original transaction number includes: Calling the query interface of the payment system to query whether the validity status of the original transaction number is a predetermined value; When the valid state returned by the query interface is a predetermined value, it is determined that the object belongs to the target object.

6. The method according to claim 3, characterized in that The method further comprises: When the original transaction number does not exist in the target bill, sending a query request for the object to the server, wherein the query request is used to query whether the object meets a preset condition; receiving a query result returned by the server in response to the query request; When the query result indicates that the object meets a preset condition, it is determined that the object belongs to a target object.

7. The method according to claim 1, characterized in that The display of preset payment options includes: Determine the identity information of the target object, and send the identity information to the payment system, so that the payment system adds the identity information to the payment request to obtain a preset payment option; Receive and display the preset payment options sent by the payment system.

8. A payment system, characterized in that: include: The information acquisition module is used to obtain the historical transaction information of the object in the payment system when the payment behavior occurs; A target object determination module, configured to determine whether the object belongs to a target object based on the historical transaction information; a payment display module, for displaying preset payment options when the object belongs to a target object; The payment execution module is used to call the payment system to initiate payment when receiving a trigger operation for the preset payment option.

9. A computer device: at least one communication interface; at least one bus connected to the at least one communication interface; at least one processor connected to the at least one bus; at least one memory connected to the at least one bus, wherein: The processor is configured to execute the payment method according to any one of claims 1 to 7.

10. A computer storage medium storing computer executable instructions, wherein the computer executable instructions are used to execute the payment method according to any one of claims 1 to 7.

Images