Payment service processing method, apparatus and device, and medium

Abstract

Disclosed in embodiments of the description are a payment service processing method, apparatus and device, and a medium. The solution comprises: acquiring a payment processing request sent by a first device, the payment processing request comprising tag information stored in an NFC tag of a second device; on the basis of the tag information, determining the second device for storing the tag information; determining whether the distance between the first device and the second device is less than or equal to a preset distance to obtain a first determination result; on the basis of the first determination result, generating processing result information corresponding to the payment processing request; and feeding back the processing result information to the first device.

Description

A method, apparatus, equipment and medium for payment transaction processing

[0001] This application claims priority to Chinese Patent Application No. 202411047325.5, filed on July 31, 2024, entitled "A Method, Apparatus, Equipment and Medium for Payment Transaction Processing", 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, device and medium for payment processing. Background Technology

[0003] With the development of computer technology, more and more business transactions can be processed through mobile terminals, such as online payments and QR code payments for public 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 subway and bus fares. 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 payment processing to address the payment risk issues inherent in existing payment 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 transaction processing method, including:

[0008] Obtain a payment processing request sent by a first device; the payment processing request includes tag information for storage in an NFC tag on a second device;

[0009] Based on the tag information, a second device for storing the tag information is determined;

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

[0011] Based on the first judgment result, the processing result information corresponding to the payment processing request is generated;

[0012] The processing result information is fed back to the first device.

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

[0014] The first device acquires tag information used to process payment transactions;

[0015] Based on the tag information, a payment processing request is sent to the server; the server is able to execute a payment business processing flow based on the location relationship between the first device and the second device used to store the tag information and return the processing result information in response to the payment processing request.

[0016] Based on the processing result information provided by the server, the payment transaction processing result page is displayed.

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

[0018] The payment processing request acquisition module is used to acquire a payment processing request sent by the first device; the payment processing request includes tag information for storage in the NFC tag of the second device;

[0019] The second device determination module is used to determine a second device for storing the tag information based on the tag information;

[0020] The distance judgment module is used to determine whether the distance between the first device and the second device is less than or equal to a preset distance, and to obtain a first judgment result;

[0021] The processing result information generation module is used to generate processing result information corresponding to the payment processing request based on the first judgment result;

[0022] The processing result information feedback module is used to feed back the processing result information to the first device.

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

[0024] The tag information acquisition module is used to acquire tag information for processing payment transactions;

[0025] A payment processing request sending module is used to send a payment processing request to the server based on the tag information; the server is able to execute a payment business processing flow based on the location relationship between the first device and the second device used to store the tag information and return the processing result information in response to the payment processing request.

[0026] The page display module is used to display the payment transaction processing result page based on the processing result information provided by the server.

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

[0028] At least one processor; and,

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

[0030] The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform a method for processing a payment transaction.

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

[0032] At least one embodiment in this specification can achieve the following beneficial effects: by obtaining the tag information contained in the payment processing request sent by the first device, a second device for storing the tag information is determined. If the distance between the first device and the second device is less than or equal to a preset distance, processing result information corresponding to the payment processing request can be generated, and this processing result information can be fed back to the first device. In the NFC payment scenario, due to the short communication distance of NFC, the distance between the first device and the second device providing NFC tag information should normally be relatively close. In the embodiments of this specification, the distance between the first device and the second device can be used to determine whether there is a risk in the current transaction, thereby reducing the risk of user funds being defrauded or stolen, and improving the security of payment services. Attached Figure Description

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

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

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

[0036] Figure 3 is a schematic diagram of a processing result page provided in an embodiment of this specification;

[0037] Figure 4 is a swimlane diagram of a payment transaction processing method provided in an embodiment of this specification;

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

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

[0040] Figure 7 is a structural schematic diagram of a payment transaction processing device corresponding to Figure 5 provided in the embodiments of this specification;

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

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

[0043] NFC payment is a mobile payment method based on near-field communication technology. Users can use NFC-enabled devices to make 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.

[0044] In practical applications, users can use the NFC reader mode set in their terminals to read payment links on merchant devices containing NFC tags, thus completing payments based on these links. However, some unauthorized users may crack the tag information in the NFC tags on merchant devices to obtain payment links, then repackage or directly forward these links to users. This could lead to users clicking on links sent by unauthorized users through other devices, completing financial transactions, and potentially resulting in theft or fraud.

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

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

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

[0048] As shown in Figure 1, this solution may 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. For example, the second device 3 may have a built-in NFC tag, or the NFC tag may be separate from the second device. The second device can write tag information into the NFC tag or modify the tag information in the NFC tag. In practical applications, the first device can obtain the tag information in the second device by bringing it close to the second device, such as by touching or tucking the two devices together. The first device 1 can then send a payment processing request generated based on the obtained tag information to the server 2. The server 2 can determine the corresponding second device 3 based on the tag information contained in the payment processing request sent by the first device 1. Then, based on the positions of the first device 1 and the second device 3, it determines whether the distance between them is less than or equal to a preset distance. The server 2 can process the payment processing request according to the determination result and obtain the processing result information.

[0049] In practical applications, there may be some unconventional operations. For example, an unauthorized user may crack the tag information in the second device and obtain the payment link information contained in the tag information. The user may then package the payment link information through other devices or send it directly to the first device. The first device may then generate a payment processing request based on the payment link information sent by other devices and send it to the server.

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

[0051] Figure 2 is a schematic flowchart of a payment transaction processing method provided in an embodiment of this specification. From a program perspective, the entity executing the process can be a program hosted on an application server or an application client.

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

[0053] Step 202: Obtain the payment processing request sent by the first device; the payment processing request includes tag information for storage in the NFC tag of the second device.

[0054] In the embodiments of this specification, the first device can be a user terminal device running iOS or Android, or it can be a user terminal device running other systems such as HarmonyOS, such as mobile phones, computers, smartwatches, and other smart wearable devices. The first device can have the function of reading NFC tags, acting as a card reader to read the tag information in the NFC tag. The second device can be a device associated with the NFC tag; for example, the second device can contain the NFC tag, or it can connect to other devices containing NFC tags via wired or wireless means to record or modify the tag information in the NFC tag. The tag information can be a string conforming to preset rules, such as a link, like a URL link. The tag information can include identification information representing the second device, order identification information, or token information generated based on the tag information, etc. The specific content of the tag information is not specifically limited here.

[0055] In practical applications, the server can generate tag information based on business needs and send it to the second device, so that the second device can store the tag information in an associated NFC tag. The second device is a device that can interact normally with the server; it can be understood as a device that has been registered with the server.

[0056] The payment processing request is generated by the first device based on the acquired tag information. This acquired tag information can be obtained by the first device through NFC communication between the second device, which stores the NFC tag, or it can be the tag information sent to the first device by an unauthorized user after cracking the NFC tag of the second device through other devices or methods.

[0057] The payment processing request may include all the information in the tag information, or it may include some of the information in the tag information, or it may include relevant information about the first device, etc.

[0058] Step 204: Based on the tag information, determine a second device for storing the tag information.

[0059] In the embodiments described in this specification, the server can generate tag information according to business needs and send it to the second device. It can also save the correspondence between the tag information and the second device receiving the tag information. The corresponding second device can be found based on the tag information using this correspondence.

[0060] For example, in an NFC payment scenario, the merchant's POS system can connect to a second device. After the cashier confirms 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, without specific limitations.

[0061] Step 206: Determine whether the distance between the first device and the second device is less than or equal to a preset distance, and obtain the first determination result.

[0062] The server can obtain the second location information of the second device after identifying it, or the second device can send its location information to the server in real time. The server can also store the second location information of the second device. The first device can include its own first location information in the payment processing request sent to the server, or the server can obtain the first device's first location information after receiving the payment processing request sent by the first device. The first and second location information can be location information obtained based on Location-Based Services (LBS), location information obtained through positioning systems such as Global Positioning System (GPS) and BeiDou Navigation Satellite System (BDS), or location information obtained through the device's connected Wi-Fi or Bluetooth.

[0063] In practical applications, the location information obtained by the server can be the device's real-time location information or the location information cached by the device.

[0064] The distance in the embodiments of this specification can be calculated based on the first location information and the second location information, and can represent the distance between the first device and the second device. The distance can be expressed in absolute value form. The preset distance can be determined based on the NFC sensing distance or based on the historical payment distance in historical payment data, and is not specifically limited here.

[0065] Step 208: Based on the first judgment result, generate the processing result information corresponding to the payment processing request.

[0066] In the embodiments of this specification, if the first judgment result indicates that the distance between the first device and the second device is less than or equal to a preset distance, it means that the distance between the first device and the second device is relatively close, and the generated payment processing request is secure. The server can respond to the payment processing request sent by the first device to generate corresponding processing result information. If the first judgment result indicates that the distance between the first device and the second device is greater than the preset distance, it means that the distance between the first device and the second device is relatively far, exceeding the normal NFC payment distance. This indicates that there is an abnormal situation in the current payment and there is a payment risk. The server may not respond to the payment processing request sent by the first device, or it may respond to the payment processing request sent by the first device but not perform subsequent transaction processing, and no actual resource transfer will occur. It can generate processing result information indicating transaction failure or abnormality.

[0067] In practical applications, tag information can be an accessible link. Unauthorized users may use illegal means to crack the tag information stored in a second device and send it to the user device via instant messaging applications or web pages that can carry tag information. If the user clicks on the obtained tag information, such as a link, the user device can also send a payment processing request to the server. In this case, the distance between the second device and the user's first device will exceed the normal NFC payment distance, confirming that the payment processing request sent by the user is risky.

[0068] Step 210: Feed back the processing result information to the first device.

[0069] In the embodiments described in this specification, if the payment processing request is risk-free, the server can process the request and return information indicating a successful transaction. The first device can display a result page indicating a successful transaction, which may include transaction amount information, payment method, counterparty information, etc. If the payment processing request is risky, information indicating a transaction error or failure can be returned. The first device can display a result page indicating a transaction error or failure, which may include transaction amount information, and the reason for the transaction error or failure, etc.

[0070] 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. Furthermore, the information obtained in the various embodiments of this specification is obtained and used with user authorization.

[0071] The method in Figure 2 obtains the tag information contained in the payment processing request sent by the first device, identifies the second device storing the tag information, and then determines the distance between the first and second devices. It then checks whether the distance is less than or equal to a preset distance, processes the payment processing request based on the result, obtains the payment processing result information, and sends it back to the first device. In NFC payment scenarios, due to the short communication distance of NFC, the distance between the first device and the second device providing the NFC tag information should normally be relatively close. In this embodiment, the distance between the first and second devices can be used to determine whether the payment processing request poses a risk, thus preventing fraud or theft of user funds by illegal elements, protecting user funds, and improving payment security.

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

[0073] As one implementation method, optionally, the generation of processing result information corresponding to the payment processing request based on the first determination result in the embodiments of this specification may specifically include:

[0074] If the first determination result indicates that the distance is less than or equal to the preset distance, then the payment processing procedure is executed;

[0075] Based on the payment processing flow, payment result information representing the payment result is generated.

[0076] The payment processing flow in the embodiments of this specification can represent the process for processing payment processing requests, such as 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. Payment results can exist in two forms: one is a successful payment result, which can generate payment result information containing transaction amount information, and may also include information such as the merchant name and user payment account name, so that the transaction result page can be displayed on the first device; the other is a failed payment result, which can generate payment result information containing information such as the reason for payment failure. Reasons for payment failure may include network errors, insufficient user account balance, payment timeout, etc., or other reasons for payment failure, which will not be listed here.

[0077] As one implementation method, optionally, the generation of processing result information corresponding to the payment processing request based on the first determination result in the embodiments of this specification may specifically include:

[0078] If the first judgment result indicates that the distance is greater than the preset distance, then information indicating a payment anomaly is generated.

[0079] In the embodiments of this specification, if the first judgment result indicates that the distance between the first device and the second device is greater than a preset distance, it can mean that the first device and the second device have exceeded the normal distance for NFC payment, and the payment processing process can be terminated or not started. Payment anomaly information can be a message indicating an abnormal situation in the current transaction to the user. In addition to generating payment anomaly information, the server can also generate prompts to prompt the user to use near-field communication for payment; it can also generate prompts indicating that a clicked link poses a risk, etc.

[0080] To clearly illustrate the display page of the prompt information, Figure 3 is a schematic diagram of a processing result page 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."

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

[0082] As one implementation method, to further improve transaction security, the security of the transaction can also be determined by the validity period of the tag information. Optionally, before generating the processing result information corresponding to the payment processing request as described in the embodiments of this specification, the following may also be included:

[0083] Determine the generation time of the tag information;

[0084] Determine the request time of the payment processing request;

[0085] Based on the generation time, it is determined whether the request time is within the validity period of the tag information, and a second determination result is obtained;

[0086] The generation of the processing result information corresponding to the payment processing request may specifically include:

[0087] If the first judgment result indicates that the distance is less than or equal to the preset distance, and the second judgment result indicates that the request time is within the validity period of the tag information, then the payment processing procedure is executed;

[0088] Based on the payment processing flow, payment result information representing the payment result is generated.

[0089] In practical applications, the server can generate tag information according to business needs and send it to the second device. The server can also record this tag information and its generation time, and can set the tag's validity period, such as 30 minutes, 10 minutes, etc., after generation. An expiration time can also be set, representing the time period between generation and expiration. The tag information can also include a timestamp of its generation time. The server can query the tag's generation time from stored information based on the tag information included in the payment processing request, or determine the generation time by parsing the timestamp of the tag information included in the payment processing request.

[0090] The request time can represent the time when the first device generates the payment processing request. For example, the payment processing request can contain the timestamp information of the request generation. It can also represent the time when the server can receive the payment processing request.

[0091] The validity period can represent the effective duration or time period of the tag information. The validity period can be determined based on historical data or expert experience. If the validity period represents the effective duration of the tag information, a second judgment result can be obtained by comparing the difference between the request time and the generation time with the effective duration. If the validity period represents the effective time period of the tag information, a second judgment result can be obtained by determining whether the request time falls within the time period between the generation time and the expiration time.

[0092] In practical applications, after determining that the distance between the first device and the second device is less than or equal to a preset distance, it can be determined whether the request time is within the validity period of the tag information; alternatively, both can be determined simultaneously, or the distance can be determined to be less than or equal to the preset distance after determining that the request time is within the validity period of the tag information.

[0093] In practical applications, the aforementioned processes for determining payment based on distance and validity period can be executed independently, without needing to be executed in their entirety. For example, if the distance between the first and second devices is detected to be greater than a preset distance, the payment processing process can be terminated or not initiated; or, if the request time is detected to be outside the validity period of the tag information, the payment processing process can also be terminated or not initiated. The execution of the payment processing process can be referenced to the same or similar parts in the above embodiments, and will not be elaborated further here.

[0094] The server can set the validity period based on the required duration of the NFC payment link. Specifically, the payment link duration can be determined based on the generation time and the time of payment completion, and this payment link duration will be used as the validity period of the tag information.

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

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

[0097] Based on the notification information, the validity period of the tag information is set to a preset duration.

[0098] In the embodiments of this specification, the notification information can represent information generated by the second device after the tag information in the second device is read. This reading can be divided into two scenarios: one is that a user reads the tag information of the second device using a first device they hold; the other is that an unauthorized user reads the tag information of the second device. After receiving the notification information, the server can set the validity period of the tag information to a preset duration. This preset duration can be set based on the time required for the server to historically execute NFC payment processes, or it can be set based on expert experience.

[0099] In practical applications, several differences between notification times and generation times can be determined based on historical data, an average value can be calculated, and an increment can be added to the average value to obtain the preset validity period. Alternatively, the maximum value from several differences can be selected and an increment added to obtain the preset validity period. The start time of the tag information is the generation time of the tag information generated by the server, and the corresponding end time can be determined based on the generation time and the preset validity period. The preset validity period can also be determined by other methods, such as expert experience, etc., without specific limitations here. It is understandable that after the tag information is read, the server will generate new tag information for the second device to improve payment security.

[0100] To enhance security, the tag's validity period can be shortened after it is read. This prevents unauthorized users from sending the obtained link to the first device after cracking the tag information stored in the second device. In such cases, the server would take longer to receive the payment processing request than a normal NFC payment. Therefore, the validity period can be shortened according to the required NFC payment time to ensure payment security.

[0101] As one implementation method, the preset validity period can be shortened according to actual circumstances. Optionally, setting the validity period of the label information to a preset duration as described in the embodiments of this specification may specifically include:

[0102] The original validity period of the label information is set as the new validity period; the duration of the new validity period is shorter than the duration of the original validity period.

[0103] In the embodiments of this specification, the original validity period can represent the server's default validity period or the initial validity period set, such as 30 minutes, 2 hours, etc.; it can also be the validity period set most recently. The new validity period represents a shorter duration or time period than the original validity period, such as changing the original validity period of 30 minutes to a shorter time such as 2 minutes, 20 seconds, etc.

[0104] In practical applications, the server can set an original validity period for the tag information during the tag information generation process; after the tag information is sent to the second device, the second device will send a notification message to the server after the tag information is read within the original validity period. After receiving the notification message, the server can set a new validity period for the tag information.

[0105] In practical applications, the new validity period can be set as a time period, with the start time set to the tag information's generation time. The end time is determined and set based on the validity period's duration and the generation time. For example, based on the tag information's generation time, the start time of the new validity period can be set to May 1, 2024, at 10:11 AM, and the end time can be set to May 1, 2024, at 10:13 AM. Alternatively, the new validity period can be set as a duration, such as setting the duration to 2 minutes; no specific limitation is made here.

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

[0107] If the second judgment result indicates that the request time is not within the validity period of the tag information, then information indicating payment abnormality is generated;

[0108] Alternatively, if the first determination result indicates that the distance is greater than the preset distance, then information indicating a payment anomaly is generated;

[0109] Alternatively, if the first judgment result indicates that the distance is greater than the preset distance and the second judgment result indicates that the request time is not within the validity period of the tag information, then information indicating payment abnormality is generated.

[0110] In the embodiments of this specification, if at least one of the following conditions is met—that the distance between the first device and the second device is greater than a preset distance, and that the request time is not within the validity period of the tag information—the payment processing procedure may not be executed or may be terminated, and a payment processing result indicating a payment error may be generated. The information indicating a payment error may be a prompt to the user to re-enter the payment; it may also be a prompt to the user to complete the payment via NFC near-field payment; or it may be a prompt to the user indicating payment failure, etc.

[0111] To more clearly illustrate the payment processing method provided in the embodiments of this specification, Figure 4 is a swimlane diagram of the payment processing method provided in the embodiments of this specification. As shown in Figure 4, the solution may include an information acquisition stage, a payment processing stage, and an information feedback stage, specifically including:

[0112] Step 402: The first device acquires tag information for processing payment transactions.

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

[0114] In practical applications, the first device can act as an NFC card reader, sending trigger information to initiate near-field communication, such as NFC communication. When it is close to the second device, such as by placing it against the second device, it receives tag information from the second device in response to the trigger information, used for processing payment transactions. The second device has an NFC tag containing the tag information.

[0115] Step 404: The first device sends a payment processing request to the server based on the tag information.

[0116] The first device can generate a payment processing request containing the tag information based on the tag information, and send the generated payment processing request to the server so that the server can process the payment processing request.

[0117] Step 406: The server obtains a payment processing request sent by the first device, the payment processing request containing tag information for storage in the NFC tag of the second device.

[0118] Step 408: The server determines the second device storing the tag information based on the tag information.

[0119] The server can store the correspondence between tag information and second devices, and can determine the second device corresponding to the tag information based on the correspondence.

[0120] Step 410: The first device sends its first location information to the server.

[0121] The tag information in the embodiments of this specification may include identification information for launching a target application, which may be an application with payment processing functions. The first device can invoke the target application on the first device based on the identification information, and obtain the first location information of the first device based on the target application.

[0122] The identification information can be information used to uniquely identify the target application. The first device can obtain the LBS information of the first device to determine the first location information, and send the first location information to the server through the target application. The first device can wake up the target application based on the front-end wake-up method or the back-end wake-up method. The specific method used to wake up the target application is not specifically limited here.

[0123] In one implementation, the first device in this embodiment can also send a location acquisition request to a location server, obtain real-time location information provided by the location server, and send the real-time location information to the server. The location server is a server capable of providing location information.

[0124] The location provided by the location server can be obtained based on LBS, or based on the positioning system; it can also be obtained from other authorized applications that can obtain the location information of the first device, without specific limitations here.

[0125] As one implementation method, in this embodiment of the specification, if the real-time location information of the first device is not obtained within a preset time period after obtaining the tag information, the cached location information is obtained from the cache of the first device; and the cached location information is sent to the server.

[0126] The preset time period can be a pre-set duration for limiting the acquisition of the first device's real-time location information. The first device can cache the acquired location information in a cache. The cached location information can represent the latest location information of the first device stored in the device's cache.

[0127] Step 412: The second device sends its second location information.

[0128] In the embodiments of this specification, the second location information may be obtained by the second device after receiving a location acquisition request from the server, and then sent to the server in the manner described above; alternatively, the server may determine the second location information of the second device corresponding to the tag information based on the known device location information, such as a list of location information of each second device, using the tag information.

[0129] Step 414: The server determines whether the distance between the first device and the second device is less than or equal to the preset distance.

[0130] The server can determine whether the distance between the first device and the second device is less than or equal to a preset distance based on the first and second locations. If the distance is less than or equal to the preset distance, then step 416 is executed: determine the generation time of the tag information.

[0131] If the distance is greater than the preset distance, then step 422 is executed: generate information indicating payment abnormality.

[0132] Specifically, this could be information used to inform users of the reason for the error, or information used to inform users of a failed transaction, etc.

[0133] The first device can also obtain information from the server indicating payment abnormalities and execute step 428: display the payment transaction processing result page.

[0134] Step 418: The server determines the request time for the payment processing request.

[0135] Step 420: The server determines whether the request time is within the validity period of the tag information based on the generation time.

[0136] If the request time is not within the validity period of the tag information, step 422 can be executed; if the request time is within the validity period of the tag information, step 424 can be executed: the server executes the payment processing flow.

[0137] In addition to the methods described above, the embodiments of this specification may also determine whether there are other Bluetooth devices within the Bluetooth range of the first device, and obtain a third determination result; if the third determination result indicates that there are no other Bluetooth devices within the Bluetooth range of the first device, then the access to the server is terminated; if the third determination result indicates that there are other Bluetooth devices within the Bluetooth range of the first device, then a payment processing request is sent to the server.

[0138] In this context, "terminating access to the server" can mean that the first device will not send a payment processing request to the server.

[0139] In another implementation, the first device can also send information about other Bluetooth devices to the server. After receiving this information, the server identifies the second device's Bluetooth device based on the tag information and determines whether the other Bluetooth devices contain the second device's Bluetooth device. If the other Bluetooth devices contain the second device's Bluetooth device, the server can execute the payment processing procedure. If the other Bluetooth devices do not contain the second device's Bluetooth device, the server terminates or does not initiate the payment processing procedure.

[0140] The first device can also send the third judgment result back to the server, which can then determine whether to execute the payment processing procedure based on the third judgment result. Specifically, if the server receives a third judgment result indicating that no other Bluetooth devices exist within the first device's Bluetooth range, the payment processing procedure will not be initiated or will be terminated; or, if the server receives a third judgment result indicating that other Bluetooth devices exist within the first device's Bluetooth range, it will then determine whether the second device's Bluetooth device exists among these other Bluetooth devices based on the other Bluetooth devices and tag information, further determining whether to execute the payment processing procedure. The methods for determining the second device's Bluetooth device share similar or identical characteristics and will not be elaborated upon here.

[0141] The first device can also determine whether to access the server by checking if it has established a Bluetooth connection. The first device can also send the result to the server. Based on the result, the server determines whether to execute the payment processing procedure by checking if the device with which the first device has established a Bluetooth connection is the second device. Specifically, if the first device has not established a Bluetooth connection, it accesses the server but does not send a payment processing request; if the first device has established a Bluetooth connection, it can send a list of devices with the established Bluetooth connection to the server, and the server can determine whether to execute the payment processing procedure by checking if the device with the established Bluetooth connection is the second device.

[0142] Step 426: The server generates payment result information representing the payment result.

[0143] Payment result information can include information indicating successful payment, which may include transaction amount information; payment result information can also include information indicating failed payment, which may include reasons for payment failure, such as network error, insufficient account balance, etc.

[0144] Step 428: The first device displays the payment transaction processing result page.

[0145] First, based on the information returned by the server, a payment processing result page can be generated and displayed according to a preset format.

[0146] The same concepts or features present in this embodiment as those in the above embodiments can be referred to the descriptions in 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.

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

[0148] Figure 5 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.

[0149] As shown in Figure 5, the process may include the following steps:

[0150] Step 502: The first device acquires tag information for processing payment transactions.

[0151] In the embodiments of this specification, the tag information obtained by the first device may be obtained from a device used to store NFC tags; or it may be obtained from other devices, such as link information, code information, and other tag information sent to the first device by an unauthorized user after parsing the tag information of the NFC device.

[0152] Step 504: Based on the tag information, send a payment processing request to the server; the server is able to execute the payment business processing flow based on the location relationship between the first device and the second device used to store the tag information and provide feedback on the processing result information.

[0153] The payment processing request in the embodiments of this specification may include all or part of the information in the NFC tag. After processing the payment processing request sent by the first device through the execution process, the server can generate processing result information and feed it back to the first device.

[0154] Step 506: Based on the processing result information provided by the server, display the payment transaction processing result page.

[0155] In the embodiments described in this specification, the first device can generate a payment transaction processing result display page based on a preset page layout and format. It can display information such as transaction amount, transaction success or failure, and prompts to guide the user to perform the correct operation.

[0156] In practical applications, during the period from when the first device sends a payment processing request to the server to when the server sends the processing result back to the first device, a full-screen payment page or a secure payment page occupying part of the screen can be displayed. This page can display promotional information related to near-field payment methods or payment order information; no specific limitations are made here.

[0157] Using the methods described above, the server can determine whether to execute the payment processing procedure based on the distance between the first and second devices, or based on the generation time to determine whether the request time is within the validity period. Alternatively, it can determine whether to execute the payment processing procedure based on the Bluetooth devices of the first and second devices. By considering payment risks from multiple dimensions, the security of user account funds is ensured, and user fund losses are reduced. Near-field payment methods can also be used to complete payments, improving payment efficiency and user payment experience.

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

[0159] The payment processing request acquisition module 602 is used to acquire a payment processing request sent by the first device; the payment processing request includes tag information for storage in the NFC tag of the second device;

[0160] The second device determination module 604 is used to determine a second device for storing the tag information based on the tag information;

[0161] The distance judgment module 606 is used to determine whether the distance between the first device and the second device is less than or equal to a preset distance, and to obtain a first judgment result.

[0162] The processing result information generation module 608 is used to generate processing result information corresponding to the payment processing request based on the first judgment result;

[0163] The processing result information feedback module 610 is used to feed back the processing result information to the first device.

[0164] Optionally, the processing result information generation module described in the embodiments of this specification can be specifically used to: if the first judgment result indicates that the distance is less than or equal to a preset distance, then execute the payment processing flow; based on the payment processing flow, generate payment result information indicating the payment result.

[0165] Optionally, the processing result information generation module described in the embodiments of this specification can be specifically used to: if the first judgment result indicates that the distance is greater than the preset distance, then generate information indicating payment abnormality.

[0166] Optionally, in the embodiments of this specification, the device may further include an expiration date determination module, which may be used to: determine the generation time of the tag information; determine the request time of the payment processing request; and, based on the generation time, determine whether the request time is within the expiration date of the tag information, thereby obtaining a second determination result.

[0167] The step of generating the processing result information corresponding to the payment processing request specifically includes: if the first judgment result indicates that the distance is less than or equal to a preset distance, and the second judgment result indicates that the request time is within the validity period of the tag information, then the payment processing process is executed; based on the payment processing process, payment result information representing the payment result is generated.

[0168] Optionally, the expiration date determination module described in the embodiments of this specification may include:

[0169] The notification information acquisition unit is used to acquire notification information sent by the second device indicating that the tag information in the second device has been read;

[0170] The validity period setting unit is used to set the validity period of the tag information to a preset duration based on the notification information.

[0171] Optionally, the validity period setting unit described in the embodiments of this specification can be specifically used to: set the original validity period of the label information to a new validity period; the duration of the new validity period is shorter than the duration of the original validity period.

[0172] Optionally, the validity period determination module described in the embodiments of this specification can also be used to: generate information indicating payment abnormality if the second determination result indicates that the request time is not within the validity period of the tag information; or, generate information indicating payment abnormality if the first determination result indicates that the distance is greater than the preset distance; or, generate information indicating payment abnormality if the first determination result indicates that the distance is greater than the preset distance and the second determination result indicates that the request time is not within the validity period of the tag information.

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

[0174] The tag information acquisition module 702 is used to acquire tag information for processing payment transactions;

[0175] The payment processing request sending module 704 is used to send a payment processing request to the server based on the tag information; the server is able to execute a payment business processing flow based on the positional relationship between the first device and the second device used to store the tag information and provide feedback on the processing result information in response to the payment processing request.

[0176] The page display module 706 is used to display the payment business processing result page based on the processing result information provided by the server.

[0177] Optionally, the device described in the embodiments of this specification further includes a location information sending module, which can be used to send the first location information of the first device to the server.

[0178] Optionally, the tag information described in the embodiments of this specification includes identification information for launching the target application; the target application is an application with payment processing functions; the location information sending module may specifically include:

[0179] A target application invocation unit is configured to invoke the target application in the first device based on the identification information;

[0180] The location information acquisition unit is used to acquire the first location information of the first device based on the target application.

[0181] Optionally, the location information sending module described in the embodiments of this specification may specifically include:

[0182] A location sending unit is used to send a location information acquisition request to a location server; the location server is a server capable of providing location information.

[0183] A real-time location acquisition unit is used to acquire real-time location information provided by the location server;

[0184] Sending the first location information of the first device to the server specifically includes: sending the real-time location information to the server.

[0185] Optionally, the location information sending module described in the embodiments of this specification can also be used to: if the real-time location information of the first device is not obtained within a preset time period after the tag information is obtained, then obtain cached location information from the cache of the first device.

[0186] Sending the first location information of the first device to the server specifically includes: sending the cached location information to the server.

[0187] Optionally, the device described in the embodiments of this specification may further include a Bluetooth device determination module, which can be used to: determine whether there are other Bluetooth devices within the Bluetooth range of the first device, and obtain a third determination result; if the third determination result indicates that there are no other Bluetooth devices within the Bluetooth range of the first device, then terminate access to the server.

[0188] Sending the payment processing request to the server specifically includes: if the third determination result indicates that there are other Bluetooth devices within the Bluetooth range of the first device, then sending the payment processing request to the server.

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

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

[0191] At least one processor 810; and,

[0192] Memory 830 communicatively connected to the at least one processor;

[0193] Corresponding to the payment processing method shown in Figure 2, the memory 830 stores instructions 820 that can be executed by the at least one processor 810. The instructions are executed by the at least one processor 810 to enable the at least one processor 810 to implement the above-mentioned payment processing method.

[0194] 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 processing method.

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

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

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

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

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

[0200] 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. Furthermore, the present invention 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.

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

[0202] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device 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.

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

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

[0205] Memory may include non-persistent storage in computer-readable media, such as 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.

[0206] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using 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-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

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

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

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

[0210] 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 a payment processing request sent by a first device; the payment processing request containing at least part of information of tag information stored in an NFC tag of a second device; determining the second device for storing the tag information based on the at least part of the information of the tag information; judging whether a distance between the first device and the second device is less than or equal to a preset distance to obtain a first judgment result; generating processing result information corresponding to the payment processing request based on the first judgment result. 2.The method of claim 1, wherein the generating the processing result information corresponding to the payment processing request based on the first judgment result specifically comprises: if the first judgment result indicates that the distance is less than or equal to the preset distance, performing a payment processing procedure; and generating payment result information indicating a payment result based on the payment processing procedure. 3.The method of claim 1, wherein the generating the processing result information corresponding to the payment processing request based on the first judgment result specifically comprises: if the first judgment result indicates that the distance is greater than the preset distance, generating information indicating a payment exception. 4.The method of claim 1, wherein before the generating the processing result information corresponding to the payment processing request, the method further comprises: determining a generation time of the tag information; determining a request time of the payment processing request; judging whether the request time is within a valid period of the tag information based on the generation time to obtain a second judgment result; and the generating the processing result information corresponding to the payment processing request specifically comprises: if the first judgment result indicates that the distance is less than or equal to the preset distance and the second judgment result indicates that the request time is within the valid period of the tag information, performing the payment processing procedure; and generating the payment result information indicating the payment result based on the payment processing procedure. 5.The method of claim 4, further comprising: obtaining notification information sent by the second device and indicating that the tag information in the second device has been read; and based on the notification information, setting a valid period of the tag information as a preset time length. 6.The method of claim 5, wherein the setting the valid period of the tag information as the preset time length specifically comprises: setting an original valid period of the tag information as a new valid period; and a time length of the new valid period is less than a time length of the original valid period. 7.The method of claim 4, wherein the generating the processing result information corresponding to the payment processing request specifically comprises: if the second judgment result indicates that the request time is not within the valid period of the tag information, generating information indicating a payment exception; or if the first judgment result indicates that the distance is greater than the preset distance, generating the information indicating the payment exception; or if the first judgment result indicates that the distance is greater than the preset distance and the second judgment result indicates that the request time is not within the valid period of the tag information, generating the information indicating the payment exception. ​ 8. The method of claim 6, further comprising: generating the tag information; setting the original validity period for the tag information; sending the tag information to the second device.

9. The method of claim 1, further comprising: feeding back the processing result information to the first device.

10. The method of claim 1, further comprising: obtaining a third judgment result sent by the first device; the third judgment result is a judgment result obtained by judging whether there is another Bluetooth device in the Bluetooth range of the first device; if the third judgment result indicates that there is no other Bluetooth device in the Bluetooth range of the first device, the payment processing procedure is not started or terminated; if the third judgment result indicates that there is another Bluetooth device in the Bluetooth range of the first device, and the second device is included in the other Bluetooth device, the payment processing procedure is executed.

11. The method of claim 1, wherein the preset distance is determined according to the induction distance of NFC.

12. A payment service processing method, comprising: a first device obtaining tag information for processing a payment service; sending a payment processing request to a server based on the tag information; the server is configured to execute a payment service processing procedure based on the position relationship between the first device and a second device for storing the tag information and feed back processing result information; based on the processing result information provided by the server, a payment service processing result page is displayed.

13. The method of claim 12, further comprising: sending first position information of the first device to the server.

14. The method of claim 13, wherein the tag information includes identification information for launching a target application. the target application is an application with payment service processing function; the method further comprises: based on the identification information, the target application in the first device is invoked; based on the target application, the first position information of the first device is obtained.

15. The method of claim 13, further comprising: sending a position information obtaining request to a position server; the position server is a server capable of providing position information; obtaining real-time position information provided by the position server; the sending of the first position information of the first device to the server specifically comprises: sending the real-time position information to the server.

16. The method of claim 15, further comprising: if the real-time position information of the first device is not obtained within a preset time period after the tag information is obtained, the cached position information is obtained from the cache of the first device; the sending of the first position information of the first device to the server specifically comprises: sending the cached position information to the server.

17. The method of claim 12, further comprising: judging whether there is another Bluetooth device in the Bluetooth range of the first device, obtaining a third judgment result; if the third judgment result indicates that there is no other Bluetooth device in the Bluetooth range of the first device, the access to the server is terminated; the sending of the payment processing request to the server specifically comprises: If the third determination result indicates that there is another Bluetooth device within the Bluetooth range of the first device, a payment processing request is sent to a server.

18. The method of claim 12, wherein the tag information comprises link information.

19. The method of claim 12, wherein the payment service processing result page comprises payment result information indicating a payment result; and the information indicating a payment exception comprises at least one of prompt information prompting a user to re-perform payment, prompt information prompting a user to complete payment through an NFC near field payment method, and prompt information prompting a user that payment has failed. Alternatively, the payment service processing result page comprises payment result information indicating payment success or payment result information indicating payment failure.

20. An apparatus for payment service processing, comprising: a payment processing request obtaining module configured to obtain a payment processing request sent by a first device; the payment processing request comprising at least part of tag information to be stored in an NFC tag of a second device; a second device determining module configured to determine the second device for storing the tag information based on the at least part of the tag information; a distance determining module configured to determine whether a distance between the first device and the second device is less than or equal to a preset distance to obtain a first determination result; a processing result information generating module configured to generate processing result information corresponding to the payment processing request based on the first determination result.

21. An apparatus for payment service processing, comprising: a tag information obtaining module configured to obtain tag information for processing a payment service; a payment processing request sending module configured to send a payment processing request to a server based on the tag information; the server being capable of executing a payment service processing flow based on a positional relationship between the first device and a second device for storing the tag information and feeding back processing result information in response to the payment processing request; a page displaying module configured to display a payment service processing result page based on the processing result information provided by the server.

22. An apparatus for payment service processing, comprising: at least one processor; and a memory in communication connection with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the method for payment service processing according to any one of claims 1 to 19.

23. A computer readable medium having computer readable instructions stored thereon, the computer readable instructions being executable by a processor to implement the method for payment service processing according to any one of claims 1 to 19.

Images