Payment service processing method and device, equipment and medium

Abstract

The embodiment of the invention discloses a payment service processing method and device, equipment and a medium. The scheme comprises the following steps: a first device obtains label information used for triggering a payment service; judging whether the source of the label information meets a preset condition or not to obtain a judgment result; the preset condition comprises at least one of a first preset condition and a second preset condition; the first preset condition is that the label information is obtained through an NFC communication mode; the second preset condition is that the first equipment has an NFC communication function; and if the judgment result shows that the source of the label information does not meet the preset condition, terminating execution of the processing flow of the payment service.

Description

[0001] This application is a divisional application of "A method, device, equipment and medium for processing payment services (application date: August 1, 2024, application number: 202411055546.7)". Technical Field

[0002] The present application relates to the field of computer technology, and in particular to a payment service processing method, device, equipment and medium. Background Art

[0003] With the development of computer technology, more and more businesses can be processed through mobile terminals, such as online payment, scanning code to travel, etc. In recent years, NFC technology has also been widely used in payment services due to its low cost and convenience, such as taking public transportation by swiping NFC cards. Therefore, how to improve the security of payment is a technical problem that needs to be solved urgently. Summary of the invention

[0004] The embodiments of this specification provide a payment service processing method, device, equipment and medium to solve the problem of payment risk in the existing payment service processing method.

[0005] To solve the above technical problems, the embodiments of this specification are implemented as follows:

[0006] The embodiment of this specification provides a method for processing a payment service, including:

[0007] The first device obtains tag information for triggering a payment service;

[0008] Determine whether the source of the tag information meets a preset condition, and obtain a determination result; the preset condition includes at least one of a first preset condition and a second preset condition; the first preset condition is that the tag information is obtained through NFC communication; the second preset condition is that the first device has an NFC communication function;

[0009] If the judgment result indicates that the source of the tag information does not meet the preset condition, the processing flow of executing the payment service is terminated.

[0010] The embodiment of this specification provides a method for processing a payment service, including:

[0011] Obtaining a payment processing request sent by the first device, where the payment processing request is generated by the first device based on the acquired tag information for triggering the payment service;

[0012] Determine whether the payment processing request satisfies a trust condition and obtain a determination result; the trust condition includes at least one of a first trust condition and a second trust condition; the first trust condition is that the payment processing request is a request obtained within the validity period of the tag information, and the second trust condition is that the distance between the device sending the payment processing request and the second device for storing the tag information is less than or equal to a preset distance;

[0013] If the judgment result indicates that the payment processing request does not meet the trust condition, the processing flow of the payment service corresponding to the payment processing request is terminated.

[0014] The embodiment of this specification provides a payment service processing device, including:

[0015] A tag information acquisition module, used to acquire tag information used to trigger payment services;

[0016] A preset condition judgment module, used to judge whether the source of the tag information meets the preset condition and obtain a judgment result; the preset condition includes at least one of a first preset condition and a second preset condition; the first preset condition is that the tag information is obtained through NFC communication; the second preset condition is that the first device has NFC communication function;

[0017] The processing flow termination module is used to terminate the processing flow of the payment service if the judgment result indicates that the source of the tag information does not meet the preset condition.

[0018] The embodiment of this specification provides a payment service processing device, including:

[0019] A payment processing request acquisition module, used to acquire a payment processing request sent by a first device, wherein the payment processing request is generated by the first device based on acquired tag information for triggering a payment service;

[0020] a trusted condition judgment module, used to judge whether the payment processing request satisfies a trusted condition and obtain a judgment result; the trusted condition includes at least one of a first trusted condition and a second trusted condition; the first trusted condition is that the payment processing request is a request obtained within the validity period of the tag information, and the second trusted condition is that the distance between the device sending the payment processing request and the second device for storing the tag information is less than or equal to a preset distance;

[0021] The processing flow termination module is used to terminate the processing flow of the payment service corresponding to the payment processing request if the judgment result indicates that the payment processing request does not meet the trust condition.

[0022] The embodiment of this specification provides a payment service processing device, including:

[0023] at least one processor; and,

[0024] a memory communicatively connected to the at least one processor; wherein,

[0025] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute a method for processing a payment service.

[0026] The embodiments of the present specification provide a computer-readable medium on which computer-readable instructions are stored. The computer-readable instructions can be executed by a processor to implement a method for processing a payment service.

[0027] At least one embodiment in the present specification can achieve the following beneficial effects: obtaining tag information for triggering a payment service through a first device, and judging whether the source of the tag information meets a preset condition based on the tag information; if the source of the tag information does not meet the preset condition, it can be further determined that there is a risk in the current transaction, and the first device may not send a payment service processing request to the server, and terminate the payment service processing flow, thereby avoiding the risk of user account funds being defrauded or misappropriated, and improving the security of the payment service. BRIEF DESCRIPTION OF THE DRAWINGS

[0028] In order to more clearly illustrate the technical solutions in the embodiments of this specification or the prior art, the drawings required for use in the embodiments or the prior art description are briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative labor.

[0029] Figure 1 This is a schematic diagram of an application scenario of a payment service processing method provided in an embodiment of this specification;

[0030] Figure 2 It is a flowchart of a payment service processing method provided in an embodiment of this specification;

[0031] Figure 3 It is a schematic diagram of a processing result page showing a transaction exception provided in an embodiment of this specification;

[0032] Figure 4 It is a flowchart of a payment service processing method provided in an embodiment of this specification;

[0033] Figure 5It is a flow chart of a payment service processing method provided in an embodiment of this specification;

[0034] Figure 6 This specification provides an embodiment corresponding to Figure 2 A schematic diagram of the structure of a payment service processing device;

[0035] Figure 7 This specification provides an embodiment corresponding to Figure 4 A schematic diagram of the structure of a payment service processing device;

[0036] Figure 8 It is a structural diagram of a payment service processing device provided in an embodiment of this specification. DETAILED DESCRIPTION

[0037] In order to make the purpose, technical solutions and advantages of one or more embodiments of this specification clearer, the technical solutions of one or more embodiments of this specification will be clearly and completely described below in combination with the specific embodiments of this specification and the corresponding drawings. Obviously, the described embodiments are only part of the embodiments of this specification, not all of the embodiments. Based on the embodiments in this specification, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of one or more embodiments of this specification.

[0038] NFC is a technology that allows two electronic devices to transfer data wirelessly within a few centimeters. This short-range wireless connection is mainly used in scenarios such as sharing mobile payment information and simplifying device pairing. In payment scenarios based on near-field communication, users can use NFC-enabled devices to make contactless payments. During the payment process, the user's device communicates wirelessly with the merchant terminal via NFC to achieve fast payment. For example, in a bus scenario, the user terminal can be read as an NFC tag by the gate on the bus to complete the payment; or when taking the subway, the user touches the gate on the subway with the user terminal, and the user terminal can be read as an NFC tag or card by the gate on the subway to complete the payment.

[0039] In actual applications, users can use mobile terminals with NFC card reading functions to read the payment link in the merchant device with NFC tags through close contact or contactless methods such as tapping, and complete payment based on the payment link. However, some illegal users may crack the tag information in the NFC tag on the merchant's device to obtain the corresponding payment link, and can package the payment link or directly forward it to the user, tampering with the near-field payment into online payment, inducing the user to click the link to complete the payment, making the funds in the user's account extremely vulnerable to theft or fraud.

[0040] The technical solutions provided by the embodiments of this specification are described in detail below in conjunction with the accompanying drawings.

[0041] In order to solve the defects in the prior art, this solution provides the following embodiments:

[0042] Figure 1 The present invention is a schematic diagram of an application scenario of a payment service processing method provided in an embodiment of this specification.

[0043] like Figure 1 As shown, the scheme may include a first device 1, a server 2, and a second device 3. The first device 1 may be a user terminal device with a function of reading an NFC tag, such as a mobile phone, a tablet, a smart watch, a wearable smart device, a laptop computer, and other mobile user terminal devices. The second device 3 may be a device associated with an NFC tag, and may also be called an NFC device, such as a POS machine, a cash register terminal, and the like. The second device 3 may have an NFC tag built in, or the NFC tag may be set separately from the second device. In actual applications, the first device 1 may obtain the NFC tag information of the second device 3 and trigger a payment process. In actual applications, there may also be some illegal users who maliciously obtain the NFC tag in the second device and send it to the first device in other ways. For example, an illegal user cracks the tag information in the second device and obtains the payment link information contained in the tag information, and packages the payment link information through other devices or directly sends it to the first device. This may cause financial losses or information leakage to the user of the first device. In order to ensure payment security, the first device or the server may also verify the reliability of the source of the tag information obtained by the first device, so that the risk of the funds in the user account being stolen or defrauded can be reduced, thereby improving the security of payment.

[0044] Next, a payment service processing method provided in the embodiment of the specification will be specifically described with reference to the accompanying drawings:

[0045] Figure 2 A flowchart of a method for processing a payment service provided in an embodiment of this specification. From a program perspective, the execution subject of the process may be a program or application client installed on a first device. From a hardware perspective, the execution subject of the process may be a first device. Specifically, it may be a mobile terminal such as a mobile phone, a phone watch, a wearable smart device, and a tablet computer.

[0046] like Figure 2 As shown, the process may include the following steps:

[0047] Step 202: The first device obtains tag information for triggering a payment service.

[0048] In the embodiments of this specification, the first device may be a user mobile terminal device equipped with an Android system, such as a mobile phone, a computer, a smart watch, and other smart wearable devices, etc. It may also be a device with other systems, as long as it can execute the method provided in the embodiments of this specification.

[0049] The first device may have a function of reading an NFC tag, and may serve as a card reader to read tag information in the NFC tag.

[0050] In actual applications, the tag information may be tag information obtained by the first device from the second device through a near field payment method; or it may be tag information sent to the first device through other devices by an illegal user after breaking into the tag information in the NFC device.

[0051] Step 204: Determine whether the source of the tag information meets a preset condition and obtain a determination result.

[0052] Among them, the preset condition includes at least one of a first preset condition and a second preset condition; the first preset condition is that the tag information is obtained through NFC communication; the second preset condition is that the first device has NFC communication function.

[0053] In the embodiments of this specification, it is possible to first determine whether the source of the tag information satisfies the first preset condition. If the source of the tag information satisfies the first preset condition, it is possible to determine whether the source of the tag information satisfies the second preset condition; or first determine whether the source of the tag information satisfies the second preset condition. If the source of the tag information satisfies the second preset condition, it is possible to determine whether the source of the tag information satisfies the first preset condition. It is also possible to only determine whether the source of the tag information satisfies the first preset condition, or only determine whether the source of the tag information satisfies the second preset condition. It is also possible to simultaneously execute the judgment process corresponding to the two preset conditions, and determine whether the source of the tag information is credible based on the two judgment results obtained. It is also possible to terminate the execution of the judgment program corresponding to another preset condition after obtaining the judgment result of one preset condition. For example, after determining that the table tag information is not obtained by NFC communication according to the first preset condition, if the judgment program for the second preset condition has been started but no result has been obtained, the judgment program for the second preset condition can be terminated. The setting of the judgment condition can be determined according to actual needs, and no specific limitation is made here.

[0054] In the embodiments of this specification, it is possible to further determine whether the tag information is credible by determining whether the source of the tag information meets the preset conditions. The first device can provide a storage space for the target application, so that the target application can store some information that only the target application can access in the space. The target application can compare the storage information in the space with the tag information to determine whether the tag information is credible, and then determine whether the tag information is obtained through NFC communication, or determine whether the first device has NFC function. The first device can determine whether the transaction link corresponding to the tag information is risky based on the judgment result, thereby preventing other applications other than the target application from completing payment directly through the link.

[0055] Step 206: If the judgment result indicates that the source of the tag information does not meet the preset condition, the processing flow of executing the payment service is terminated.

[0056] In the embodiments of this specification, if the source of the tag information does not meet the preset conditions, it may be that the source of the tag information does not meet the first preset condition; it may also be that the source of the tag information does not meet the second preset condition; it may also be that the source of the tag information does not meet the first preset condition and the second preset condition, and specific judgment criteria may be set according to actual business needs. If the source of the tag information does not meet the preset conditions, it may indicate that the tag information obtained by the first device is unreliable, and further it may be determined that the payment transaction corresponding to the tag information is risky and unsafe, and the first device may not process the payment transaction.

[0057] Terminating the payment service processing flow may mean that the first device does not send a payment service processing request to the server and directly does not execute the payment service processing flow. In practical applications, terminating the payment service processing flow may also mean that after the first device sends a payment service processing request to the server, if it detects that the tag information is unreliable, it sends a payment service processing request to the server, so that the server terminates the payment service processing flow being executed.

[0058] It should be understood that the order of some steps in the methods described in one or more embodiments of this specification can be interchanged according to actual needs, or some steps can be omitted or deleted.

[0059] Figure 2 In the method, the tag information for triggering the payment service is obtained through the first device, and whether the source of the tag information meets the preset conditions is determined based on the tag information. If the source of the tag information does not meet the preset conditions, it can be determined that there is a risk in the current transaction. The first device may not send a payment service processing request to the server, terminate the payment service processing flow, avoid the risk of user account funds being defrauded or stolen, and improve the security of the payment service.

[0060] based on Figure 2 The method, the examples of this specification also provide some specific implementation plans of the method, which are described below.

[0061] As an implementation mode, optionally, the method described in the embodiments of this specification may further include:

[0062] If the judgment result indicates that the source of the tag information meets the preset conditions, a payment processing request is sent to the server; the server can execute the payment service processing flow based on the payment processing request.

[0063] The source of the tag information satisfies the preset conditions, which may be that the source of the tag information satisfies the first preset condition; or the source of the tag information satisfies the second preset condition; or the source of the tag information satisfies both the first preset condition and the second preset condition. Specifically, the situation in which the preset conditions are satisfied can be determined based on the set judgment conditions.

[0064] In the embodiments of this specification, the source of the tag information meets the preset conditions, which can indicate that the tag information is credible; the credible tag information can indicate that the first device obtains the tag information by being close to or approaching the device providing the tag information, for example, the user places the first device and the second device close together to obtain the tag information of the NFC tag of the second device.

[0065] The payment business processing flow may represent a process for processing a payment processing request, such as a server reading information carried in a payment processing request, deducting a transaction amount from a corresponding user account, and transferring the deducted transaction amount to a payee account.

[0066] The payment processing request may be a request generated by the first device based on the tag information after the first device determines that the tag information is credible.

[0067] In the embodiment of the present specification, the first device may also start a target application in the first device based on the tag information. The target application may generate a payment processing request based on the tag information after determining that the tag information is credible according to a preset condition.

[0068] The tag information may contain identification information related to the target application, such as the name identification of the target application, etc. The first device may call up the target application through the identification information. The target application may be a terminal application APP with a payment function.

[0069] In actual applications, after the first device receives the tag information, if the first device is displaying other pages, it can jump from other pages to the target application page, switch other pages to background operation or close them, and switch the target application page to the front display; or, superimpose the target application page on the upper layer of other pages for display. Other pages can be the home page, menu page, system page or other application page of the first device. It is understandable that if the first device is off screen, the first device can directly display the target application page according to the tag information, or after the first device is unlocked, display the target application page according to the tag information.

[0070] In actual applications, the first device can receive the execution result information of the payment business processing flow fed back by the server, and can also display the payment result page based on the obtained execution result information. The execution result information may include results such as successful payment, failed payment, or abnormal payment. The format and content of the display page corresponding to the execution result can be set according to actual needs, and are not specifically limited here. For example, if the execution result is a successful payment, the transaction amount information can be displayed on the page; if the execution result is a failed payment, the transaction amount information and the transaction failure reason information can be displayed on the page, or only the transaction failure reason information can be displayed, etc.

[0071] As an implementation manner, whether the tag information is credible can be determined by determining whether the tag information is obtained through NFC communication. Optionally, in the embodiment of this specification, determining whether the source of the tag information meets the first preset condition can specifically include:

[0072] Determine whether the trusted memory of the first device contains verification information matching the tag information; the trusted memory is a trusted memory for storing verification information of information obtained by the first device through near field communication;

[0073] If the trusted memory does not include verification information matching the tag information, it is determined that the source of the tag information does not meet the first preset condition.

[0074] If the trusted memory includes verification information that matches the tag information, it is determined that the source of the tag information meets the first preset condition.

[0075] The trusted memory can be a hardware-isolated area in the first device, used to store sensitive information, such as encryption keys and authentication data. The trusted memory can provide a more secure environment than a conventional operating system, allowing only target applications to access data in the trusted memory, preventing malware from accessing data in the trusted memory. After the first device obtains information transmitted through the NFC channel, it can store the information in the trusted memory as verification information; or it can store the information obtained after processing the information in a preset data processing format in the trusted memory as verification information, so that the verification information in the trusted memory can be used to verify the credibility of the source of the tag information obtained by the first device.

[0076] In actual applications, after receiving the tag information, the first device can wake up the target application based on the target application identification information contained in the tag information. The target application can access the trusted memory and verify the tag information based on the verification information obtained from the trusted memory. If the target application determines that the tag information does not contain the verification information in the trusted memory, or there is no verification information consistent with the tag information in the trusted memory, it can be determined that the source of the tag information does not meet the first preset condition, so as to determine that the tag information is unreliable and the current transaction is risky. The first device may not access the server, or request the server to terminate the payment service processing flow to ensure the security of the user account funds.

[0077] If the target application determines that the tag information contains verification information in the trusted memory, or verification information consistent with the tag exists in the trusted memory, it can be determined that the source of the tag information meets the first preset condition, and then it can be determined that the tag information is trustworthy. The first device can access the server and request the server to execute the business processing flow.

[0078] As an implementation manner, the verification information in the trusted memory may be information obtained in a preset format. Optionally, the step of determining whether the trusted memory of the first device contains verification information matching the tag information in the embodiments of this specification may specifically include:

[0079] Processing the tag information according to preset data rules to obtain target verification information;

[0080] Determine whether the trusted memory of the first device contains the target verification information; the verification information stored in the trusted memory is obtained by processing the information obtained by the first device through near field communication according to the preset data rule.

[0081] The preset data rules in the embodiments of this specification may include the NFC Data Exchange Format (NDEF), and may also include data in other formats, such as XML format, JOIN format, etc., which are not specifically limited here. The target verification information can be the target NDEF tag obtained after processing the tag information or part of the tag information according to the NDEF rules. NDEF is used to structure and encode the information in the NFC tag so that different NFC devices can understand and use this information.

[0082] In actual applications, it is determined whether the trusted memory of the first device contains the target verification information. Specifically, the target application in the first device can be matched in the trusted memory based on the target NDEF tag. If the match is successful, it can be indicated that the trusted memory contains an NDEF tag that is consistent with the target NDEF tag, which can indicate that the tag information is trustworthy and is obtained by the first device through NFC communication; if the match is unsuccessful, the trusted memory does not contain an NDEF tag that is consistent with the target NDEF tag, which can indicate that the tag information is untrustworthy and is obtained by other methods other than NFC communication. For payment scenarios based on near-field communication, the tag information is risky and the payment service processing flow can be terminated.

[0083] In the embodiment of this specification, if the trusted memory contains verification information that matches the tag information, it can be determined that the source of the tag information meets the first preset condition, and thus it can be indicated that the tag information is trustworthy. The first device can generate a payment processing request based on the tag information and send the payment processing request to the server to request the server to execute the payment service.

[0084] If the trusted memory does not contain verification information that matches the tag information, it can be determined that the source of the tag information does not meet the first preset condition, which can further indicate that the tag information is unreliable. The first device may not access the server and terminate the payment service processing flow.

[0085] As an implementation mode, optionally, the method described in the embodiments of this specification may further include:

[0086] The verification information in the trusted memory that matches the tag information is deleted.

[0087] In actual applications, in order to further ensure the security of payment, the verification information matching the tag information in the trusted memory may also be deleted to avoid the problem that an illegal user obtains the tag information and sends it to the first device through other channels to trigger the payment process.

[0088] As another implementation, when generating verification information, the first device may set a verification validity period for the verification information. When the storage time of the verification information in the trusted memory exceeds the verification validity period, it can be determined that the verification information has expired and the expired verification information can be deleted.

[0089] As an implementation manner, whether the tag information is credible may also be determined by determining whether the first device that obtains the tag information is in a preset whitelist. Optionally, in the embodiment of this specification, determining whether the source of the tag information meets the second preset condition may specifically include:

[0090] Acquire system identification information of the first device;

[0091] Determine whether the system identification information is in a preset whitelist; the preset whitelist includes system identification information of multiple device systems with near field communication functions;

[0092] If the system identification information is not in the preset whitelist, it is determined that the source of the tag information does not meet the second preset condition.

[0093] If the system identification information is in the preset whitelist, it is determined that the source of the tag information meets the second preset condition.

[0094] The preset whitelist may include identification information of devices with NFC functions, such as device name, device ID, etc., or system identification of the device system, such as system package name, package signature, etc. The preset whitelist may also be stored in the trusted memory of the target application, or in other memory spaces. The system identification information in the preset whitelist may be provided to the target application by the device manufacturer or system developer, or may be obtained by the target application from the user's mobile terminal information after the user grants the target application permission to obtain system information.

[0095] In actual applications, a blacklist can also be preset. If the system identification information is in the preset blacklist, it is determined that the source of the tag information does not meet the second preset condition; if the system identification information is not in the preset blacklist, it is determined that the source of the tag information meets the second preset condition. The device corresponding to the system identification information in the preset blacklist does not contain a module related to the NFC tag in hardware, or does not have NFC near-field communication function in software. The method for obtaining the system identification information in the preset blacklist is the same as the method for obtaining the preset whitelist.

[0096] In the embodiments of this specification, the system identification information may include system package name information and package signature information; it may also include information such as the terminal model or name of the first device. The package name information is used to uniquely identify the application or service. In different Android versions, the same application or service should also use the same package name to ensure compatibility and consistency. For example, the package name of payment application 1 in Android version 1 and Android version 2 is package name 1, and the package names of payment application 1 and payment application 2 in Android version 1 are package name 1 and package name 2 respectively. The package signature can be used to verify the source and integrity of the application to ensure that the application has not been tampered with or comes from an untrusted source.

[0097] In actual applications, after obtaining the tag information, the first device can wake up the target application, and the target application can obtain the system identification information of the first device. The target application can search from the preset whitelist whether there is target system identification information that is consistent with the system identification information of the first device; if it exists, it can be determined that the source of the tag information meets the second preset condition, and then it can be determined that the tag information is credible, and the client of the target application can generate a payment processing request based on the tag information and send it to the server; if it does not exist, it can be determined that the source of the tag information does not meet the second preset condition, and then it can be determined that the tag information is untrustworthy, and the client of the target application can terminate the processing flow of the payment business. Specifically, the credibility of the source of the tag information can be determined based on at least one of the package name information and the package signature information. For example, it can be determined first whether the trusted memory contains the package name information of the first device. If the trusted memory does not contain the package name information of the first device, it can be determined that the source of the tag information does not meet the second preset condition; if the trusted memory contains the package name information of the first device, it can be determined whether the trusted memory contains the package signature information of the first device to determine the credibility of the tag information. The judgment order of the package name information and the package signature information can be set based on actual needs. The credibility of the tag information may also be determined only by judging the package name information or the package signature information.

[0098] Optionally, the server described in the embodiments of this specification can also execute a processing flow of a corresponding payment service according to the positional relationship between the first device and the second device for storing the tag information.

[0099] In the embodiments of this specification, the second device may be a device associated with an NFC tag, such as a device with a built-in NFC tag, or a device connected to an NFC card by wireless or wired means; the second device here may represent a safe, legal and compliant device. The server may obtain the first location information of the first device and the second location information of the second device, and then determine the distance between the first device and the second device, and determine whether to execute the payment service processing flow according to the distance between the two.

[0100] The tag information can be generated by the server and sent to the second device. For example, in a payment method scenario based on near field communication, the merchant's cash register system can be connected to the second device. After the cashier confirms the payment through the merchant's cash register system, the merchant's cash register system requests the server to generate tag information; or after the tag information is read, the second device requests the server to generate tag information; or the server actively sends the tag information to the second device. There is no specific limitation here.

[0101] In actual applications, the first device can also determine the credibility of the tag information through the positions of the first device and the second device. The method in the embodiments of this specification can also determine whether the tag information is credible by determining whether the source of the tag information meets a fourth preset condition. The fourth preset condition can be used to indicate that the distance between the first device and the second device meets a distance threshold.

[0102] Specifically, the first device sends a location acquisition request to the server. The server can determine the second location information of the second device based on the tag information contained in the location acquisition request or the identification information corresponding to the tag information and feed it back to the first device. The first device can determine whether the distance between the first device and the second device meets the distance threshold based on its own first location information and the second location information fed back by the server. If the distance between the first device and the second device meets the distance threshold, it can be determined that the tag information is credible, and the first device can send a payment processing request to the server or display a payment confirmation page. If the distance between the first device and the second device does not meet the distance threshold, it can be determined that the tag information is not sent by near-field communication, the tag information is unreliable, and the first device may not access the server and generate a payment processing request.

[0103] As an implementation method, after obtaining the second location information, the server can directly determine the distance value between the first device and the second device and feed it back to the first device. The first device determines the credibility of the tag information by judging whether the fed-back distance value meets the distance threshold. The first location information and the second location information can be location information obtained based on mobile location services (Location-Based Services, LBS), or location information obtained through positioning systems such as the Global Positioning System (GPS) and the BeiDou Navigation Satellite System (BDS), or the location information of the device can be obtained through the WIFI or Bluetooth connection of the device.

[0104] As an implementation, the reliability of the tag information can also be determined by the preset range of the first device. Optionally, the preset condition in the embodiment of this specification also includes a third preset condition; the third preset condition is that there are other devices within the near field communication range of the first device.

[0105] The near field communication range may include a Bluetooth connection communication range, an NFC communication range, a WIFI connection communication range, and other near field communication ranges.

[0106] As an implementation manner, determining whether the source of the tag information satisfies a third preset condition may specifically include:

[0107] Determine whether there are other Bluetooth devices within the Bluetooth range of the first device;

[0108] If there is no other Bluetooth device within the Bluetooth range of the first device, it is determined that the tag information does not meet the third preset condition.

[0109] If there are no other Bluetooth devices within the Bluetooth range of the first device, it may indicate that there are no other near-field communication devices around the first device. In this way, it can be determined that the tag information obtained by the first device is not obtained through near-field communication. In the payment scenario using a near-field communication-based payment method, the tag information is risky and the payment processing request may not be sent.

[0110] If there are other Bluetooth devices within the Bluetooth range of the first device, it is determined that the tag information meets the third preset condition and the tag information is credible.

[0111] In order to further ensure the security of payment, verification can also be performed through the server. As an implementation method, if there are other Bluetooth devices within the Bluetooth range of the first device, the information of other Bluetooth devices can be sent to the server. After receiving the information of other Bluetooth devices sent by the first device, the server determines the Bluetooth device of the second device according to the tag information, and determines whether the other Bluetooth devices contain the Bluetooth device of the second device. The judgment result is sent to the first device. The first device can judge whether the source of the tag information meets the third preset condition based on the feedback judgment result to determine the credibility of the tag information. If the feedback judgment result is that the other Bluetooth devices contain the Bluetooth device of the second device, the first device determines that the source of the tag information meets the third preset condition and determines that the tag information is credible; if the feedback judgment result is that the other Bluetooth devices do not contain the Bluetooth device of the second device, the first device determines that the source of the tag information does not meet the third preset condition, determines that the tag information is unreliable, and does not need to access the server.

[0112] As an implementation mode, the first device may also directly include information of other Bluetooth devices within the range of the first device in a payment processing request and send it to the server. The server determines whether to execute the processing flow of the payment service based on the information of other Bluetooth devices.

[0113] The first device can also determine whether to send the payment processing flow to the server by determining whether the first device has established a Bluetooth connection with another device. The first device has established a Bluetooth connection, which can indicate that the source of the tag information is credible, and can send a payment processing request containing the device information of the Bluetooth connection to the server. The server can determine whether to execute the payment service processing flow by determining whether the device that has established a Bluetooth connection with the first device is the second device.

[0114] Optionally, the method described in the embodiments of this specification may also include:

[0115] Displays a prompt message indicating transaction abnormality.

[0116] In the embodiments of this specification, the first device can locally generate prompt information indicating transaction abnormality based on the obtained judgment result, or obtain prompt information indicating transaction abnormality provided by the server. The prompt information indicating transaction abnormality may include information prompting the user of transaction abnormality, information on the cause of transaction abnormality, prompt information prompting the user to use near field communication payment method, etc.

[0117] In actual applications, the first device may also display a prompt message indicating that the transaction is successful; it may also display a prompt message prompting the user to confirm the transaction; it may also display a prompt message for starting the target payment application, and so on.

[0118] In order to clearly explain the display page of the prompt information, Figure 3 This is a schematic diagram of a page showing the results of a transaction exception provided in an embodiment of this specification. Figure 3 As shown, the page 300 may include a payment page 302, which may include information such as the payment amount, and a prompt message 304 may be displayed on the upper layer of the payment page to prompt the user that the current transaction is abnormal. The prompt message may also include prompt information prompting the user to complete the payment via NFC, such as "Transaction abnormality, please touch via NFC to complete the payment".

[0119] like Figure 3 As shown, the page may also include a control 306 for closing the page, such as an "OK" control. After the user clicks the control, the page may be closed or redirected to other pages, such as the home page of the first device, the home page of the payment APP, etc. It is understandable that Figure 3This is only for illustrative purposes, and the display page can also be laid out in other forms, which are not specifically limited here. For example, only the prompt information can be displayed without displaying the payment page.

[0120] In this specification, the server can also be used to verify the credibility of the tag information. Figure 4 The flowchart of a payment service processing method provided in the embodiment of this specification is as follows. From the program perspective, the execution subject of the process can be a program installed on an application server or an application client.

[0121] like Figure 4 As shown, the process may include the following steps:

[0122] Step 402: Obtain a payment processing request sent by the first device.

[0123] The payment processing request is generated by the first device based on the acquired tag information for triggering the payment service.

[0124] In the embodiments of this specification, the first device may be a user terminal device with a function of reading NFC tags, for example, a mobile user terminal device such as a mobile phone, a tablet, a smart watch, a wearable smart device, and a laptop computer. The tag information may be generated by a server; the tag information may contain a payment-related identifier, which may be a preset character; or it may be identification information of a payment application or other information used to identify a payment service, which is not specifically limited here. The payment processing request may include identification information of a method of triggering a payment request, such as identification information indicating a payment method of face-to-face payment, such as identification information of NFC communication, or identification information of payment by scanning a code image such as a payment code or a receipt code, etc.

[0125] Step 404: Determine whether the payment processing request satisfies a trusted condition and obtain a determination result; the trusted condition includes at least one of a first trusted condition and a second trusted condition; the first trusted condition is that the payment processing request is obtained within the validity period of the tag information, and the second trusted condition is that the distance between the device sending the payment processing request and the second device used to store the tag information is less than or equal to a preset distance.

[0126] To determine whether a payment processing request satisfies a trustworthy condition, it may be to first determine whether the payment processing request satisfies a first trustworthy condition, and after the first trustworthy condition is satisfied, determine whether the payment processing request satisfies a second trustworthy condition; it may also be to first determine whether the payment processing request satisfies a second trustworthy condition, and after the second trustworthy condition is satisfied, determine whether the payment processing request satisfies the first trustworthy condition; it may also be to only determine whether the payment processing request satisfies the first trustworthy condition; it may also be to only determine whether the payment processing request satisfies the second trustworthy condition; it may be to simultaneously execute the judgment processes corresponding to the two trustworthy conditions, and determine whether the payment processing request is trustworthy based on the two judgment results obtained. It is also possible to terminate the execution of the judgment program corresponding to another trustworthy condition after obtaining the judgment result of one trustworthy condition. For example, after determining that the payment processing request is not a request obtained within the validity period of the tag information according to the first trustworthy condition, if the judgment program for the second trustworthy condition has been started but no result has been obtained, the execution of the judgment program for the second trustworthy condition may be terminated. The setting of the judgment condition may be determined according to actual needs, and no specific limitation is made here.

[0127] In the embodiment of the present specification, the validity period may be a valid time period or a valid duration set by the server for the tag information when the tag information is generated.

[0128] The second device may be a device associated with an NFC tag, such as a POS machine, a cash register terminal, etc. The second device may have an NFC tag built in, or the NFC tag may be set separately from the second device. The payment processing request may include the location information of the first device that sends the payment processing request; or it may be obtained by the server sending a location acquisition request to the first device after receiving the payment processing request. The location information of the second device may be stored in the server, or sent by the second device to the server.

[0129] Step 406: If the judgment result indicates that the payment processing request does not meet the trust condition, the processing flow of the payment service corresponding to the payment processing request is terminated.

[0130] In the embodiment of this specification, the payment processing request fails to meet the trusted condition, which may mean that the payment processing request is not obtained within the validity period of the tag information, or that the distance between the device sending the payment processing request and the second device for storing the tag information is greater than a preset distance, or that both the validity period and the preset distance conditions are not met.

[0131] The payment processing request satisfies the trust condition, which may mean that the payment processing request is a request obtained within the validity period of the tag information; it may also mean that the distance between the device sending the payment processing request and the second device used to store the tag information is less than or equal to the preset distance; it may also mean that the tag information is within the validity period and the distance is less than or equal to the preset distance.

[0132] As an implementation mode, optionally, the method described in the embodiments of this specification may further include:

[0133] If the judgment result indicates that the payment processing request satisfies the trust condition, the processing flow of the payment service corresponding to the payment processing request is executed and the processing result information is fed back to the first device.

[0134] As an implementation manner, optionally, the payment processing request in the embodiment of this specification includes identification information of the tag information; and determining whether the payment processing request satisfies the first trust condition may specifically include:

[0135] Based on the identification information, determining the validity period of the tag information;

[0136] Determining whether the acquisition time of the payment processing request is within the validity period;

[0137] If the acquisition time of the payment processing request is not within the validity period, it is determined that the payment processing request does not meet the first trust condition.

[0138] The tag information may be a string that complies with a preset rule, for example, a link, such as a URL link. The tag information may include order identification information, or may include token information generated according to the tag information, etc., which is not specifically limited here. The identification information may be part or all of the information in the tag information, such as the token information included in the tag information.

[0139] The validity period can indicate the validity period or time period of the tag information. If the validity period indicates the validity period of the tag information, the relationship between the time difference between the acquisition time and the generation time and the validity period can be determined. If the time difference is greater than the validity period, it can be determined that the acquisition time is not within the validity period, and the payment processing request does not meet the first trust condition; if the validity period indicates the validity period of the tag information, it can be determined whether the acquisition time is within the time period between the generation time and the end time of the validity period. If the acquisition time is not within the time period between the generation time and the end time of the validity period, it can be determined that the acquisition time is not within the validity period, and the payment processing request does not meet the first trust condition, and the server terminates the payment service processing flow.

[0140] If the time difference is less than or equal to the valid period, or the acquisition time is within the time period between the generation time and the end time of the valid period, it can be determined that the acquisition time is within the valid period, and the payment processing request meets the first trust condition, and the server can continue to execute the payment service processing flow.

[0141] As an implementation manner, optionally, the method described in the embodiments of this specification further includes:

[0142] Can generate label information and record the validity period of label information;

[0143] The tag information is sent to the second device.

[0144] The validity period of the tag information can be set by the server, such as when the tag information is generated and the validity period is set; the validity period can represent a valid time period or a valid duration. If the validity period is a time period, the start time of the validity period is the generation time of the tag information generated by the server, and the corresponding end time can be determined based on the generation time and the preset duration of the validity period.

[0145] After receiving the tag information sent by the server, the second device containing the NFC tag can burn the tag information into the NFC tag, and can store the tag information within a preset time, such as 30 minutes, 1 hour, etc. The preset time can represent the validity period of the tag information.

[0146] In actual applications, if the tag information has not been read for a certain period of time or the time exceeds the validity period, the server can determine that the tag information has expired and delete the tag. The server can also determine whether the tag information exists in the trusted tag set. If not, it can indicate that the tag information has expired and has exceeded the validity period, and normal payment can no longer be made based on the tag information. The trusted tag set can represent the collection of valid tag information stored in the server; it can also be a collection of trusted tag information corresponding to the verification information obtained by the target application from the trusted memory and sent to the server.

[0147] In actual applications, after the tag information of the second device is read, or when the tag information of the second device has not been read for more than a preset time, the server can generate new tag information and send it to the second device.

[0148] As an implementation manner, optionally, the method described in the embodiments of this specification further includes:

[0149] Acquire notification information sent by the second device indicating that the tag information has been read;

[0150] Based on the notification information, the validity period of the recorded tag information is changed to a new validity period; the duration of the new validity period is shorter than the validity period of the recorded tag information.

[0151] The notification information may indicate information generated by the second device after the tag information in the second device is read. The reading here can be divided into two situations. One is that the user reads the tag information of the second device through the first device held by the user; the other is that an illegal user reads the tag information of the second device. The original validity period may indicate the default validity period of the server or the set initial validity period, such as 30 minutes, 2 hours, etc.; it may also be the validity period last set. The new validity period indicates a duration or time period shorter than the original validity period, for example, the original validity period of 30 minutes is changed to a shorter time such as 2 minutes, 20 seconds, etc.

[0152] In actual applications, the server can generate tag information and set an original validity period for the tag information; send the tag information to the second device, and within the original validity period, after the tag information of the second device is read, the second device will send a notification message to the server, and after receiving the notification message, the server can set a new validity period for the tag information.

[0153] As an implementation mode, optionally, the method described in the embodiments of this specification may further include:

[0154] If the judgment result indicates that the payment processing request does not meet the trust condition, information indicating that the transaction is abnormal is generated and fed back to the first device.

[0155] If the judgment result indicates that the payment processing request satisfies the trust condition, the payment service processing request is executed, and information indicating the execution result is generated and fed back to the first device.

[0156] In the embodiments of this specification, the payment processing request failing to meet the trust condition may mean that the payment processing request failing to meet the first trust condition; may also mean that the payment processing request failing to meet the second trust condition; may also mean that the payment processing request failing to meet both the first trust condition and the second trust condition.

[0157] The payment processing request satisfies the trust condition, which may mean that the payment processing request satisfies the first trust condition, or may mean that the payment processing request satisfies the second trust condition; or the payment processing request satisfies both the first trust condition and the second trust condition.

[0158] As an implementation manner, optionally, the payment processing request in the embodiment of this specification includes the tag information; the method further includes:

[0159] Based on the tag information, determining a second device for storing the tag information;

[0160] Determining whether the payment processing request satisfies the second trust condition may specifically include:

[0161] Determining whether the distance between the first device and the second device is less than or equal to a preset distance;

[0162] If the distance between the first device and the second device is less than or equal to a preset distance, determining that the payment processing request satisfies the second trust condition;

[0163] If the distance between the first device and the second device is greater than a preset distance, it is determined that the payment processing request does not meet the second trust condition.

[0164] The server may obtain the second location information of the second device after determining the second device, or the second device may send the location information to the server in real time, and the server may also store the second location information of the second device. The first device may carry its own first location information in the payment processing request sent to the server, or the server may obtain the first location information of the first device after obtaining the payment processing request sent by the first device.

[0165] In actual applications, the location information obtained by the server may be the real-time location information of the device or the location information cached by the device.

[0166] The distance may be calculated based on the first location information and the second location information, and may represent the distance between the first device and the second device. The distance may be represented in the form of an absolute value. The preset distance may be the same as the value of the distance threshold in the aforementioned embodiment; the preset distance may represent the maximum distance at which the first device and the second device can perform near field communication. The preset distance may be determined based on the sensing distance of NFC, or based on the historical payment distance in the historical payment data, and is not specifically limited here.

[0167] In the embodiments of this specification, payment services can also be processed by combining the first device with the server. Figure 5 The following is a flow chart of a payment service processing method provided in an embodiment of this specification. Figure 5 As shown, the scheme may specifically include:

[0168] Step 502: The first device obtains tag information for triggering a payment service.

[0169] The tag information obtained by the first device may be obtained by the first device from the second device through NFC communication; or it may be sent to the first device after an illegal device decrypts the tag information of the NFC device. The first device may be an NFC device with an NFC tag or NFC communication function. The tag information may include all or part of the information in the NFC tag of the second device, such as token information, order information, etc.

[0170] Step 504: Determine whether the source of the tag information meets a first preset condition.

[0171] The first preset condition may indicate that the trusted memory of the first device contains verification information that matches the tag information. If the source of the tag information does not meet the first preset condition, step 510 is executed: terminating the processing flow of executing the payment service.

[0172] If the source of the tag information meets the first preset condition, the first device may execute step 506: determining whether the source of the tag information meets the second preset condition.

[0173] The second preset condition may indicate that the system identification information of the first device is in a preset whitelist. If the source of the tag information does not meet the second preset condition, the first device may execute step 510: terminating the processing flow of executing the payment service.

[0174] If the source of the tag information meets the second preset condition, the first device may further execute step 508: determining whether the source of the tag information meets the third preset condition.

[0175] The third preset condition may indicate that there are other devices within the preset range of the first device, specifically, there are other Bluetooth devices within the Bluetooth range of the first device. If the source of the tag information does not meet the third preset condition, step 510 is executed: the payment service processing flow is terminated.

[0176] In actual applications, the first device can determine whether the source of the tag information meets the preset conditions according to one or more of the first preset conditions, the second preset conditions, and the third preset conditions. If the second preset condition is not used to determine whether the trusted source of the tag information meets the preset conditions, the above step 506 can be deleted; if the credibility of the tag information is determined only according to the first preset condition, the above steps 506 and 508 can be deleted.

[0177] Step 512: Send a payment processing request to the server.

[0178] If the source of the tag information meets the preset conditions, the first device can generate a payment processing request based on the tag information, and send the payment processing request to the server so that the server can process based on the payment processing request.

[0179] Step 514: The server obtains the payment processing request sent by the first device.

[0180] The payment processing request in the embodiment of this specification is generated by the first device based on the acquired tag information for triggering the payment service.

[0181] Step 516: Determine whether the payment processing request meets the trust condition.

[0182] The trusted condition may include at least one of a first trusted condition and a second trusted condition. The first trusted condition may indicate that the acquisition time of the payment processing request is within the validity period of the tag information.

[0183] The second trust condition may indicate that the distance between the first device and the second device is less than or equal to a preset distance. The payment processing request may include the tag information obtained by the first device. For details, please refer to the description in the above embodiment, which will not be repeated here.

[0184] If the payment processing request does not meet the trust condition, the server may execute step 518: terminate the payment service processing flow; and may also execute step 520: generate information indicating that the transaction is abnormal.

[0185] The server may send the generated information indicating the transaction abnormality to the first device, and the first device may further execute step 522: the first device displays prompt information indicating the transaction abnormality.

[0186] If the first device is the one that terminates the payment service processing flow, the first device may also locally generate a prompt message indicating a transaction abnormality; if the server is the one that terminates the payment service processing flow, the server may feed back the generated information indicating the transaction abnormality to the first device, and the first device may display a prompt message indicating the transaction abnormality based on the feedback information received from the server.

[0187] If the payment processing request meets the trust condition, the server may execute step 524: the server executes the processing flow of the payment service corresponding to the payment processing request. The server may also execute step 526: generating processing result information of the payment service.

[0188] The server may also feed back the processing result information of the generated payment service to the first device, and the first device may execute step 528: the first device displays the processing result page of the payment service.

[0189] The processing result page can be generated based on the payment service processing result information fed back by the server, and is used to display the payment service processing result to the user. The result page can include two situations, one is the transaction success situation, and the other is the transaction failure situation. The reasons for the transaction failure can be displayed, such as insufficient account balance, unstable network, etc.

[0190] In actual applications, during the time period when the server processes the payment processing request, the first device may display a full-screen payment page or a secure payment page occupying part of the screen. The page may display some promotional information related to the near-field payment method or payment order information, which is not specifically limited here.

[0191] It is understandable that various embodiments of this specification provide a variety of methods for verifying tag information or payment processing requests. In actual applications, one or more methods can be selected for verification, and the execution order of multiple verification methods can also be set according to actual needs.

[0192] The same concepts or features as those in the above embodiments in this embodiment can refer to the description of the above embodiments, which will not be repeated. It should be understood that the order of some steps in the methods described in the embodiments of this specification can be interchanged according to actual needs, or some steps can be omitted or deleted.

[0193] The method provided in the embodiments of this specification can effectively prevent illegal users from using the tag information obtained from the NFC device, such as link information, to perform some harmful actions on them, thereby improving payment security. The server can be a server with payment processing capabilities, specifically a server for processing payment services executed based on near field communication. The tag information can include the domain name information of the server. As an implementation method, the server can process each payment processing request obtained according to the method provided in this specification. As another implementation method, the payment processing request obtained by the server can include a preset string, and the server can process the payment processing request containing the preset string according to the method provided in this specification.

[0194] Through the above method, the first device can determine whether the source of the tag information is credible through at least one of the preset conditions, and then send a payment processing request to the server if the source of the tag information is credible. After receiving the request, the server can determine whether to process the request based on at least one of the trusted conditions, thereby being able to determine whether the payment transaction is abnormal through multiple dimensions and angles, thereby reducing the risk of user account funds being stolen or defrauded, and improving transaction security.

[0195] Based on the same idea, the embodiments of this specification also provide a device corresponding to the above method. Figure 6 The embodiments of this specification provide corresponding to Figure 2 A schematic diagram of the structure of a payment service processing device. Figure 6 As shown, the device may include:

[0196] The tag information acquisition module 602 is used to acquire tag information for triggering a payment service;

[0197] The preset condition judgment module 604 is used to judge whether the source of the tag information meets the preset condition and obtain a judgment result; the preset condition includes at least one of a first preset condition and a second preset condition; the first preset condition is that the tag information is obtained through NFC communication; the second preset condition is that the first device has NFC communication function;

[0198] The processing flow termination module 606 is used to terminate the processing flow of the payment service if the judgment result indicates that the source of the tag information does not meet the preset condition.

[0199] based on Figure 6 The present specification also provides some specific implementation schemes of the method, which are described below.

[0200] Optionally, the device may further include a business process execution module, which may be specifically used to:

[0201] If the judgment result indicates that the source of the tag information meets the preset conditions, a payment processing request is sent to the server; the server can execute the processing flow of the payment service based on the payment processing request.

[0202] Optionally, the preset condition judgment module further includes a first preset condition judgment unit, which can be specifically used to:

[0203] Determine whether the trusted memory of the first device contains verification information matching the tag information; the trusted memory is a trusted memory for storing verification information of information obtained by the first device through near field communication;

[0204] If the trusted memory does not include verification information matching the tag information, it is determined that the source of the tag information does not meet the first preset condition.

[0205] Optionally, the first preset condition judgment unit may further include a label information processing subunit, which may be specifically used to:

[0206] Processing the tag information according to preset data rules to obtain target verification information;

[0207] Determine whether the trusted memory of the first device contains the target verification information; the verification information stored in the trusted memory is obtained by processing the information obtained by the first device through near field communication according to the preset data rule.

[0208] Optionally, the preset data rule includes an NFC data exchange format.

[0209] Optionally, the device can also be used for:

[0210] The verification information in the trusted memory that matches the tag information is deleted.

[0211] Optionally, the preset condition judgment module further includes a second preset condition judgment unit, which can be specifically used to:

[0212] Acquire system identification information of the first device;

[0213] Determine whether the system identification information is in a preset whitelist; the preset whitelist includes system identification information of multiple device systems with near field communication functions;

[0214] If the system identification information is not in the preset whitelist, it is determined that the source of the tag information does not meet the second preset condition.

[0215] Optionally, the system identification information includes system package name information and package signature information.

[0216] Optionally, the business processing flow execution module can also be used to enable the server to execute a corresponding payment business processing flow according to the positional relationship between the first device and a second device for storing the tag information.

[0217] Optionally, the preset condition in the device further includes a third preset condition; the third preset condition is that there are other devices within the near field communication range of the first device.

[0218] Optionally, the preset condition judgment module further includes a third preset condition judgment unit, which can be specifically used to:

[0219] Determine whether there are other Bluetooth devices within the Bluetooth range of the first device;

[0220] If there is no other Bluetooth device within the Bluetooth range of the first device, it is determined that the tag information does not meet the third preset condition.

[0221] Optionally, the device further includes a prompt information display module, which can be specifically used for:

[0222] Displays a prompt message indicating transaction abnormality.

[0223] Based on the same idea, the embodiments of this specification also provide a device corresponding to the above method. Figure 7 The embodiments of this specification provide corresponding to Figure 4 A schematic diagram of the structure of a payment service processing device. Figure 7As shown, the device may include:

[0224] A payment processing request acquisition module 702, configured to acquire a payment processing request sent by a first device, wherein the payment processing request is generated by the first device based on acquired tag information for triggering a payment service;

[0225] The trusted condition judgment module 704 is used to judge whether the payment processing request satisfies the trusted condition and obtain a judgment result; the trusted condition includes at least one of a first trusted condition and a second trusted condition; the first trusted condition is that the payment processing request is a request obtained within the validity period of the tag information, and the second trusted condition is that the distance between the device sending the payment processing request and the second device for storing the tag information is less than or equal to a preset distance;

[0226] The processing flow termination module 706 is used to terminate the processing flow of the payment service corresponding to the payment processing request if the judgment result indicates that the payment processing request does not meet the trust condition.

[0227] based on Figure 7 The present specification also provides some specific implementation schemes of the method, which are described below.

[0228] Optionally, the device can also be used for:

[0229] If the judgment result indicates that the payment processing request satisfies the trust condition, the payment service processing flow corresponding to the payment processing request is executed and the processing result information is fed back to the first device.

[0230] Optionally, the trusted condition judgment module may further include a first trusted condition judgment unit, and the payment processing request includes identification information of the tag information, which may be specifically used to:

[0231] Based on the identification information, determining the validity period of the tag information;

[0232] Determining whether the acquisition time of the payment processing request is within the validity period;

[0233] If the acquisition time of the payment processing request is not within the validity period, it is determined that the payment processing request does not meet the first trust condition.

[0234] Optionally, the device may further include a validity period sending module, which may be specifically used for:

[0235] generating the label information and recording the validity period of the label information;

[0236] The tag information is sent to the second device.

[0237] Optionally, the device may further include a validity period updating module, which may be specifically used for:

[0238] Acquire notification information sent by the second device indicating that the tag information has been read;

[0239] Based on the notification information, the validity period of the recorded tag information is changed to a new validity period; the duration of the new validity period is shorter than the validity period of the recorded tag information.

[0240] Optionally, the device may further include a transaction abnormality feedback module, which may be specifically used for:

[0241] If the judgment result indicates that the payment processing request does not meet the trust condition, information indicating that the transaction is abnormal is generated and fed back to the first device.

[0242] Optionally, the second trusted condition judgment unit, wherein the payment processing request includes the tag information, can be specifically used to:

[0243] Based on the tag information, determining a second device for storing the tag information;

[0244] Determining whether the distance between the first device and the second device is less than or equal to a preset distance;

[0245] If the distance between the first device and the second device is less than or equal to a preset distance, determining that the payment processing request satisfies the second trust condition;

[0246] If the distance between the first device and the second device is greater than a preset distance, it is determined that the payment processing request does not meet the second trust condition.

[0247] Based on the same idea, the embodiments of this specification also provide a device corresponding to the above method.

[0248] Figure 8 This is a schematic diagram of a payment service processing device provided in an embodiment of this specification. Figure 8 As shown, the device 800 may include:

[0249] at least one processor 810; and,

[0250] A memory 830 communicatively connected to the at least one processor;

[0251] The memory 830 stores instructions 820 that can be executed by the at least one processor 810. The instructions are executed by the at least one processor 810 to enable the at least one processor 810 to implement the above-mentioned payment service processing method.

[0252] Based on the same idea, the embodiment of this specification also provides a computer-readable medium corresponding to the above method. The computer-readable medium stores computer-readable instructions, which can be executed by a processor to implement the above payment service processing method.

[0253] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. The description of the same or similar parts in the method with the server as the execution subject in the above-mentioned method with the first device as the execution subject is relatively simple, and you can refer to the embodiment part of the method with the server as the execution subject. For the equipment and devices shown above, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiments.

[0254] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of relevant data must comply with relevant laws, regulations and standards in the relevant regions, and provide corresponding operation entrances for users to choose to authorize or refuse.

[0255] In the 1990s, improvements to a technology could be clearly distinguished as hardware improvements (for example, improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the method flow). However, with the development of technology, many improvements to the method flow today can be regarded as direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved method flow into the hardware circuit. Therefore, it cannot be said that an improvement in a method flow cannot be implemented using a hardware entity module. For example, a programmable logic device (PLD) (such as a field programmable gate array (FPGA)) is such an integrated circuit whose logical function is determined by the user's programming of the device. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to ask a chip manufacturer to design and produce a dedicated integrated circuit chip. Moreover, nowadays, instead of manually making integrated circuit chips, this kind of programming is mostly implemented by "logic compiler" software, which is similar to the software compiler used when developing and writing programs, and the original code before compilation must also be written in a specific programming language, which is called hardware description language (HDL). There is not only one HDL, but many 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. The most commonly used ones are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also know that it is only necessary to program the method flow slightly in the above-mentioned hardware description languages ​​and program it into the integrated circuit, and then it is easy to obtain the hardware circuit that implements the logic method flow.

[0256] The controller can be implemented in any appropriate manner, for example, the controller can take the form of a microprocessor or processor and a computer-readable medium storing a computer-readable program code (such as software or firmware) that can be executed by the (micro)processor, a logic gate, a switch, an application-specific integrated circuit (ASIC), a programmable logic controller, and an embedded microcontroller. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art also know that in addition to implementing the controller in a purely computer-readable program code manner, the controller can be implemented in the form of a logic gate, a switch, an application-specific integrated circuit, a programmable logic controller, and an embedded microcontroller by logically programming the method steps. Therefore, this controller can be considered as a hardware component, and the devices included therein for implementing various functions can also be regarded as structures within the hardware component. Or even, the devices for implementing various functions can be regarded as both software modules for implementing the method and structures within the hardware component.

[0257] The systems, devices, modules or units described in the above embodiments may be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, 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.

[0258] For the convenience of description, the above device is described in various units according to their functions. Of course, when implementing the present application, the functions of each unit can be implemented in the same or multiple software and / or hardware.

[0259] Those skilled in the art will appreciate that embodiments of the present invention may be provided as methods, systems, or computer program products. Therefore, the present invention may take the form of a complete hardware embodiment, a complete software embodiment, or an embodiment combining software and hardware. Moreover, the present invention may take the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0260] The present invention is described with reference to flowcharts and / or block diagrams of methods, devices (systems), and computer program products according to embodiments of the present invention. It should be understood that each process and / or block in the flowchart and / or block diagram, as well as the combination of processes and / or blocks in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0261] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0262] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

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

[0264] The memory may include non-permanent storage in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. The memory is an example of a computer-readable medium.

[0265] Computer readable media include permanent and non-permanent, removable and non-removable media that can be implemented by any method or technology to store information. Information can be computer readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disk read-only memory (CD-ROM), digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include temporary computer readable media (transitory media), such as modulated data signals and carrier waves.

[0266] It should also be noted that the terms "include", "comprises" or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, commodity or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, commodity or device. In the absence of more restrictions, the elements defined by the sentence "comprises a ..." do not exclude the existence of other identical elements in the process, method, commodity or device including the elements.

[0267] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) that contain computer-usable program code.

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

[0269] The above is only an embodiment of the present application and is not intended to limit the present application. For those skilled in the art, the present application may have various changes and variations. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application should be included in the scope of the claims of the present application.

Claims

1. A method for processing a payment service, comprising: The first device obtains tag information for triggering a payment service; The first device is a mobile terminal device that reads NFC tags; Determine whether the source of the tag information meets a preset condition and obtain a determination result; The preset condition includes at least one of a first preset condition, a second preset condition, a third preset condition and a fourth preset condition; the first preset condition is that the tag information is acquired by the first device through NFC communication; the second preset condition is that the first device is a device with NFC communication function; The third preset condition is that there are other devices within the near field communication range of the first device; the fourth preset condition is that the distance between the first device and the second device for storing the tag information meets the distance threshold; If the judgment result indicates that the source of the tag information does not meet the preset condition, the processing flow of executing the payment service is terminated.

2. The method according to claim 1, further comprising: If the determination result indicates that the source of the tag information meets the preset condition, sending a payment processing request to the server; The server can execute a payment service processing flow based on the payment processing request.

3. The method according to claim 1, determining whether the source of the tag information meets the first preset condition, specifically comprising: Determining whether the trusted memory of the first device contains verification information matching the tag information; The trusted memory is a trusted memory used to store verification information of information obtained by the first device through near field communication; If the trusted memory does not include verification information matching the tag information, it is determined that the source of the tag information does not meet the first preset condition.

4. According to the method of claim 3, the determining whether the trusted memory of the first device contains verification information matching the tag information specifically comprises: Determining whether the trusted memory contains the tag information; Alternatively, the tag information is processed according to a preset data rule to obtain target verification information; Determining whether the trusted memory of the first device contains the target verification information; The verification information stored in the trusted memory is obtained by processing the information obtained by the first device through near field communication according to the preset data rule.

5. The method according to claim 4, wherein the preset data rule comprises an NFC data exchange format; The target verification information includes a target NDEF tag obtained by processing the tag information or part of the tag information according to NDEF rules.

6. The method according to claim 3, further comprising: The verification information in the trusted memory that matches the tag information is deleted.

7. The method according to claim 1, determining whether the source of the tag information meets the second preset condition, specifically comprising: Acquire system identification information of the first device; Determining whether the system identification information is in a preset whitelist; The preset whitelist includes system identification information of multiple device systems having near field communication functions; If the system identification information is not in the preset whitelist, it is determined that the source of the tag information does not meet the second preset condition.

8. The method according to claim 7, wherein the system identification information comprises system package name information and package signature information.

9. The method according to claim 1, determining whether the source of the tag information meets the second preset condition, specifically comprising: Determining whether the system identification information of the first device is in a preset blacklist; The device corresponding to the system identification information in the preset blacklist does not contain a module related to the NFC tag in hardware or does not have an NFC near-field communication function in software; If the system identification information is not in the preset blacklist, it is determined that the source of the tag information meets the second preset condition.

10. According to the method of claim 2, the server can also execute a corresponding payment service processing flow according to the positional relationship between the first device and the second device for storing the tag information.

11. According to the method of claim 10, the tag information is generated by the server and sent to the second device; the second device is a device associated with the NFC tag; the NFC tag is built into the second device, or the second device is connected to the device of the NFC tag wirelessly or wiredly.

12. The method according to claim 1, determining whether the source of the tag information satisfies a third preset condition, specifically comprising: Determine whether there are other Bluetooth devices within the Bluetooth range of the first device; If no other Bluetooth device exists within the Bluetooth range of the first device, determining that the tag information does not meet the third preset condition; If there are other Bluetooth devices within the Bluetooth range of the first device, it is determined that the tag information meets the third preset condition.

13. The method according to claim 12, further comprising: If there are other Bluetooth devices within the Bluetooth range of the first device, sending information of the other Bluetooth devices to the server; The server determines whether the other Bluetooth devices include the second device, and sends the determination result to the first device; If the judgment result is that the other Bluetooth devices include the second device, determining that the tag information meets a third preset condition; If the judgment result is that the other Bluetooth devices do not contain the second device, it is determined that the tag information does not meet the third preset condition.

14. The method according to claim 1, further comprising: Displays a prompt message indicating transaction abnormality.

15. The method according to claim 14, wherein the prompt information indicating the transaction abnormality comprises at least one of information prompting the user of the transaction abnormality, information indicating the reason for the transaction abnormality, and prompt information prompting the user to use a near field communication payment method.

16. The method according to claim 1, determining whether the source of the tag information satisfies a fourth preset condition, specifically comprising: Send a location acquisition request to the server; The server can determine the second location information of the second device according to the tag information included in the location acquisition request or the identification information corresponding to the tag information; Acquire the second location information fed back by the server; Based on the first location information of the first device and the second location information, determining whether the distance between the first device and the second device meets a distance threshold; or, Send a location acquisition request to the server; Obtaining a distance value between the first device and the second device fed back by the server; It is determined whether the distance value satisfies a distance threshold.

17. The method according to claim 16, wherein the first location information and the second location information are location information obtained based on at least one of a mobile location service (LBS), a global positioning system (GPS), and a Beidou satellite navigation system (BDS).

18. According to the method of claim 1, the process of terminating the payment service specifically comprises: The first device does not send a payment service processing request to the server; Alternatively, after sending the payment service processing request to the server, the first device sends a request to terminate the payment service processing to the server.

19. The method according to claim 1, further comprising: Based on the tag information, starting a target application in the first device; After determining that the tag information meets the preset condition, the target application generates a payment processing request based on the tag information.

20. According to the method of claim 19, the tag information includes identification information related to the target application, and the first device can call up the target application through the identification information; the identification information includes a name identifier of the target application.

21. The method according to claim 1, further comprising: Receive the execution result information of the payment service processing flow fed back by the server; the execution result information includes any one of the result information indicating payment success, payment failure or payment abnormality; A payment result page is displayed based on the execution result information.

22. A method for processing a payment service, the method being applied to a server, comprising: Obtaining a payment processing request sent by the first device, where the payment processing request is generated by the first device based on the acquired tag information for triggering the payment service; The first device is a mobile terminal device that reads NFC tags; Determine whether the payment processing request satisfies a trust condition and obtain a determination result; the trust condition includes at least one of a first trust condition and a second trust condition; the first trust condition is that the payment processing request is a request obtained within the validity period of the tag information, and the second trust condition is that the distance between the device sending the payment processing request and the second device for storing the tag information is less than or equal to a preset distance; If the judgment result indicates that the payment processing request does not meet the trust condition, the processing flow of the payment service corresponding to the payment processing request is terminated.

23. The method according to claim 22, further comprising: If the judgment result indicates that the payment processing request satisfies the trust condition, the payment service processing flow corresponding to the payment processing request is executed and the processing result information is fed back to the first device.

24. The method according to claim 22, wherein the payment processing request includes identification information of the tag information; Determining whether the payment processing request satisfies a first trust condition specifically includes: Based on the identification information, determining the validity period of the tag information; Determining whether the acquisition time of the payment processing request is within the validity period; If the acquisition time of the payment processing request is not within the validity period, it is determined that the payment processing request does not meet the first trust condition.

25. According to the method of claim 24, the tag information is information in a link form; or, the identification information is at least one of partial information in the tag information, all information in the tag information, and token information contained in the tag information.

26. The method according to claim 24, further comprising: generating the label information and recording the validity period of the label information; The tag information is sent to the second device. 27 . The method according to claim 26 , wherein the second device comprises an NFC tag, and the tag information can be burned into the NFC tag after receiving the tag information sent by the server.

28. The method according to claim 26, further comprising: Acquire notification information sent by the second device indicating that the tag information has been read; Based on the notification information, changing the validity period of the recorded label information to a new validity period; The duration of the new validity period is shorter than the validity period of the recorded tag information.

29. The method of claim 22, further comprising: If the judgment result indicates that the payment processing request does not meet the trust condition, information indicating that the transaction is abnormal is generated and fed back to the first device.

30. The method according to claim 22, wherein the payment processing request includes the tag information; the method further comprising: Based on the tag information, determining a second device for storing the tag information; Determining whether the payment processing request satisfies a second trust condition specifically includes: Determining whether the distance between the first device and the second device is less than or equal to a preset distance; If the distance between the first device and the second device is less than or equal to a preset distance, determining that the payment processing request satisfies the second trust condition; If the distance between the first device and the second device is greater than a preset distance, it is determined that the payment processing request does not meet the second trust condition.

31. According to the method according to claim 22, the payment processing request is generated by the first device when the source of the tag information meets the preset conditions; the preset conditions include at least one of the first preset conditions, the second preset conditions, the third preset conditions and the fourth preset conditions; the first preset condition is that the tag information is obtained by the first device through NFC communication; the second preset condition is that the first device is a device with NFC communication function; the third preset condition is that there are other devices within the near-field communication range of the first device; the fourth preset condition is that the distance between the first device and the second device used to store the tag information meets the distance threshold.

32. A payment service processing device, the device being applied to a first device, comprising: A tag information acquisition module, used to acquire tag information used to trigger payment services; The first device is a mobile terminal device that reads NFC tags; A preset condition judgment module is used to judge whether the source of the tag information meets the preset condition and obtain a judgment result; The preset condition includes at least one of a first preset condition, a second preset condition, a third preset condition and a fourth preset condition; the first preset condition is that the tag information is acquired by the first device through NFC communication; the second preset condition is that the first device is a device with NFC communication function; The third preset condition is that there are other devices within the near field communication range of the first device; the fourth preset condition is that the distance between the first device and the second device for storing the tag information meets the distance threshold; The processing flow termination module is used to terminate the processing flow of the payment service if the judgment result indicates that the source of the tag information does not meet the preset condition.

33. A payment service processing device, the device being applied to a server, comprising: A payment processing request acquisition module, used to acquire a payment processing request sent by a first device, wherein the payment processing request is generated by the first device based on acquired tag information for triggering a payment service; the first device is a mobile terminal device for reading NFC tags; a trusted condition judgment module, used to judge whether the payment processing request satisfies a trusted condition and obtain a judgment result; the trusted condition includes at least one of a first trusted condition and a second trusted condition; the first trusted condition is that the payment processing request is a request obtained within the validity period of the tag information, and the second trusted condition is that the distance between the device sending the payment processing request and the second device for storing the tag information is less than or equal to a preset distance; The processing flow termination module is used to terminate the processing flow of the payment service corresponding to the payment processing request if the judgment result indicates that the payment processing request does not meet the trust condition.

34. A payment service processing device, comprising: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can execute the payment service processing method described in any one of claims 1 to 31.

35. A computer-readable medium having computer-readable instructions stored thereon, wherein the computer-readable instructions can be executed by a processor to implement the payment service processing method according to any one of claims 1 to 31.

Images