Payment service processing method, apparatus, and device, and medium

Abstract

Disclosed in embodiments of the present description are a payment service processing method, apparatus, and device, and a medium. The solution comprises: a first device acquiring tag information for triggering a payment service; determining whether the source of the tag information satisfies a preset condition, and obtaining a determination result, wherein the preset condition comprises at least one of a first preset condition and a second preset condition, the first preset condition is that the tag information is acquired by means of NFC communication, and the second preset condition is that the first device has an NFC communication function; and if the determination result indicates that the source of the tag information fails to satisfy the preset condition, terminating execution of a processing flow of the payment service.

Description

A method, apparatus, equipment, and medium for processing payment transactions.

[0001] This application claims priority to Chinese Patent Application No. 202411055546.7, filed on August 1, 2024, entitled "A Method, Apparatus, Equipment and Medium for Processing Payment Transactions", the entire contents of which are incorporated herein by reference. Technical Field

[0002] This application relates to the field of computer technology, and in particular to a method, apparatus, equipment and medium for processing payment transactions. Background Technology

[0003] With the development of computer technology, more and more transactions can be processed through mobile terminals, such as online payments and QR code payments for transportation. In recent years, NFC technology has been widely used in payment services due to its low cost and ease of use, such as using NFC cards to pay for public transportation. Therefore, improving payment security is a pressing technical issue that needs to be addressed.

[0004] Summary of the Invention

[0005] This specification provides a method, apparatus, device, and medium for processing payment transactions, in order to address the payment risk issues present in existing payment transaction processing methods.

[0006] To solve the above-mentioned technical problems, the embodiments in this specification are implemented as follows:

[0007] This specification provides an embodiment of a payment processing method, including:

[0008] The first device acquires the tag information used to trigger the payment transaction;

[0009] Determine whether the source of the tag information meets preset conditions, and obtain a determination result; the preset conditions include 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;

[0010] If the judgment result indicates that the source of the tag information does not meet the preset conditions, the processing flow of the payment business will be terminated.

[0011] This specification provides an embodiment of a payment processing method, including:

[0012] Obtain a payment processing request sent by a first device, wherein the payment processing request is generated by the first device based on the obtained tag information used to trigger the payment transaction;

[0013] Determine whether the payment processing request meets the trust conditions and obtain the determination result; the trust conditions include 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 used to store the tag information is less than or equal to a preset distance;

[0014] If the determination result indicates that the payment processing request does not meet the trusted condition, then the processing flow of the payment business corresponding to the payment processing request will be terminated.

[0015] This specification provides an embodiment of a payment processing apparatus, comprising:

[0016] The tag information acquisition module is used to acquire tag information used to trigger payment transactions;

[0017] A preset condition judgment module is used to determine whether the source of the tag information meets preset conditions and obtain a judgment result; the preset conditions include 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;

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

[0019] This specification provides an embodiment of a payment processing apparatus, comprising:

[0020] The payment processing request acquisition module is used to acquire a payment processing request sent by the first device, wherein the payment processing request is generated by the first device based on the acquired tag information used to trigger the payment transaction;

[0021] A trust condition judgment module is used to judge whether the payment processing request meets the trust condition and obtain a judgment 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 used to store the tag information is less than or equal to a preset distance;

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

[0023] This specification provides an embodiment of a payment processing device, including:

[0024] At least one processor; and,

[0025] A memory communicatively connected to the at least one processor; wherein,

[0026] The memory stores instructions that can be executed by the at least one processor, which, when executed, enable the at least one processor to perform a payment processing method.

[0027] This specification provides a computer-readable medium storing computer-readable instructions that can be executed by a processor to implement a payment service processing method.

[0028] At least one embodiment in this specification can achieve the following beneficial effects: by obtaining tag information for triggering payment transactions through a first device, and judging whether the source of the tag information meets the preset conditions based on the tag information, if the source of the tag information does not meet the preset conditions, it can be further determined that the current transaction is at risk, and the first device can stop sending payment transaction processing requests to the server and terminate the payment transaction processing flow, thereby avoiding the risk of user account funds being defrauded or stolen and improving the security of payment transactions. Attached Figure Description

[0029] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the accompanying drawings used in the description of the embodiments or prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0030] Figure 1 is a schematic diagram of an application scenario of a payment business processing method provided in the embodiments of this specification;

[0031] Figure 2 is a flowchart illustrating a payment processing method provided in an embodiment of this specification;

[0032] Figure 3 is a schematic diagram of a page showing the processing results of a transaction anomaly, provided in an embodiment of this specification.

[0033] Figure 4 is a flowchart illustrating a payment processing method provided in an embodiment of this specification;

[0034] Figure 5 is a flowchart of a payment processing method provided in an embodiment of this specification;

[0035] Figure 6 is a schematic diagram of a payment processing device corresponding to Figure 2 provided in the embodiments of this specification;

[0036] Figure 7 is a schematic diagram of a payment processing device corresponding to Figure 4 provided in the embodiments of this specification;

[0037] Figure 8 is a schematic diagram of the structure of a payment processing device provided in an embodiment of this specification. Detailed Implementation

[0038] To make the objectives, 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 conjunction with specific embodiments and corresponding drawings. Obviously, the described embodiments are only a part of the embodiments of this specification, and not all of them. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort are within the protection scope of one or more embodiments of this specification.

[0039] NFC is a technology that allows two electronic devices to wirelessly transmit data within a distance of a few centimeters. This short-range wireless connection is primarily used in scenarios such as mobile payment information sharing and simplified device pairing. In NFC payment scenarios, users can use NFC-enabled devices for contactless payments. During the payment process, the user's device wirelessly communicates with the merchant's terminal via NFC, enabling fast payment. For example, in a public transportation scenario, the user's terminal can act as an NFC tag and be read by the turnstile on the bus to complete the payment; or when riding the subway, the user can tap their terminal against the turnstile, and the terminal, acting as an NFC tag or card, can be read by the turnstile to complete the payment.

[0040] In practical applications, users can use mobile terminals with NFC card reading capabilities to read payment links from merchant devices containing NFC tags via short-range contact or contactless methods such as tapping, and complete payments based on these links. However, some unscrupulous users may crack the tag information in the NFC tags on merchant devices to obtain the corresponding payment links. They can then repackage or directly forward these payment links to users, tampering with near-field payments and converting them into online payments, thus inducing users to click the links and complete payments. This makes it extremely easy for funds in users' accounts to be stolen or used for fraud.

[0041] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0042] To address the shortcomings of existing technologies, this solution provides the following embodiments:

[0043] Figure 1 is a schematic diagram of an application scenario of a payment business processing method provided in the embodiments of this specification.

[0044] As shown in Figure 1, this solution can include a first device 1, a server 2, and a second device 3. The first device 1 can be a user terminal device with NFC tag reading capabilities, such as a mobile phone, tablet, smartwatch, wearable smart device, or laptop computer. The second device 3 can be a device associated with an NFC tag, also known as an NFC device, such as a POS machine or cash register. The second device 3 may have a built-in NFC tag, or the NFC tag may be separate from the second device. In practical applications, the first device 1 can obtain the NFC tag information from the second device 3 and trigger the payment process. However, in practice, some unauthorized users may maliciously obtain the NFC tag from the second device and send it to the first device through other means. For example, an unauthorized user might crack the tag information in the second device, obtain the payment link information contained in the tag information, and then package or directly send the payment link information to the first device through other devices. This could lead to financial losses or information leaks for the user of the first device. To ensure payment security, the first device or server can also verify the reliability of the source of the tag information obtained by the first device. This reduces the risk of user account funds being stolen or defrauded, thus improving payment security.

[0045] Next, a payment processing method provided in the embodiments of the specification will be described in detail with reference to the accompanying drawings.

[0046] Figure 2 is a flowchart illustrating a payment processing method provided in an embodiment of this specification. From a programmatic perspective, the entity executing the process can be a program or application client mounted on a first device. From a hardware perspective, the entity executing the process can be the first device, specifically a mobile terminal such as a mobile phone, smartwatch, wearable smart device, or tablet computer.

[0047] As shown in Figure 2, the process may include the following steps:

[0048] Step 202: The first device acquires the tag information used to trigger the payment transaction.

[0049] The first device in the embodiments of this specification can be a user mobile terminal device running the Android system, such as a mobile phone, computer, smartwatch, and other smart wearable devices. It can also be a device with other operating systems, as long as it can execute the methods provided in the embodiments of this specification.

[0050] The first device can be equipped with the function of reading NFC tags, and can act as a card reader to read the tag information in the NFC tag. In practical applications, the tag information can be the tag information obtained by the first device from the second device through a near-field payment method; or it can be the tag information sent to the first device by an unauthorized user through another device after the tag information in the NFC device has been compromised.

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

[0052] The preset conditions include 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 can be first determined whether the source of the tag information meets a first preset condition. If the source of the tag information meets the first preset condition, it can then be determined whether the source of the tag information meets a second preset condition; or it can be first determined whether the source of the tag information meets the second preset condition, and if the source of the tag information meets the second preset condition, then it can be determined whether the source of the tag information meets the first preset condition. Alternatively, it can only determine whether the source of the tag information meets the first preset condition, or only determine whether the source of the tag information meets the second preset condition. It can also execute the judgment process corresponding to both preset conditions simultaneously, and determine whether the source of the tag information is trustworthy based on the two judgment results. Alternatively, it can terminate the execution of the judgment program corresponding to the other preset condition after obtaining the judgment result of one preset condition. For example, after determining that the tag information was not obtained through NFC communication according to the first preset condition, if the judgment program for the second preset condition has started execution but has not yet obtained a result, the execution of the judgment program for the second preset condition can be terminated. The setting of the judgment conditions can be determined according to actual needs, and no specific limitations are made here.

[0054] In the embodiments of this specification, the reliability of the tag information can be further determined by judging whether the source of the tag information meets preset conditions. The first device can provide a storage space for the target application, allowing it to store information accessible only to the target application. The target application can compare the stored information with the tag information to determine its reliability, and thus whether the tag information was obtained via NFC communication, or whether the first device has NFC functionality. Based on the judgment result, the first device can determine whether the transaction link corresponding to the tag information is risky, thereby preventing other applications besides the target application from directly completing payments through the link.

[0055] Step 206: If the judgment result indicates that the source of the tag information does not meet the preset conditions, then the processing flow of the payment business 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 be that the source of the tag information does not meet the second preset condition; or it may be that the source of the tag information does not meet both the first and second preset conditions. Specific judgment criteria can be set according to actual business needs. If the source of the tag information does not meet the preset conditions, it can be indicated that the tag information obtained by the first device is unreliable, and thus it can be determined that the payment transaction corresponding to the tag information is risky and insecure. The first device may not process the payment transaction.

[0057] The process of terminating payment processing can mean that the first device does not send a payment processing request to the server and directly does not execute the payment processing procedure. In practical applications, the process of terminating payment processing can also mean that after the first device sends a payment processing request to the server, if it detects that the tag information is untrustworthy, it sends a request to terminate payment processing, causing the server to terminate the payment processing procedure that is currently 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 may be interchanged according to actual needs, or some steps may be omitted or deleted.

[0059] The method in Figure 2 obtains tag information used to trigger payment transactions through a first device. Based on the tag information, it determines whether the source of the tag information meets preset conditions. If the source of the tag information does not meet the preset conditions, it can be determined that the current transaction is risky. The first device can then stop sending a payment transaction processing request to the server and terminate the payment transaction processing flow to avoid the risk of user account funds being defrauded or stolen, thereby improving the security of payment transactions.

[0060] Based on the method in Figure 2, this specification also provides some specific implementation schemes of the method, which will be described below.

[0061] As one implementation method, 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 business processing flow based on the payment processing request.

[0063] The source of the label information meets the preset conditions. This can be the first preset condition, the second preset condition, or both. The specific situation can be determined based on the set judgment conditions.

[0064] In the embodiments of this specification, the source of the tag information meeting preset conditions indicates that the tag information is trustworthy. Trustworthy tag information means that the first device obtained the tag information by bringing it close to or near the device providing the tag information; for example, a user brings the first device close to a second device to obtain the NFC tag information of the second device. The payment processing flow can represent the process for processing payment processing requests, such as the server reading the information carried in the payment processing request, deducting the transaction amount from the corresponding user account, and transferring the deducted transaction amount to the payee's account. The payment processing request can be a request generated by the first device based on the tag information after determining that the tag information is trustworthy.

[0065] In this embodiment of the specification, the first device can also launch a target application within the first device based on the tag information. The target application can generate a payment processing request based on the tag information after determining its trustworthiness through preset conditions.

[0066] The tag information may contain identification information related to the target application, such as the name of the target application. The first device can use this identification information to activate the target application. The target application can be a terminal application (APP) with payment functionality.

[0067] In practical applications, after receiving the tag information, if the first device is currently displaying another page, it can jump to the target application page from that page, switch the other page to the background or close it, and bring the target application page to the foreground; alternatively, it can overlay the target application page on top of other pages. These other pages can be the first device's main page, menu page, system page, or other application pages. It's understandable that if the first device's screen is off, it can directly display the target application page based on the tag information, or it can display the target application page based on the tag information after the first device is unlocked.

[0068] In practical applications, the first device can receive the execution result information of the payment transaction processing flow from the server, and can also display a payment result page based on the obtained execution result information. The execution result information can include results such as payment success, payment failure, or payment exception. The format and content of the display page corresponding to the execution result can be set according to actual needs, and there are no specific limitations here. For example, if the execution result is payment success, the transaction amount information can be displayed on the page; if the execution result is payment failure, the transaction amount information and the reason for the transaction failure information can be displayed on the page, or only the reason for the transaction failure information can be displayed, and so on.

[0069] As one implementation method, the trustworthiness of tag information can be determined by whether it was obtained through NFC communication. Optionally, in this embodiment, determining whether the source of the tag information meets the first preset condition may specifically include:

[0070] Determine whether the trusted memory of the first device contains verification information that matches 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.

[0071] If the trusted memory does not contain verification information that matches the tag information, then it is determined that the source of the tag information does not meet the first preset condition.

[0072] If the trusted memory contains verification information that matches the tag information, then the source of the tag information is determined to meet the first preset condition.

[0073] Trusted memory can be a hardware-isolated area within the first device used to store sensitive information, such as encryption keys and authentication data. Trusted memory provides a more secure environment than a regular operating system, allowing only target applications to access data within it and preventing malware from accessing the data. After acquiring information transmitted via the NFC channel, the first device can store this information in trusted memory as verification information; alternatively, it can process the information according to a preset data processing format and store the resulting information in trusted memory as verification information. This allows the verification information in trusted memory to verify the trustworthiness of the tag information acquired by the first device.

[0074] In practical 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 trusted memory and verify the tag information based on the verification information obtained from trusted memory. If the target application determines that the tag information does not contain the verification information in trusted memory, or that there is no verification information in trusted memory that is consistent with the tag information, it can determine that the source of the tag information does not meet the first preset condition, thus determining that the tag information is untrustworthy and that the current transaction is risky. The first device can choose not to access the server or request the server to terminate the payment business processing flow to ensure the security of the user's account funds.

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

[0076] As one implementation method, the verification information in the trusted memory can be information obtained according to a preset format. Optionally, the determination of whether the trusted memory of the first device contains verification information matching the tag information, as described in the embodiments of this specification, may specifically include:

[0077] The tag information is processed according to preset data rules to obtain target verification information;

[0078] Determine whether the target verification information is contained in the trusted memory of the first device; the verification information stored in the trusted memory is obtained by processing the information obtained by the first device through near-field communication in accordance with the preset data rules.

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

[0080] In practical applications, determining whether the trusted memory of the first device contains target verification information can be achieved by the target application in the first device matching the target NDEF tag within the trusted memory. If the match is successful, it indicates that the trusted memory contains an NDEF tag that matches the target NDEF tag, suggesting that the tag information is trustworthy and was obtained by the first device via NFC communication. If the match fails, and the trusted memory does not contain an NDEF tag that matches the target NDEF tag, it indicates that the tag information is untrustworthy and was obtained through methods other than NFC communication. In NFC payment scenarios, this tag information poses a risk, and the payment processing flow can be terminated.

[0081] In the embodiments 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, thereby indicating that the tag information is trusted. 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 business.

[0082] 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, and thus it can be indicated that the tag information is untrustworthy. The first device can then terminate the payment business processing flow without accessing the server.

[0083] As one implementation method, optionally, the method described in the embodiments of this specification may further include:

[0084] Delete the verification information that matches the tag information from the trusted memory.

[0085] In practical applications, to further ensure payment security, the verification information matching the tag information in trusted memory can be deleted. This prevents unauthorized users from obtaining the tag information and sending it to the primary device through other channels, thus triggering the payment process.

[0086] As another implementation method, the first device can set a verification validity period for the verification information during the generation of verification information. When the verification information is stored in trusted memory for a longer period than the verification validity period, it can be determined that the verification information has expired and the expired verification information can be deleted.

[0087] As one implementation method, the reliability of the tag information can also be determined by whether the first device acquiring the tag information is in a preset whitelist. Optionally, in the embodiments of this specification, determining whether the source of the tag information meets the second preset condition may specifically include:

[0088] Obtain the system identification information of the first device;

[0089] 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.

[0090] If the system identification information is not in the preset whitelist, then the source of the tag information is determined not to meet the second preset condition. If the system identification information is in the preset whitelist, then the source of the tag information is determined to meet the second preset condition.

[0091] The preset whitelist can include identification information of devices with NFC functionality, such as device name and device ID, or system identifiers of the device's operating system, such as system package name and package signature. The preset whitelist can be stored in trusted memory by the target application or in other memory spaces. The system identifier information in the preset whitelist can be provided to the target application by the device manufacturer or system developer, or it can be obtained by the target application from the user's mobile terminal information after the user has granted permission for the target application to access system information.

[0092] In practical applications, a blacklist can be pre-set. If the system identifier information is in the pre-set blacklist, it is determined that the source of the tag information does not meet the second pre-set condition; if the system identifier information is not in the pre-set blacklist, it is determined that the source of the tag information meets the second pre-set condition. The devices corresponding to the system identifier information in the pre-set blacklist do not contain NFC tag-related modules in hardware, or do not have NFC near-field communication functionality in software. The method for obtaining the system identifier information in the pre-set blacklist is the same as the method for obtaining the pre-set whitelist.

[0093] The system identification information in the embodiments of this specification 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 an application or service. In different Android versions, the same application or service should use the same package name to ensure compatibility and consistency. For example, the package name of payment application 1 is package name 1 in both Android version 1 and Android version 2, 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, ensuring that the application has not been tampered with or comes from an untrusted source.

[0094] In practical applications, after acquiring the tag information, the first device can wake up the target application. The target application can then acquire the system identification information of the first device. The target application can search a preset whitelist for a target system identification information that matches the first device's system identification information. If it does, the source of the tag information satisfies the second preset condition, thus confirming the tag information is trustworthy. The target application's client can then generate a payment processing request based on the tag information and send it to the server. If it does not, the source of the tag information does not meet the second preset condition, thus confirming the tag information is untrustworthy. The target application's client can then terminate the payment processing flow. Specifically, the trustworthiness of the tag information's source can be determined based on at least one of the following: package name information and package signature information. For example, it can first determine whether the trusted memory contains the first device's package name information. If the trusted memory does not contain the first device's package name information, the source of the tag information does not meet the second preset condition. If the trusted memory contains the first device's package name information, it can then determine whether the trusted memory contains the first device's package signature information to confirm the tag information's trustworthiness. The order of judging the package name information and the package signature information can be set based on actual needs. The credibility of tag information can also be determined by judging the package name information or the package signature information alone.

[0095] Optionally, the server described in this embodiment can also execute the corresponding payment business processing flow based on the location relationship between the first device and the second device used to store the tag information.

[0096] In the embodiments of this specification, the second device can 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 wirelessly or via a wired connection; the second device here can refer to a secure, legal, and compliant device. The server can obtain the first location information of the first device and the second location information of the second device, and thus determine the distance between the first device and the second device. The distance between the two devices can be used to determine whether to execute the payment transaction processing procedure.

[0097] The tag information can be generated by the server and sent to the second device. For example, in an NFC payment scenario, the merchant's POS system can connect to the second device. After the cashier confirms the payment through the merchant's POS system, the merchant's POS 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 tag information to the second device. There are no specific limitations here.

[0098] In practical applications, the first device can also determine the credibility of the tag information by the position 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 the fourth preset condition. The fourth preset condition can be used to indicate that the distance between the first device and the second device meets the distance threshold.

[0099] Specifically, the first device can send a location acquisition request to the server. The server can determine the second location information of the second device based on the tag information or the identification information corresponding to the tag information contained in the location acquisition request and send 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 trustworthy, 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 was not sent through near-field communication and is therefore untrustworthy. The first device can choose not to access the server and not generate a payment processing request.

[0100] In one implementation, after obtaining the second location information, the server can directly determine the distance between the first and second devices and feed it back to the first device. The first device then determines the reliability of the tag information by judging whether the fed-back distance value meets a distance threshold. The first and second location information can be location information obtained based on Location-Based Services (LBS), or location information obtained through positioning systems such as Global Positioning System (GPS) or BeiDou Navigation Satellite System (BDS), or the device's location information can be obtained through the device's connected Wi-Fi or Bluetooth connection.

[0101] As one implementation method, the reliability of the tag information can also be determined by using a preset range of the first device. Optionally, the preset conditions described in the embodiments of this specification further include a third preset condition; the third preset condition is that other devices exist within the near-field communication range of the first device.

[0102] Near-field communication range can include the communication range of Bluetooth connection, NFC communication range, and WIFI connection, etc.

[0103] As one implementation method, it is determined whether the source of the tag information meets a third preset condition; specifically, it may include:

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

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

[0106] If no other Bluetooth devices are within the Bluetooth range of the first device, it indicates that there are no other near-field communication (NFC) devices around the first device. This confirms that the tag information obtained by the first device was not acquired through NFC. In NFC payment scenarios, this tag information poses a risk, and a payment processing request may not be sent. If other Bluetooth devices are 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 trustworthy.

[0107] To further ensure payment security, server verification can also be performed. As one implementation, if other Bluetooth devices exist within the Bluetooth range of the first device, their information can be sent to the server. Upon receiving this information, the server identifies the second device's Bluetooth device based on the tag information, determines whether the other Bluetooth devices include the second device's Bluetooth device, and sends the result back to the first device. The first device can then determine the reliability of the tag information based on the feedback result, checking if the source of the tag information meets a third preset condition. If the feedback result indicates that the other Bluetooth devices include the second device's Bluetooth device, the first device determines that the source of the tag information meets the third preset condition and that the tag information is reliable. If the feedback result indicates that the other Bluetooth devices do not include the second device's Bluetooth device, the first device determines that the source of the tag information does not meet the third preset condition and that the tag information is unreliable, thus eliminating the need to access the server.

[0108] In one implementation, the first device may also directly include information about other Bluetooth devices within its range in the payment processing request and send it to the server. The server then determines whether to execute the payment process based on the information about the other Bluetooth devices.

[0109] The first device can also determine whether to send a payment processing procedure to the server by checking if it has established a Bluetooth connection with other devices. If the first device establishes a Bluetooth connection, it indicates that the source of the tag information is trustworthy, and it can send a payment processing request containing information about the device with the established Bluetooth connection to the server. The server can then determine whether to execute the payment processing procedure by checking if the device with the established Bluetooth connection to the first device is the second device.

[0110] Optionally, the method described in the embodiments of this specification may further include: displaying a prompt message indicating an abnormal transaction.

[0111] In the embodiments of this specification, the first device can generate a prompt message indicating a transaction error locally based on the obtained judgment result, or it can obtain a prompt message indicating a transaction error provided by the server. The prompt message indicating a transaction error may include information informing the user of the transaction error, information about the reason for the transaction error, or prompts to the user to use NFC payment, etc.

[0112] In practical applications, the first device can also display a message indicating that the transaction was successful; it can also display a message prompting the user to confirm the transaction; it can also display a message prompting the user to launch the target payment application, and so on.

[0113] To clearly illustrate the display page for the prompt information, Figure 3 is a schematic diagram of a page indicating the processing result of a transaction anomaly provided in an embodiment of this specification. As shown in Figure 3, this page 300 may include a payment page 302, which may contain information such as the payment amount. A prompt message 304 may be displayed above the payment page to inform the user that the current transaction is abnormal. The prompt message may also include a prompt to the user to complete the payment via NFC, such as "Transaction abnormal, please complete the payment by tapping your NFC device."

[0114] As shown in Figure 3, this page can also include a control 306 for closing the page, such as an "OK" control. Clicking this control will close the page or redirect the user to another page, such as the main page of the first device or the homepage of the payment app. It is understood that Figure 3 is for illustrative purposes only, and other layouts of the displayed page can be used; no specific limitations are made here. For example, only the prompt information could be displayed, without showing the payment page.

[0115] This specification may also utilize a server to verify the credibility of tag information. Figure 4 is a flowchart illustrating a payment processing method provided in an embodiment of this specification. From a programming perspective, the entity executing the process can be a program hosted on an application server or an application client.

[0116] As shown in Figure 4, the process may include the following steps:

[0117] Step 402: Obtain the payment processing request sent by the first device. The payment processing request is generated by the first device based on the obtained tag information used to trigger the payment transaction.

[0118] In the embodiments of this specification, the first device can be a user terminal device with NFC tag reading function, such as a mobile user terminal device like a mobile phone, tablet, smartwatch, wearable smart device, or laptop computer. The tag information can be generated by a server; the tag information can contain payment-related identifiers, which can be preset characters; it can also be the identifier information of the payment application or other information used to identify payment transactions, without specific limitations here. The payment processing request can include identifier information of the method that triggers the payment request, such as identifier information indicating a face-to-face payment method, such as NFC communication identifier information, or identifier information for payment by scanning payment codes, collection codes, or other code images, etc.

[0119] Step 404: Determine whether the payment processing request meets the trust conditions and obtain the determination result; the trust conditions include at least one of a first trust condition and a second trust condition; the first trust condition is that the payment processing request is 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 used to store the tag information is less than or equal to a preset distance.

[0120] Determining whether a payment processing request meets the trust conditions can be done in several ways. First, it can be checked if the request meets the first trust condition; if so, then it can be checked if it meets the second trust condition. Alternatively, it can be checked first, then the second trust condition; or only the first or second trust condition can be checked. Both trust condition checks can be executed simultaneously, and the trustworthiness of the payment request is determined based on the two results. Alternatively, the execution of the check for one trust condition can be terminated after obtaining the result of the first trust condition check. For example, if the first trust condition determines that the payment processing request was not obtained within the validity period of the tag information, and the check for the second trust condition has started but has not yet yielded a result, the check for the second trust condition can be terminated. The judgment conditions can be set according to actual needs and are not specifically limited here.

[0121] In the embodiments of this specification, the validity period can be the valid time period or valid duration set by the server for the tag information when generating the tag information.

[0122] The second device can be a device associated with an NFC tag, such as a POS machine or cash register. The second device may have a built-in NFC tag, or the NFC tag may be separate from the second device. The payment processing request may include the location information of the first device that sent the payment processing request; alternatively, 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 on the server or sent to the server by the second device.

[0123] Step 406: If the judgment result indicates that the payment processing request does not meet the trusted condition, then the processing flow of the payment business corresponding to the payment processing request is terminated.

[0124] In the embodiments of this specification, the payment processing request not meeting the trusted conditions can mean that the payment processing request was 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 used to store the tag information is greater than a preset distance, or that neither the validity period condition nor the preset distance condition is met.

[0125] A payment processing request that meets the trust conditions can mean that the payment processing request was obtained within the validity period of the tag information; it can 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 a preset distance; or it can mean that the tag information is both within the validity period and the distance is less than or equal to the preset distance.

[0126] As one implementation method, optionally, the method described in the embodiments of this specification may further include:

[0127] If the judgment result indicates that the payment processing request meets the trusted condition, then the processing flow of the payment business corresponding to the payment processing request is executed and the processing result information is fed back to the first device.

[0128] As one implementation method, optionally, the payment processing request described in the embodiments of this specification includes the identification information of the tag information; determining whether the payment processing request meets the first trust condition may specifically include:

[0129] Based on the identification information, the validity period of the label information is determined;

[0130] Determine whether the time of acquisition of the payment processing request is within the validity period;

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

[0132] Tag information can be a string that conforms to preset rules, such as a link, like a URL. Tag information can include order identification information, or token information generated specifically for that tag, etc., without specific limitations. Identification information can be part or all of the information in the tag information, such as token information included in the tag information.

[0133] The validity period can represent the effective duration or time period of the tag information. If the validity period represents the effective duration of the tag information, it can be determined by comparing the time difference between the acquisition time and the generation time with the effective duration. If the time difference is greater than the effective duration, 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 represents the effective time period of the tag information, it can be determined by determining 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. The server then terminates the payment business processing flow.

[0134] If the time difference is less than or equal to the validity period, or if the acquisition time falls within the time interval between the generation time and the expiration time, it can be determined that the acquisition time is within the validity period, and the payment processing request meets the first trust condition. The server can then continue to execute the payment business processing flow.

[0135] As one implementation method, optionally, the method described in the embodiments of this specification further includes:

[0136] It can generate tag information, record the validity period of the tag information, and send the tag information to a second device.

[0137] The validity period of tag information can be set by the server, such as when generating tag information and setting the validity period. 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 time when the server generates the tag information, and the corresponding end time can be determined based on the generation time and the preset duration of the validity period.

[0138] A second device containing an NFC tag can burn the tag information into the NFC tag after receiving the tag information sent by the server. The tag information can be stored for a preset time, such as 30 minutes or 1 hour. This preset time indicates the validity period of the tag information.

[0139] In practical applications, if the tag information is not read for a certain period of time or exceeds its validity period, the server can determine that the tag information has expired and delete it. The server can also check if the tag information exists in the trusted tag set. If it does not exist, it indicates that the tag information has expired and cannot be used for payment. The trusted tag set can represent the collection of valid tag information stored on the server; or it can be the collection of trusted tag information corresponding to the verification information obtained by the target application from trusted memory and sent to the server.

[0140] In practical applications, once the tag information of the second device is read, or if the tag information of the second device has not been read for a preset time, the server can generate new tag information and send it to the second device.

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

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

[0143] 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.

[0144] The notification information indicates the information generated by the second device after its tag information has been read. This reading can be categorized into two scenarios: one is a user reading the tag information of the second device using their own first device; the other is an unauthorized user reading the tag information of the second device. The original validity period can represent the server's default validity duration or the initial validity period set, such as 30 minutes or 2 hours; it can also be the most recently set validity duration. The new validity period indicates a shorter duration or time interval than the original validity period, for example, changing from the original 30 minutes to a shorter time such as 2 minutes or 20 seconds.

[0145] In practical applications, the server can generate tag information and set an initial validity period for the tag information; the tag information is sent to the second device. Within the initial validity period, after the tag information on the second device is read, the second device will send a notification message to the server. Upon receiving the notification message, the server can set a new validity period for the tag information. Optionally, as one implementation, the method described in the embodiments of this specification may further include:

[0146] If the judgment result indicates that the payment processing request does not meet the trust conditions, then information indicating a transaction anomaly is generated and fed back to the first device.

[0147] If the judgment result indicates that the payment processing request meets the trust condition, then the payment business processing request is executed, information indicating the execution result is generated and fed back to the first device.

[0148] In the embodiments of this specification, a payment processing request not meeting the trusted conditions can mean that the payment processing request does not meet the first trusted condition; it can also mean that the payment processing request does not meet the second trusted condition; or it can mean that the payment processing request does not meet both the first and second trusted conditions. A payment processing request meeting the trusted conditions can mean that the payment processing request meets the first trusted condition; it can also mean that the payment processing request meets the second trusted condition; or it can mean that the payment processing request meets both the first and second trusted conditions.

[0149] As one implementation, optionally, the payment processing request described in the embodiments of this specification includes the tag information; the method further includes: determining a second device for storing the tag information based on the tag information;

[0150] Determining whether the payment processing request meets the second trust condition may specifically include:

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

[0152] If the distance between the first device and the second device is less than or equal to a preset distance, then the payment processing request is determined to meet the second trust condition.

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

[0154] The server can obtain the second device's second location information after identifying the second device, or the second device can send its location information to the server in real time. The server can also store the second device's second location information. The first device can include its own first location information in the payment processing request it sends to the server, or the server can obtain the first device's first location information after receiving the payment processing request. In practical applications, the location information obtained by the server can be the device's real-time location information or the device's cached location information.

[0155] The distance can be calculated based on the first and second location information, and can represent the distance between the first and second devices. The distance can be expressed as an absolute value. The preset distance can be the same as the distance threshold value in the aforementioned embodiments; the preset distance can represent the maximum distance at which the first and second devices can perform near-field communication. The preset distance can be determined based on the NFC sensing distance or based on historical payment distances in historical payment data, and is not specifically limited here.

[0156] In the embodiments of this specification, payment transactions can also be processed by combining a first device with a server. Figure 5 is a flowchart of a payment transaction processing method provided in an embodiment of this specification. As shown in Figure 5, the solution may specifically include:

[0157] Step 502: The first device acquires the tag information used to trigger the payment transaction.

[0158] The tag information acquired by the first device can be obtained from the second device via NFC communication; alternatively, it can be sent to the first device after an unauthorized or compromised device has cracked the NFC device's tag information. The first device can be an NFC device with NFC tag or NFC communication capabilities. The tag information can include all or part of the information from the second device's NFC tag, such as token information, order information, etc.

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

[0160] The first preset condition can 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, then step 510 is executed: the payment transaction processing flow is terminated.

[0161] If the source of the tag information meets the first preset condition, the first device can execute step 506: determine whether the source of the tag information meets the second preset condition.

[0162] 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: terminate the payment transaction processing flow.

[0163] If the source of the tag information meets the second preset condition, the first device can also execute step 508: determine whether the source of the tag information meets the third preset condition.

[0164] The third preset condition can indicate that other devices exist within the preset range of the first device, specifically, that other Bluetooth devices exist within the Bluetooth range of the first device. If the source of the tag information does not meet the third preset condition, then step 510 is executed: the payment transaction processing flow is terminated.

[0165] In practical applications, the first device can determine whether the source of the tag information meets the preset conditions based on one or more of the first, second, and third preset conditions. If the determination of whether the credible source of the tag information meets the preset conditions is not based on the second preset condition, step 506 can be deleted; if the determination of the credibility of the tag information is based solely on the first preset condition, steps 506 and 508 can be deleted.

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

[0167] 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 the payment processing request.

[0168] Step 514: The server obtains the payment processing request sent by the first device. In this embodiment, the payment processing request is generated by the first device based on the obtained tag information used to trigger the payment transaction.

[0169] Step 516: Determine whether the payment processing request meets the trust conditions.

[0170] 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 time of obtaining the payment processing request is within the validity period of the tag information.

[0171] The second reliable condition can 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 tag information obtained by the first device. For details, please refer to the description in the above embodiments, which will not be repeated here.

[0172] If the payment processing request does not meet the trust conditions, the server can execute step 518: terminate the payment business processing flow; it can also execute step 520: generate information indicating a transaction error.

[0173] The server can generate information indicating a transaction error and send it to the first device. The first device can also execute step 522: The first device displays a prompt message indicating a transaction error.

[0174] If the first device is responsible for terminating the payment transaction process, it can also generate a message indicating a transaction error locally. If the server is responsible for terminating the payment transaction process, it can send the generated message indicating a transaction error back to the first device, and the first device will then display the message indicating a transaction error based on the received feedback from the server.

[0175] If the payment processing request meets the trust conditions, the server can execute step 524: the server executes the processing flow of the payment business corresponding to the payment processing request. The server can also execute step 526: generate the processing result information of the payment business.

[0176] The server can also send the processing result information of the payment transaction back to the first device, and the first device can execute step 528: the first device displays the processing result page of the payment transaction.

[0177] The processing results page is generated based on the payment transaction processing results reported by the server and is used to display the processing outcome to the user. This page can include two scenarios: successful transaction and failed transaction. It can display the reason for the failed transaction, such as insufficient account balance or unstable network connection.

[0178] In practical applications, during the time the server processes the payment request, the first device can display a full-screen payment page or a secure payment page that occupies part of the screen. This page can display promotional information related to near-field payment methods or payment order information; no specific limitations are made here. It is understood that the various embodiments in this specification provide multiple methods for verifying tag information or payment requests. In practical applications, one or more methods can be selected for verification, and the execution order of multiple verification methods can be set according to actual needs.

[0179] The same concepts or features present in this embodiment as those in the above embodiments can be referred to the descriptions of the above embodiments, and will not be repeated here. 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.

[0180] The methods provided in the embodiments of this specification can effectively prevent unauthorized users from using the tag information, such as link information, obtained from NFC devices to engage in harmful activities, thereby improving payment security. The server can be a server with payment processing capabilities, specifically a server for NFC payments. The tag information may include the server's domain name information. In one implementation, the server can process each obtained payment processing request according to the methods provided in this specification. In another implementation, the payment processing request obtained by the server may contain a preset string, and the server can process payment processing requests containing this preset string according to the methods provided in this specification.

[0181] Using the above method, the first device can determine whether the source of the tag information is trustworthy based on at least one of the preset conditions. If the source of the tag information is trustworthy, it can send a payment processing request to the server. After receiving the request, the server can determine whether to process the request based on at least one of the trustworthy conditions. This allows the device to determine whether the payment transaction is abnormal from multiple dimensions and angles, thereby reducing the risk of user account funds being stolen or defrauded and improving transaction security.

[0182] Based on the same idea, embodiments of this specification also provide an apparatus corresponding to the above method. Figure 6 is a schematic diagram of the structure of a payment processing apparatus corresponding to Figure 2 provided in an embodiment of this specification. As shown in Figure 6, the apparatus may include:

[0183] The tag information acquisition module 602 is used to acquire tag information used to trigger payment transactions;

[0184] The preset condition judgment module 604 is used to judge whether the source of the tag information meets the preset conditions and obtain the judgment result; the preset conditions include 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.

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

[0186] Based on the apparatus shown in Figure 6, this specification also provides some specific implementation schemes of the method, which will be described below.

[0187] Optionally, the device may further include a business processing flow execution module, which may be used to: if the judgment result indicates that the source of the tag information meets the preset conditions, then send a payment processing request to the server; the server can execute the payment business processing flow based on the payment processing request.

[0188] Optionally, the preset condition judgment module further includes a first preset condition judgment unit, which can be used to: determine whether the trusted memory of the first device contains verification information that matches 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 contain verification information that matches the tag information, then it is determined that the source of the tag information does not meet the first preset condition.

[0189] Optionally, the first preset condition judgment unit may further include a tag information processing subunit, which may be used to: process the tag information according to preset data rules to obtain target verification information; 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 rules.

[0190] Optionally, the preset data rules include the NFC data exchange format.

[0191] Optionally, the device can also be used to delete verification information that matches the tag information in the trusted memory.

[0192] Optionally, the preset condition judgment module further includes a second preset condition judgment unit, which can be used to: obtain the system identification information of the first device; determine whether the system identification information is in a preset whitelist; the preset whitelist includes the system identification information of multiple device systems with near-field communication function; if the system identification information is not in the preset whitelist, then determine that the source of the tag information does not meet the second preset condition.

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

[0194] Optionally, the business processing execution module can also be used to enable the server to execute a corresponding payment business processing flow based on the location relationship between the first device and the second device used to store the tag information.

[0195] Optionally, the preset conditions in the device may further include a third preset condition; the third preset condition is that other devices exist within the near-field communication range of the first device.

[0196] Optionally, the preset condition judgment module further includes a third preset condition judgment unit, which can be used to: determine whether there are other Bluetooth devices within the Bluetooth range of the first device; if there are no other Bluetooth devices within the Bluetooth range of the first device, then determine that the tag information does not meet the third preset condition.

[0197] Optionally, the device further includes a prompt information display module, which can be used to display prompt information indicating transaction abnormalities.

[0198] Based on the same idea, embodiments of this specification also provide an apparatus corresponding to the above method. Figure 7 is a schematic diagram of the structure of a payment processing apparatus corresponding to Figure 4 provided in an embodiment of this specification. As shown in Figure 7, the apparatus may include:

[0199] The payment processing request acquisition module 702 is used to acquire a payment processing request sent by the first device, wherein the payment processing request is generated by the first device based on the acquired tag information used to trigger the payment business;

[0200] The trust condition judgment module 704 is used to judge whether the payment processing request meets the trust condition and obtain the judgment 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 used to store the tag information is less than or equal to a preset distance.

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

[0202] Based on the apparatus in Figure 7, this specification also provides some specific implementation schemes of the method, which will be described below.

[0203] Optionally, the device can also be used to: if the judgment result indicates that the payment processing request meets the trusted condition, then execute the payment business processing flow corresponding to the payment processing request and feed back the processing result information to the first device.

[0204] Optionally, the trust condition judgment module may further include a first trust condition judgment unit, wherein the payment processing request contains the identification information of the tag information, specifically used for: determining the validity period of the tag information based on the identification 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, then determining that the payment processing request does not meet the first trust condition.

[0205] Optionally, the device may further include an expiration date sending module, which can be used to: generate the tag information, record the expiration date of the tag information, and send the tag information to a second device.

[0206] Optionally, the device may further include a validity period update module, which can be used to: obtain notification information sent by the second device indicating that the tag information has been read; based on the notification information, change the validity period of the recorded tag information to a new validity period; the duration of the new validity period is less than the validity period of the recorded tag information.

[0207] Optionally, the device may further include a transaction anomaly feedback module, which can be used to: if the judgment result indicates that the payment processing request does not meet the trust conditions, generate information indicating a transaction anomaly and feed it back to the first device.

[0208] Optionally, the second trust condition determination unit, wherein the payment processing request includes the tag information, can be specifically used to: determine a second device for storing the tag information based on the tag information; determine 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 the preset distance, determine that the payment processing request satisfies the second trust condition; if the distance between the first device and the second device is greater than the preset distance, determine that the payment processing request does not satisfy the second trust condition.

[0209] Based on the same idea, this specification also provides devices corresponding to the above methods in its embodiments.

[0210] Figure 8 is a schematic diagram of the structure of a payment processing device provided in an embodiment of this specification. As shown in Figure 8, the device 800 may include: at least one processor 810; and a memory 830 communicatively connected to the at least one processor; the memory 830 stores instructions 820 that can be executed by the at least one processor 810, and 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 processing method.

[0211] Based on the same approach, embodiments of this specification also provide a computer-readable medium corresponding to the above-described method. The computer-readable medium stores computer-readable instructions that can be executed by a processor to implement the above-described payment transaction processing method.

[0212] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to interchangeably. Each embodiment focuses on describing the differences from other embodiments. The descriptions of parts in the method using a first device as the execution subject that are the same as or similar to those in the method using a server as the execution subject are relatively simple; these can be referred to in the embodiment section of the method using a server as the execution subject. For the devices and apparatus shown above, since they are basically similar to the method embodiments, the descriptions are relatively simple; relevant parts can be referred to in the descriptions of the method embodiments.

[0213] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to the methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to the hardware circuit structure. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program and "integrate" a digital system onto a PLD themselves, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, 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, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0214] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0215] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices. For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware. Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Moreover, the present invention can 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.

[0216] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in one or more blocks of the flowchart illustrations and / or one or more blocks of the block diagrams.

[0217] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means that implement the functions specified in one or more flowcharts and / or one or more block diagrams. These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process, such that the instructions, which execute on the computer or other programmable apparatus, provide steps for implementing the functions specified in one or more flowcharts and / or one or more block diagrams.

[0218] In a typical configuration, a computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory. Memory may include non-persistent storage in computer-readable media, random access memory (RAM), and / or non-volatile memory such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media. Computer-readable media includes both permanent and non-persistent, removable and non-removable media that can store information by any method or technology. Information can be computer-readable instructions, data structures, modules of programs, 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 technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transfer medium that can be used to store information that can be accessed by the computing device. As defined in this article, computer-readable media do not include transient media, such as modulated data signals and carrier waves.

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

[0220] Those skilled in the art will understand that embodiments of this application can be provided as methods, systems, or computer program products. Therefore, this application can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, this application can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0221] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0222] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A method for processing a payment service, comprising: obtaining, by a first device, label information for triggering a payment service; determining whether a source of the label information meets a preset condition to obtain a determination 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 by a near field communication (NFC) communication mode; the second preset condition is that the first device has an NFC communication function; and terminating execution of a processing flow of the payment service if the determination result indicates that the source of the label information does not meet the preset condition. 2.The method of claim 1, further comprising: sending a payment processing request to a server if the determination result indicates that the source of the label information meets the preset condition; and the server is capable of executing the processing flow of the payment service based on the payment processing request. 3.The method of claim 1, wherein the label information comprises identification information of a target application; and the method further comprises: arousing the target application by the first device through the identification information; and the determining whether the source of the label information meets the preset condition comprises: determining whether the source of the label information meets the preset condition based on the started target application. 4.The method of claim 1, wherein the determining whether the source of the label information meets the first preset condition comprises: determining whether the trusted memory of the first device contains verification information matching the label information; and the trusted memory is a trusted memory for storing verification information of information obtained by the first device through the near field communication. 5.The method of claim 4, wherein the determining whether the trusted memory of the first device contains the verification information matching the label information comprises: processing the label information according to a preset data rule to obtain target verification information; and determining whether the trusted memory of the first device contains the target verification information; and the verification information stored in the trusted memory is obtained by processing information obtained by the first device through the near field communication according to the preset data rule. 6.The method of claim 5, wherein the preset data rule comprises a NFC data exchange format. 7.The method of claim 4, further comprising: deleting the verification information matching the label information in the trusted memory. 8.The method of claim 4, wherein the verification information in the trusted memory has a verification validity period; and the method further comprises: deleting the verification information in the trusted memory if a time of storing the verification information in the trusted memory exceeds the verification validity period. 9.The method of claim 1, wherein the determining whether the source of the label information meets the second preset condition comprises: obtaining system identification information of the first device; and determining whether the system identification information is located in a preset white list; and the preset white list comprises system identification information of a plurality of device systems having a near field communication function. ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ ​ 10. The method of claim 7, wherein the system identification information comprises at least one of a system package name, a package signature, a terminal model, and a terminal name.

11. The method of claim 2, wherein the server is further configured to execute a corresponding payment service processing procedure according to a positional relationship between the first device and a second device configured to store the tag information.

12. The method of claim 1, wherein the preset condition further comprises a third preset condition, and the third preset condition is that there is another device within a near field communication range of the first device.

13. The method of claim 12, wherein determining whether the source of the tag information satisfies the third preset condition comprises: determining whether there is another Bluetooth device within a Bluetooth range of the first device; and determining that the tag information does not satisfy the third preset condition if there is no other Bluetooth device within the Bluetooth range of the first device.

14. The method of claim 1, wherein the preset condition further comprises a fourth preset condition, and the fourth preset condition is configured to indicate that a distance between the first device and a second device configured to store the tag information satisfies a distance threshold.

15. The method of claim 1, further comprising: displaying prompt information indicating a transaction exception.

16. The method of claim 15, wherein the prompt information indicating the transaction exception comprises at least one of information prompting a user of the transaction exception, information of a reason of the transaction exception, and prompt information prompting the user to use NFC payment.

17. The method of claim 1, wherein the tag information comprises a URL link.

18. The method of claim 1, further comprising: receiving execution result information of the payment service processing procedure fed back by the server, and the execution result information comprises at least one of information indicating payment success, payment failure, or payment exception.

19. A payment service processing method, comprising: obtaining a payment processing request sent by a first device, wherein the payment processing request is generated by the first device based on obtained tag information configured to trigger a payment service; determining whether the payment processing request satisfies a trusted condition to obtain a determination result, wherein the trusted condition comprises 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 a validity period of the tag information, and the second trusted condition is that a distance between a device sending the payment processing request and a second device configured to store the tag information is less than or equal to a preset distance; and terminating a processing procedure of the payment service corresponding to the payment processing request if the determination result indicates that the payment processing request does not satisfy the trusted condition.

20. The method of claim 19, further comprising: executing a payment service processing procedure corresponding to the payment processing request and feeding back processing result information to the first device if the determination result indicates that the payment processing request satisfies the trusted condition. ​ ​ ​ ​ ​ ​ ​ ​ 21. The method of claim 19, wherein the payment processing request comprises identification information of the label information. determining whether the payment processing request satisfies a first trusted condition, specifically comprising: determining, based on the identification information, a validity period of the label information; determining whether an acquisition time of the payment processing request is within the validity period.

22. The method of claim 19, further comprising: generating the label information, recording a validity period of the label information; sending the label information to a second device.

23. The method of claim 22, further comprising: acquiring notification information sent by the second device, the notification information indicating that the label information has been read; based on the notification information, changing the recorded validity period of the label information to a new validity period; the new validity period has a time length shorter than the recorded validity period of the label information.

24. The method of claim 19, further comprising: if the determination result indicates that the payment processing request does not satisfy a trusted condition, generating information indicating a transaction exception and feeding back to the first device.

25. The method of claim 19, wherein the payment processing request comprises the label information; the method further comprises: determining, based on the label information, a second device for storing the label information; determining whether the payment processing request satisfies a second trusted condition, specifically comprising: determining whether a distance between the first device and the second device is less than or equal to a preset distance.

26. The method of claim 19, wherein the payment processing request is generated based on the label information after the first terminal determines that the label information satisfies a preset condition; 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 acquired through an NFC communication mode; the second preset condition is that the first device has an NFC communication function.

27. A payment service processing apparatus, comprising: a label information acquisition module configured to acquire label information for triggering a payment service; a preset condition determination module configured to determine whether a source of the label information satisfies a preset condition, to obtain a determination 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 acquired through an NFC communication mode; the second preset condition is that the first device has an NFC communication function; a processing flow termination module configured to terminate a processing flow of the payment service if the determination result indicates that the source of the label information does not satisfy the preset condition.

28. A payment service processing apparatus, comprising: a payment processing request acquisition module configured to acquire a payment processing request sent by a first device, the payment processing request being generated by the first device based on acquired label information for triggering a payment service; a trusted condition judging module, configured to judge whether the payment processing request meets a trusted condition, and obtain a judgment result; the trusted condition comprises 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 a valid period of the label information, and the second trusted condition is that a distance between a device sending the payment processing request and a second device storing the label information is less than or equal to a preset distance; a processing flow terminating module, configured to terminate a processing flow of the payment business corresponding to the payment processing request if the judgment result indicates that the payment processing request does not meet the trusted condition.

29. A payment business processing device, comprising: at least one processor; and a memory connected with the at least one processor in communication; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform the payment business processing method in any one of claims 1 to 26.

30. A computer readable medium having computer readable instructions stored thereon, the computer readable instructions being executable by a processor to implement the payment business processing method in any one of claims 1 to 26.

Images