Payment processing method and device, equipment, medium and product

Abstract

The embodiment of the invention provides a payment processing method and device, equipment, a medium and a product. The method comprises the steps that after a server obtains payment confirmation information sent by terminal equipment, whether a current transaction meets a preset condition or not can be judged, and a judgment result is obtained; the preset condition is a condition indicating that the terminal user can firstly obtain the payment result and then provide resources; and if the preset condition is met, the first payment result information can be sent to the terminal equipment after the payment processing request for the payment confirmation information sent by the merchant equipment is acquired, so that the terminal equipment can acquire the payment result information in advance. And the server can execute a judgment process after receiving the payment confirmation information sent by the terminal equipment, and the payment efficiency can also be improved through pre-judgment.

Description

Technical Field

[0001] This specification relates to the field of computer technology, and in particular to a method for payment processing. This specification also relates to a payment processing apparatus, a computing device, a computer-readable storage medium, and a computer program product. Background Technology

[0002] With the widespread adoption of mobile internet and smart devices, users are increasingly opting for payment methods that require no manual input, no QR code display, and even no active phone operation in high-frequency consumption scenarios such as retail, transportation, and catering. For example, interaction modes such as "tap-to-pay" and "touch-to-pay" based on short-range communication technologies like NFC, Bluetooth, UWB, or sound waves are gradually becoming important means of improving payment efficiency.

[0003] How to further improve the user experience is a technical problem that urgently needs to be solved. Summary of the Invention

[0004] In view of this, one or more embodiments of this specification provide a method, apparatus, device, computer-readable medium, and product for payment processing to improve the user's payment experience.

[0005] According to a first aspect of one or more embodiments of this specification, a payment processing method is provided, applied to a server, comprising: The terminal device receives payment confirmation information; the payment confirmation information is a confirmation message indicating that the terminal user of the terminal device agrees to make payment for the current transaction; the payment confirmation information is sent by the terminal device after obtaining tag information from the merchant device through short-range communication. Based on the payment confirmation information, it is determined whether the current transaction meets the preset conditions, and a judgment result is obtained; the preset conditions are conditions that indicate that the end user can obtain the payment result first and then provide resources. If the determination result indicates that the current transaction meets the preset conditions, and a payment processing request for the payment confirmation information is received from the merchant device, then first payment result information is sent to the terminal device; the first payment result information is sent before the resource transfer for the payment processing request is completed.

[0006] According to a second aspect of one or more embodiments of this specification, a payment processing method is provided, applied to a terminal device, comprising: Tag information is obtained from the merchant's device via short-range communication; the tag information includes information used to trigger the transaction process. The tag information is parsed, and payment confirmation information is sent to the server; the payment confirmation information is a confirmation that the terminal user of the terminal device agrees to make payment for the current transaction; the server is capable of executing the above payment processing method; Obtain the first payment result information fed back by the server; the first payment result information is sent by the server before the resource transfer is completed.

[0007] According to a third aspect of one or more embodiments of this specification, a payment processing apparatus is provided, comprising: The confirmation information acquisition module is used to acquire payment confirmation information sent by the terminal device; the payment confirmation information is confirmation information indicating that the terminal user of the terminal device agrees to make payment for the current transaction; the payment confirmation information is sent by the terminal device after obtaining tag information from the merchant device through short-range communication. The judgment module is used to determine whether the current transaction meets preset conditions based on the payment confirmation information, and to obtain a judgment result; the preset conditions are conditions that indicate that the end user can obtain the payment result first and then provide resources. The result sending module is used to send first payment result information to the terminal device if the judgment result indicates that the current transaction meets the preset conditions and a payment processing request for the payment confirmation information is received from the merchant device; the first payment result information is sent before the resource transfer for the payment processing request is completed.

[0008] According to a fourth aspect of one or more embodiments of this specification, a payment processing apparatus is provided, comprising: The information acquisition module is used to acquire tag information from the merchant's device via short-range communication; the tag information includes information used to trigger the transaction process. The confirmation information sending module is used to parse the tag information and send payment confirmation information to the server; the payment confirmation information is a confirmation message indicating that the terminal user of the terminal device agrees to make payment for the current transaction; the server is capable of executing the above payment processing method; The result information acquisition module is used to acquire the first payment result information fed back by the server; the first payment result information is sent by the server before the resource transfer is completed.

[0009] According to a fifth aspect of one or more embodiments of this specification, a computing device is provided, including a memory and a processor; the memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the payment processing method described above.

[0010] According to a sixth aspect of one or more embodiments of this specification, a computer-readable storage medium is provided that stores computer instructions which, when executed by a processor, implement the steps of the payment processing method described above.

[0011] According to a seventh aspect of the embodiments of this specification, a computer program product is provided, including a computer program / instructions that, when executed by a processor, implement the steps of the payment processing method described above.

[0012] One embodiment of this specification can achieve at least the following beneficial effects: After the server obtains the payment confirmation information sent by the terminal device, it can execute a preset judgment process to determine whether the current transaction meets the preset condition of obtaining the payment result first and then providing resources. If the current transaction meets the preset condition, after obtaining the payment processing request sent by the merchant device, it can send the first payment result information to the terminal device without waiting for the actual completion of the resource transfer for the payment processing request before feeding back the payment result information to the terminal device. This can shorten the time for the terminal device to display the payment result information, improve the smoothness of payment, improve the user experience, and improve payment efficiency.

[0013] On the other hand, after the server receives the payment confirmation information sent by the terminal device, it can send the transaction identifier information that identifies the terminal user's payment account to the merchant device in parallel, without waiting for the judgment result before sending the transaction identifier information. This allows the merchant device to obtain the transaction identifier information as soon as possible and send the payment processing request, which can further improve payment efficiency. Attached Figure Description

[0014] To more clearly illustrate the technical solutions in the embodiments or prior art of this specification, the 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 specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0015] Figure 1 This is a schematic diagram illustrating an application scenario of a payment processing method provided in one embodiment of this specification; Figure 2 This is a flowchart illustrating a payment processing method provided in one embodiment of this specification; Figure 3 This is a flowchart illustrating a payment processing method provided in one embodiment of this specification; Figure 4 This is a swimlane diagram of a payment processing method provided in one embodiment of this specification; Figure 5 For one embodiment of this specification, the corresponding Figure 2 A schematic diagram of the structure of a payment processing device; Figure 6 For one embodiment of this specification, the corresponding Figure 3 A schematic diagram of the structure of a payment processing device; Figure 7 This is a structural block diagram of a computing device provided in one embodiment of this specification. Detailed Implementation

[0016] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in the embodiments of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this specification, and not all embodiments. Based on the embodiments in this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this specification.

[0017] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0018] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “an,” “an,” “the,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification includes any or all possible combinations of one or more associated listed items.

[0019] The terms “comprising,” “including,” or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, 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, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded.

[0020] Although the terms "first," "second," etc., may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, "first" may also be referred to as "second," and similarly, "second" may also be referred to as "first," without departing from the scope of one or more embodiments of this specification. Ordinal numbers such as "first," "second," etc., do not necessarily indicate order; often they are used to facilitate the distinction of objects. For example, "first server" and "second server" usually refer to two servers. To distinguish these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0021] The word “if” as used in one or more embodiments of this specification may be interpreted as “when”, “when”, or “in response to determination”, depending on the context.

[0022] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0023] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0024] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant regions, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0025] The following explains the terms and concepts used in one or more embodiments of this specification.

[0026] Near Field Communication (NFC) is a technology that allows two electronic devices to transmit data wirelessly within a distance of a few centimeters. This short-range wireless connection can be used in scenarios such as mobile payment information sharing and simplifying device pairing.

[0027] Third-party guarantee: This refers to introducing a third party into the payment process to asynchronously transfer funds, ensuring the successful completion of the fund transfer. Buyers and sellers can quickly exchange payment information.

[0028] In related technologies, during payment via near-field communication (NFC), the user terminal acts as a card reader to read the tag information from the merchant. The user terminal then initiates the payment application based on this information and can request the server to send a payment code to the merchant's device. Upon receiving the payment code, the merchant initiates a payment request, requesting the server to process the transaction. After the server completes the transaction, it deducts the required payment from the user's account and adds it to the merchant's account. The user terminal then displays a payment result message such as "Payment Complete." After seeing the displayed result, the user moves the user terminal away from the merchant's device.

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

[0030] Figure 1 This is a schematic diagram illustrating an application scenario of a payment processing method provided in one embodiment of this specification.

[0031] like Figure 1As shown, this scenario may include a terminal device 100, a merchant device 200, and a server 300. Both the terminal device 100 and the merchant device 200 have near-field communication (NFC) capabilities. The terminal device 100 can act as a card reader to obtain NFC tag information from the merchant device 200, triggering the payment process. The NFC tag information can be generated locally on the merchant device according to preset rules, or it can be sent to the merchant device from the server. The merchant device 200 can determine the amount of the goods to be paid for through scanning, inputting, or other methods. The tag information in the merchant device 200 may contain information such as the amount to be paid. After obtaining the tag information, with user authorization, the terminal device 100 can automatically generate confirmation information indicating payment for the transaction corresponding to the tag information, or, after obtaining the tag information, the terminal device can display a confirmation page containing the amount to be paid. The user can perform a payment confirmation operation on this page, and the terminal device can generate confirmation information based on the user's operation. The terminal device 100 can send the payment confirmation information to the server 300. After receiving the payment confirmation information sent by the terminal device 100, the server 300 determines whether the current transaction meets the preset conditions for providing the payment result to the end user based on information such as the amount to be paid corresponding to that information. Simultaneously, after obtaining the tag information from the merchant device 200, the merchant device 200 can trigger a resource transfer process, also known as an acquiring process or a deduction process, and can send a payment processing request to the server 300. In practical applications, the payment processing request can be sent by the merchant device 200 to the server 300, or it can be sent by the merchant server that manages the merchant device 200. After determining that the current transaction meets preset conditions based on payment confirmation information and receiving the payment processing request from the merchant, server 300 can immediately send back information indicating the payment result to terminal device 100. Server 300 can provide the payment result to terminal device 100 before the actual resource transfer for the current transaction is completed. This allows users of terminal device 100 to receive transaction completion information more quickly, and terminal device 100 can be kept away from merchant device 200, eliminating the need to keep them close for extended periods or wait for the payment result to be displayed. The entire payment process is smoother, improving user experience and payment efficiency.

[0032] In such Figure 1 In the application scenarios shown, the server can connect to one or more terminal devices or merchant devices via a local area network (LAN), a wide area network (WAN), an internet connection, or other types of data networks. Figure 1The servers mentioned can include, but are not limited to, any device, equipment, platform, or equipment cluster with computing and processing capabilities. Figure 1 The terminal devices can include, but are not limited to, smartphones, tablets, laptops, PDAs, personal computers, smart home devices, and in-vehicle devices. Merchant equipment can include, but is not limited to, cash registers, self-service cash registers, and POS machines, or can also be smartphones, tablets, laptops, PDAs, personal computers, smart home devices, and in-vehicle devices.

[0033] This application provides a method for payment processing, and also relates to a payment processing apparatus, a computing device, a computer-readable storage medium, and a computer program product, which will be described in detail in the following embodiments.

[0034] Figure 2 This is a flowchart illustrating a payment processing method provided in one embodiment of this specification.

[0035] From a programming perspective, the entity executing the process can be a program hosted on a server. It can be understood that this method can be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities.

[0036] like Figure 2 As shown, the process may include the following steps: Step 202: Obtain the payment confirmation information sent by the terminal device.

[0037] The payment confirmation information is a confirmation message indicating that the terminal user of the terminal device agrees to make payment for the current transaction; the payment confirmation information may be sent by the terminal device after obtaining tag information from the merchant device through short-range communication.

[0038] Payment confirmation information can be a payment confirmation message sent by a terminal device to a merchant's device after obtaining tag information via short-range communication methods such as near-field communication, Bluetooth, or UWB. This confirmation message indicates that the terminal user agrees to pay for the current transaction. Alternatively, payment confirmation information can be a data packet or instruction sent by the terminal device to a server, signifying that the user has authorized the transaction.

[0039] If the terminal device obtains tag information from the merchant device via Near Field Communication (NFC), the terminal device can act as a card reader, and the merchant device can act as a passively responding tag device.

[0040] Tag information can contain information used to trigger transaction processes. Tag information can be strings conforming to communication rules or protocols, such as links or other string formats. It can include payment application identifiers, allowing the terminal device to launch the corresponding payment application. Tag information can also contain business information, such as details indicating the payment transaction. Upon receiving this information, the terminal device or the launched payment application can execute corresponding business processing flows, such as sending payment confirmation information to the server, sending other instructions to the server, or accessing the server to retrieve information. Tag information can also include merchant-related information, such as merchant ID and merchant device ID, or transaction-related information, such as transaction amount information.

[0041] Tag information can be pre-sent by the server to the merchant's device, for example, before the merchant's device determines the amount to be paid or before the merchant's device executes the settlement; alternatively, the tag information can be sent by the server to the merchant's device after the amount to be paid is determined; or it can be partial or template information containing tag information within the merchant's device, which is then assembled locally by the merchant's device according to preset rules after the amount to be paid is determined. Tag information can be reusable, with multiple transactions corresponding to the same tag information; or it can be non-reusable, with one transaction corresponding to one tag information, and different transactions corresponding to different tag information. The server can also record the correspondence between tag information and merchant devices.

[0042] Payment confirmation information can be automatically sent by the terminal device after obtaining tag information, based on user authorization. For example, after obtaining tag information, the terminal device can launch the payment application corresponding to that tag information. The payment application can then parse at least part of the information in the tag information and automatically send payment confirmation information to the server.

[0043] Alternatively, payment confirmation information can be sent based on the user's confirmation action. For example, after obtaining tag information, the terminal device can interpret the content of the tag information. For instance, if the tag information contains an identifier or string that triggers the display of the payment confirmation page, the terminal device can display a payment confirmation page containing information such as the amount to be paid. This page can contain operation controls. If the control is a confirmation control, after the user performs an operation on the control, the terminal device can send payment confirmation information to the server.

[0044] Alternatively, the tag information obtained by the terminal device may contain the identification information of a payment application with payment function. After obtaining the tag information, the terminal device may display a prompt page to launch the payment application. This page may contain operation controls. If the operation control is a control that indicates agreement to launch and authorize the payment application, the terminal device may automatically launch the payment application after the user performs an operation on the control. The launched payment application may send payment confirmation information to the server.

[0045] Step 204: Based on the payment confirmation information, determine whether the current transaction meets the preset conditions and obtain the judgment result; the preset conditions are conditions that indicate that the end user can obtain the payment result first and then provide resources.

[0046] The preset conditions can be used to determine whether the payment result can be sent to the payer's terminal device before resource transfer or before the current transaction settlement is completed. These preset conditions can also indicate whether there is a risk of payment failure in the current transaction. If the preset conditions are met, it means that the payment result can be provided to the payer user in advance for the current transaction, or it means that the risk of payment failure in the current transaction is low, and the payment result information can be provided to the payer user in advance.

[0047] Providing resources after obtaining the payment result can mean that for the current transaction, before actually deducting the end user's resources (such as funds, coupons, points, etc.), the result information indicating payment completion is sent to the end user, allowing the end user to know the payment result in advance. In practical applications, the judgment can be made from one or more dimensions such as the payer, the payee, and the purchased items. As one implementation method, the above judgment on whether the current transaction meets preset conditions can include: judging whether the end user meets a first preset condition; judging whether the merchant on the merchant device meets a second preset condition; wherein, the first preset condition includes at least one of the following: the end user has sufficient resources, and the end user is a trusted user; the second preset condition includes at least one of the following: the merchant is a trusted merchant, the merchant's transaction amount within a preset time period is less than or equal to a preset limit, and the merchant is a preset contracted merchant.

[0048] Sufficient resources can refer to the fact that the end user's account has sufficient available payment capacity for the current transaction amount, including but not limited to: the balance of a single channel is greater than or equal to the transaction amount; the total balance of multiple channels is greater than or equal to the transaction amount.

[0049] Trusted users can refer to users who have been certified through the platform's credit assessment system, or users whose credit score or credit level is higher than a preset score or level. For example, it can be derived from a comprehensive score based on historical performance rate, fraud records, device security level, etc.

[0050] Trusted merchants can refer to merchants who have been verified by the platform, have no record of violations, and have stable settlements, or merchants whose credit score or credit rating is higher than a preset score or rating. Alternatively, it can be determined based on a comprehensive score considering factors such as historical fulfillment rate, fraud records, and device security level.

[0051] If a merchant's transaction amount is less than or equal to a preset limit within a preset time period, it means that the transaction amount does not exceed the preset transaction limit within the preset time period. This can be used to implement dynamic transaction limit control for merchants. For example, the cumulative transaction amount on a given day shall not exceed 100,000 yuan, which can prevent the risk of abnormally large transactions.

[0052] The term "pre-signed merchant" can refer to a merchant who has signed a specific service agreement with the payment platform and is qualified to use the method provided in one embodiment of this specification.

[0053] As one implementation method, the payment confirmation information may include the identification information of the terminal device or terminal user (e.g., user ID, device ID, etc.), the identification information of the merchant or merchant device (e.g., merchant ID, merchant device ID, etc.), or it may also include information about the pending transaction amount corresponding to the current transaction. After obtaining the payment confirmation information, the server can determine whether the current transaction meets the preset conditions based on the identification information of both parties and the transaction amount.

[0054] For example, the server can extract the user ID and merchant ID from the payment confirmation information; query the user's risk control profile, call the account system to check available resources, and call the credit center to obtain the user's trust label; or it can query the merchant's risk control profile, check whether the merchant is on the whitelist (trusted merchant), query real-time transaction records, calculate the cumulative transaction amount for the current period (e.g., today), and verify whether the merchant is a contracted merchant. If the user meets the first preset condition and the merchant meets the second preset condition, then the current transaction can be determined to meet the preset conditions. If either the user or the merchant does not meet the preset conditions, then the current transaction can be determined to not meet the preset conditions.

[0055] In this context, "user meeting the first preset condition" can mean that the user meets one or more of the first preset conditions, or it can mean all of the conditions; "merchant meeting the second preset condition" can mean that the merchant meets one or more of the first preset conditions, or it can mean all of the conditions. The specific settings can be configured according to actual needs.

[0056] In one embodiment of this specification, a more comprehensive risk control mechanism is constructed by introducing preset conditions from both the user and merchant dimensions. This expands the applicability of pre-success feedback while ensuring transaction security, and may also guarantee smooth transactions and improve user experience. In practical applications, preset conditions can also be judged from the perspective of the product. Optionally, in one embodiment of this specification, the above-mentioned judgment of whether the current transaction meets the preset conditions may further include: judging whether the transaction amount corresponding to the current transaction is less than or equal to a preset amount; or judging whether the product corresponding to the current transaction is a product of a preset category.

[0057] Payment processing requests can include information required for the transaction, such as information about both parties, transaction amount, product information, order number, etc. The pending transaction amount represents the amount payable in this transaction request. The preset amount represents a threshold amount pre-set by the payment platform (e.g., 500 yuan, 1000 yuan, etc.), used to limit the maximum transaction size that can enable the pre-success feedback mechanism. This amount can be dynamically configured based on merchant type, user level, consumption location, etc., or it can be set to a fixed value. "Product" refers to the specific items or services purchased in the transaction order.

[0058] Predefined product categories can represent a predefined set of low-risk, high-frequency, or standardized product categories, such as beverages, transportation tickets, and convenience store daily necessities. Specific categories can be set according to actual business needs.

[0059] For example, the server can parse the transaction amount and / or product information (such as product ID, category code, etc.) from the payment confirmation information or the payment processing request sent by the merchant, query the currently applicable preset amount threshold (which may vary according to the merchant's industry and user level), and compare whether the transaction amount is less than or equal to the preset amount; it can also query the category tag corresponding to the product ID to determine whether it belongs to the whitelist category; if any condition is met or both are met, the transaction passes the risk control in the transaction attribute dimension.

[0060] In practical applications, if the pending transaction amount for the current transaction is less than or equal to a preset amount, it indicates that the current transaction meets the preset conditions. Alternatively, if the product corresponding to the current transaction is a product of a preset category, it indicates that the current transaction meets the preset conditions. Or, if the pending transaction amount for the current transaction is less than or equal to a preset amount and the product corresponding to the current transaction is a product of a preset category, it indicates that the current transaction meets the preset conditions.

[0061] In one embodiment of this specification, the introduction of scenario-based judgments on transaction amount and product category further refines the granularity of risk control. Under the premise of ensuring fund security, it accurately identifies low-risk transaction scenarios suitable for pre-success feedback, which helps to improve the success rate of transactions and enhances the security boundary and compliance of the entire technical solution.

[0062] Step 206: If the judgment result indicates that the current transaction meets the preset conditions, and a payment processing request for the payment confirmation information is received from the merchant device, then the first payment result information is sent to the terminal device; the first payment result information is sent before the resource transfer for the payment processing request is completed.

[0063] A payment processing request can represent a formal deduction instruction initiated by a merchant device to a server after interacting with a terminal device, such as after sensing a touch on the terminal device, after sending tag information to the terminal device, or during the process of sending tag information, or after obtaining radio frequency signals or card detection signals sent by the terminal device. This request includes transaction ID, amount, transaction party information, etc.

[0064] The first payment result information can represent a success notification returned before the funds are actually transferred or transferred to the merchant's receiving account. This first payment result information can indicate that the payment is completed, for example, it can contain the words "Payment Complete".

[0065] Resource transfer can refer to the actual fund deduction and settlement operations performed by banks or payment platforms, which may include back-end processes such as account freezing, fund transfer, and clearing.

[0066] Traditional payment methods require waiting for funds to be transferred before providing a result, which is time-consuming. In payment scenarios using short-range communication, users typically only move their devices away from the merchant's device after seeing the payment result displayed on their screens, ensuring the integrity of the short-range communication. In one embodiment of this specification, after receiving payment confirmation information from the terminal device, the server can execute a judgment process. If the current transaction meets preset conditions, upon receiving a subsequent payment processing request from the merchant, it can immediately send back first payment result information indicating payment completion to the terminal device. The actual deduction process can be executed asynchronously, allowing the terminal user to quickly learn that the transaction is complete and move their device away from the merchant's device, ending the short-range communication. This eliminates the need for the terminal user to keep their device close to the merchant's device for an extended period, reducing the perceived payment time and improving the user experience.

[0067] On the other hand, the server will only send the first payment result information to the terminal device after receiving the payment confirmation information sent by the terminal device and the payment processing request sent by the merchant device. This can ensure the accuracy of the feedback information and avoid the inconvenience caused to the end user by sending the first payment result information to the terminal device in cases where the merchant device cancels the transaction or cannot process the transaction normally due to a malfunction of the merchant device. It can also ensure the accuracy and security of transaction processing.

[0068] In practical applications, after obtaining a string or instruction that conforms to preset rules, such as the payer's payment code information, the merchant device can execute the acquiring process, generate a payment processing request, and send it. Optionally, the method in one embodiment of this specification may further include: Based on the payment confirmation information, the server sends transaction identification information to the merchant device to identify the payment account of the terminal user, so that the merchant device can send a payment processing request to the server based on the transaction identification information; Alternatively, after obtaining the tag information, the terminal device may send transaction identification information for identifying the terminal user's payment account to the merchant device via short-range communication, so that the merchant device may send a payment processing request to the server based on the transaction identification information; Alternatively, after the merchant device senses the terminal device that has acquired the tag information, it sends a payment processing request to the server based on the pre-stored transaction identifier information used to determine the payment account of the terminal user.

[0069] The transaction identifier information can be an identifier that triggers the merchant's device to send a payment processing request. This identifier information can be recognized by the server to determine the payment account of the end user transacting with the merchant's device. The transaction identifier information can be a string that conforms to certain rules, such as a string starting with 28, 25, 30, etc. The string length can be 16 to 24 characters, or any other length that meets the requirements. There are no specific limitations on the specific format of the string. In practical applications, the transaction identifier information can be a string representing the payer's payment code or a string that conforms to the composition rules of the payment code's numbers.

[0070] In one implementation, payment identification information can be sent by the server to the merchant device after receiving payment confirmation information from the terminal device. The payment confirmation information may include the terminal user's identification information, such as a user ID. After receiving the payment confirmation information from the terminal device, the server can generate or determine the transaction identification information corresponding to the terminal user's payment account and send it to the merchant device. In practical applications, the terminal device receives tag information from the merchant device and sends payment confirmation information. This payment confirmation information may contain at least part of the tag information, such as a token or other identifiers. The server can store the correspondence between tag information and merchant devices. After receiving the payment confirmation information, the server can determine which tag information the payment confirmation information was based on based on some of the identifiers contained in the payment confirmation information. Then, based on the correspondence with the merchant device, the server can determine the corresponding merchant device and send the payment identification information to that merchant device.

[0071] As another implementation, payment identification information can also be sent from the terminal device to the merchant device. After obtaining the tag information, the terminal device can send the transaction identification information to the merchant device via short-range communication. This transaction identification information can be pre-stored in the terminal device, existing before the terminal device obtains the tag information. Alternatively, the transaction identification information can be obtained from a server after the terminal device obtains the tag information. For example, after obtaining the tag information, the terminal device parses the tag information, sends payment confirmation information to the server, and the server can send the transaction identification information back to the terminal device. The terminal device can then send this transaction identification information to the merchant device via short-range communication. Since information transmission speeds are typically fast, completed within seconds or millimeter-level time, from the user's perspective, the terminal device can complete the process of obtaining tag information and sending transaction identification information with just one touch between the user and the merchant device.

[0072] In the two embodiments described above, after the server obtains the payment confirmation information, it can execute two processes in parallel: one is the process of determining whether the current transaction meets the preset conditions, and the other is the process of sending transaction identification information. This can improve the execution speed of transaction processing-related processes and increase efficiency. Since there is no need to wait for the judgment result before sending the transaction identification information to the merchant device or terminal device, from the perspective of the entire transaction process, the merchant device can obtain the transaction identification information earlier, triggering the process of sending the payment processing request, which also helps to improve payment efficiency.

[0073] In another implementation, payment identification information can be pre-stored in the merchant's device. However, the merchant's device only sends a payment processing request to the server based on the payment identification information after detecting a terminal device conducting a transaction. In this case, before the terminal device and the merchant's device interact, the transaction identification information is not associated with any payment account. After the transaction is sent, if the server receives the payment confirmation information sent by the terminal device, the server can associate the transaction identification information with the terminal device that sent the transaction, identifying that terminal device as the payer. In this implementation, after the terminal device and the merchant's device send short-range communication, they can execute the processes of sending payment confirmation information and sending payment processing requests in parallel. After receiving the payment confirmation information, the server can execute a process to determine whether the current transaction corresponding to the payment confirmation information meets preset conditions and save the determination result. After the server receives a payment processing request for the same transaction as the payment confirmation information, it can execute a resource transfer process for the payment processing request. It can also execute a process of sending the first payment result information to the terminal device in parallel. If the current transaction meets the preset conditions based on the payment confirmation information, the server can send the payment result information to the terminal device in advance before the resource transfer is completed. In this way, the terminal device can know the payment is completed in advance, shorten the payment time perceived by the user, and improve the user experience.

[0074] In practical applications, the tag information provided by the merchant device to the terminal device may include payment identification information or identification information that uniquely corresponds to the payment identification information. The payment confirmation information sent by the terminal device to the server may also include the payment identification information or identification information that uniquely corresponds to the payment identification information. The payment processing request sent by the merchant device to the server may also include the payment identification information or identification information that uniquely corresponds to the payment identification information. Therefore, the server can determine the payment confirmation information and payment request information for the same transaction based on this information. Alternatively, the payment confirmation information and payment processing request information may include transaction-related information, such as the identification information of the terminal device or terminal user, the identification information of the merchant device or merchant user, transaction amount information, transaction time information, etc. The server can also determine the payment confirmation information and payment request information for the same transaction based on this information.

[0075] The transaction identification information may not include information indicating the judgment result. The transaction identification information can be obtained by the merchant device before the server receives the judgment result, or it can be sent to the merchant device. Alternatively, the step of sending the transaction identification information and the step of judging whether the current transaction meets the preset conditions can be executed in parallel. This way, providing the transaction identification information to the merchant device does not require waiting for the judgment result, which can shorten the payment processing time and improve the user experience.

[0076] In practical applications, it's possible that the merchant device will only execute the acquiring process and send a payment processing request to the server after short-range communication between the terminal device and the merchant device. It's also possible that the payment confirmation information sent by the terminal device and the payment processing request sent by the merchant device do not arrive at the server simultaneously, or the server can process transactions from multiple terminal devices or multiple merchant devices. To improve the accuracy of transaction processing, the payment confirmation information and payment processing request corresponding to the same transaction can be determined based on the payment confirmation information and key information contained in the payment processing request. Optionally, if the above determination result indicates that the current transaction meets preset conditions and a payment processing request for the payment confirmation information is received from the merchant device, then sending first payment result information to the terminal device may include: If the judgment result indicates that the current transaction meets the preset conditions, then the payment confirmation information is temporarily stored. If a payment processing request is received, it is determined whether the payment processing request matches the key information of the payment confirmation information; the key information includes transaction amount information, merchant device identification information, and terminal device identification information. If the payment processing request matches the key information of the payment confirmation information, then the first payment result information is sent to the terminal device.

[0077] The term "temporary storage" can mean that the server temporarily stores the payment confirmation information in a cache or memory, or it can set an expiration period (such as 30 seconds) for subsequent matching and verification.

[0078] Key information can represent a set of core fields used to uniquely link user confirmation information (i.e., payment confirmation information) and merchant deduction requests (i.e., payment processing requests) corresponding to the same transaction, which can prevent cross-transaction impersonation or replay attacks.

[0079] Transaction amount information indicates the amount payable for this transaction. Merchant device identification information can represent a unique physical or logical device ID (such as a POS serial number, NFC tag ID, etc.) or a unique identifier for the merchant using the device. Terminal device identification information can represent the identifier of a user's mobile phone or other smart device, or it can represent the identifier of the user of the terminal device, such as user ID, UID, etc. Key information may also include timestamp information, etc.

[0080] Matching key information can mean that the key information is consistent, or that the similarity is greater than a preset threshold. If the key information includes timestamp information, matching key information can also mean that the difference in timestamps is less than or equal to a threshold difference.

[0081] If the key information in a payment processing request matches the key information in a payment confirmation message, it indicates that the payment processing request and the payment confirmation message pertain to the same transaction. After obtaining the payment processing request and payment confirmation message for the same transaction, the server can execute a resource transfer process for that transaction.

[0082] As one implementation method, if the current transaction corresponding to the payment confirmation information meets preset conditions, the payment confirmation information or its key information can be stored in a first information database used to store payment confirmation information that meets the preset conditions. After the server receives the payment processing request sent by the merchant device, it can query the first information database to see if there is payment confirmation information or key information matching the payment processing request, that is, to see if there is payment confirmation information for the same transaction as the payment processing request. If so, the payment result information can be sent to the terminal device before the actual resource transfer is completed. If there is no payment confirmation information or key information matching the payment processing request in the first information database, it indicates that the current transaction does not meet the conditions for sending the payment result information to the terminal device in advance, and the payment result information can be sent to the terminal device after the actual resource transfer is completed, following the conventional processing procedure.

[0083] As one implementation method, if the server determines that the current transaction does not meet the preset conditions after obtaining the payment confirmation information, it may choose not to save the payment confirmation information, or it may save the payment confirmation information in a second information database used to store payment confirmation information that does not meet the preset conditions. If the payment confirmation information that does not meet the preset conditions or the key information of the payment confirmation information is saved in the second information database, after the server obtains a payment processing request, it can synchronously or asynchronously search for payment confirmation information that matches the payment processing request in the first and second information databases. If a match is found in the first information database, it means that the current transaction meets the condition of disclosing the payment result to the end user in advance, and the payment result information can be sent to the terminal device before the resource transfer is completed. If a match is found in the second information database, it means that the current transaction does not meet the condition of disclosing the payment result to the end user in advance, and the payment result information can be sent to the terminal device after the resource transfer is completed.

[0084] For example, after completing the pre-judgment and finding that the result meets the preset conditions, the server stores key information of the payment confirmation, such as user ID, amount, merchant device ID, terminal device ID, and timestamp, in the cache as key-value pairs. An expiration time can also be set. When a merchant payment processing request is received, the server can extract the amount, merchant device ID, terminal device ID, or a deducible user identifier. Based on key information such as the merchant device ID and the time window, the server searches the cache for the corresponding payment confirmation information. For example, it can compare whether the three are completely consistent: whether the amount is equal, whether the merchant device ID is the same, and whether the terminal device ID is the same. If all three are consistent, it can be determined that the payment processing request meets the requirement to send the payment result in advance, and the first payment result can be sent. Otherwise, the payment result information can be sent after resource transfer is completed.

[0085] In practical applications, for the same transaction, the server may receive the payment confirmation information from the terminal device before receiving the payment processing request from the merchant device; or it may receive the payment processing request from the merchant device before receiving the payment confirmation information from the terminal device. Upon receiving any payment processing request, the server can use a time window, based on the timestamp contained in the payment processing request or a period before and after the timestamp when the request was received, to query the payment confirmation information within that time window. Alternatively, considering that in practical applications, the merchant device may need to perform some order generation processes before sending the payment processing request, the payment confirmation information sent by the terminal device will usually be earlier than the payment processing request sent by the merchant device. In this case, the timestamp of the payment processing request sent by the merchant device can be used as the cutoff time, and a period before that time can be used as the starting time to match the payment confirmation information within that time period.

[0086] In one embodiment of this specification, by temporarily storing user confirmation information and strictly matching it based on three key pieces of information—transaction amount, merchant device identifier, and terminal device identifier—it can ensure that the deduction request initiated by the merchant completely corresponds to the confirmation information previously authorized by the user. This provides a strong security guarantee for returning payment success before funds are transferred, ensuring the accuracy and security of the payment.

[0087] In practical applications, after obtaining payment request information and payment confirmation information, the server can execute a resource transfer process. As one implementation, if the above-mentioned judgment result indicates that the current transaction meets preset conditions, and after obtaining the payment processing request for the payment confirmation information sent by the merchant device, it may further include: Based on the transaction information of both parties and the amount to be transacted contained in the payment processing request, a resource transfer process is executed; After the resource transfer process for the payment processing request is completed, the second payment result information is sent to the merchant device.

[0088] The information of the two parties in the transaction can represent the payer (user) identifier and the payee (merchant) identifier contained in the payment processing request. For example, it can be the internal account ID of the payment application platform or the encrypted token.

[0089] The amount information to be transferred indicates the amount to be transferred in this transaction.

[0090] The resource transfer process can represent the actual fund settlement operation process, used to deduct funds from the payer's account and add the corresponding funds to the payee's account. For specific processing logic, please refer to relevant technical documents; it will not be elaborated upon here.

[0091] The second payment result information can represent the final notification sent to the merchant after the funds have been actually transferred, informing the merchant that the transaction is now complete. This second payment result information may include a notification indicating payment completion, or it may include information such as the transaction serial number, settlement status, and arrival time.

[0092] In one embodiment of this specification, after executing a real resource transfer process, a second payment result information is sent to the merchant's device, ensuring the integrity of the transaction. This satisfies users' need for speed while also protecting merchants' reliance on certain payment receipts, forming a dual closed loop of user experience and risk control.

[0093] As one implementation method, the method in one embodiment of this specification may further include: if the determination result indicates that the current transaction does not meet the preset conditions, and a payment processing request for the payment confirmation information is received from the merchant device, then a resource transfer process is executed based on the payment processing request; after the resource transfer process is completed, a fourth payment result information is sent to the terminal device.

[0094] Failure to meet preset conditions may indicate that the current transaction user terminal does not meet the conditions for obtaining payment result information in advance, such as insufficient user balance, low credit score, merchant not signed up, or transaction amount exceeding the limit.

[0095] The fourth payment result information is sent from the server to the terminal device after the resource transfer is completed, such as after the payment is successfully deducted from the terminal device's payment account. In terms of content, the fourth payment result information can be the same as the first payment result information, for example, it may include information indicating that the payment is complete.

[0096] In practical applications, the content of the fourth payment result information can differ from that of the first payment result information. The fourth payment result information is provided after the resource transfer process is completed, based on the actual result of the resource transfer. This information can indicate either payment success or payment failure. If the preset conditions include criteria for determining whether the current transaction can succeed, then meeting these conditions indicates that the current transaction can succeed. In this case, the first payment result information can indicate payment completion or success, but it doesn't necessarily have to be a payment failure message.

[0097] In one embodiment of this specification, for a given transaction, regardless of whether the transaction meets preset conditions, the server can execute the resource transfer process after receiving the payment confirmation information for the transaction sent by the terminal device and the payment processing request for the transaction from the merchant device. However, when the transaction meets the preset conditions, the server can send the payment result information to the terminal device in advance; when the transaction does not meet the preset conditions, the server can send the payment result information to the terminal device only after the resource transfer is completed. This ensures the universality and fault tolerance of the payment system, avoids transaction failures due to preset condition blocking, maintains a basic user experience, and improves overall service coverage and inclusiveness.

[0098] To facilitate user payments via short-range communication and to reuse existing merchant POS devices, an auxiliary payment device with short-range communication capability can be connected to the merchant's existing POS device. As one implementation, the merchant's equipment may include a POS device and an auxiliary payment device; the POS device and the auxiliary payment device are communicatively connected; the auxiliary payment device has short-range communication functionality to provide the tag information to the terminal device; and the POS device is used to send the payment processing request.

[0099] Correspondingly, the above-mentioned sending of the second payment result information to the merchant device after the resource transfer process for the payment processing request is completed may include: sending the second payment result information to the cashier device after the resource transfer process for the payment processing request is completed.

[0100] The method in one embodiment of this specification may further include: sending third payment result information to the auxiliary payment device before the resource transfer for the payment processing request is completed; the third payment result information is payment result information with the same meaning as the first payment result information.

[0101] In this context, a POS device refers to the core terminal used by a merchant for transaction management, such as a POS machine or a cashier's computer, which has the ability to communicate via the network, manage orders, and initiate payment requests. An auxiliary payment device can be lightweight hardware specifically designed for short-range interactions and does not have full POS functionality. In practical applications, if the POS device has short-range communication capabilities, an auxiliary payment device may not be needed; alternatively, the auxiliary payment device and the POS device can be integrated into one unit, or they can be separate devices.

[0102] The third payment result information is a pre-success notification sent to the auxiliary payment device before the funds are transferred. Its semantic content is the same as the first payment result information, such as displaying information such as "payment completed" or broadcasting audio information indicating that the payment is completed.

[0103] For example, in practical applications, when a terminal device touches an auxiliary payment device, it reads the tag information via NFC communication. The terminal device can then send payment confirmation information to the server. Upon receiving this confirmation, the server can execute a pre-judgment process to determine if the transaction meets preset conditions. If the conditions are met, the server can send the first payment result information to the terminal device. Simultaneously, it can also send the third payment result information to the auxiliary payment device. Upon receiving the third payment result, the auxiliary payment device can trigger a local response, such as a buzzer sounding, displaying text or symbols on the screen, or a voice announcement. After the terminal device touches the auxiliary payment device, the auxiliary payment device can send payment identification information to the cash register, or it can receive payment identification information from the server and send it to the cash register. The cash register can then send a payment processing request to the server, which executes a resource transfer process. After the resource transfer is complete, the server sends the second payment result information to the cash register.

[0104] In one embodiment of this specification, by sending a third payment result message with the same meaning as the first payment result message to the auxiliary payment device before the resource transfer is completed, the near-field interaction point can provide real-time localized feedback (such as light, sound, text, etc.), which can enhance the user's perception of payment success certainty for short-range communication payment methods. Furthermore, sending the final settlement result to the POS device can ensure the accuracy of the financial process. This balances the immediacy of the user experience with the reliability of merchant operations, improving the overall usability and acceptance of contactless payment.

[0105] In practical applications, to ensure successful transaction execution and a positive user experience, an initial attempt can be made to deduct funds from the end-user's account on the terminal device. If this fails, a third-party advance payment can then be used to guarantee the transaction's success. As one implementation method, the resource transfer process based on the transaction information and the amount to be transacted contained in the payment processing request can include: determining the payer's account and the payee's account based on the transaction information; deducting the amount of resources represented by the amount to be transacted from the payer's account and adding it to the payee's account; if the full amount of resources represented by the amount to be transacted cannot be deducted from the payer's account, then at least a portion of the resources represented by the amount to be transacted is deducted from the resource account of the third-party payment application and added to the payee's account.

[0106] The information of the two parties to the transaction may include the payer's identifier (such as user ID, encrypted account token) and the payee's identifier (such as merchant ID) contained in the payment processing request, which can be used to map to the real account inside the server or transaction platform.

[0107] The resource account of a third-party payment application can refer to a reserve fund or advance payment account held by the payment platform itself, represented by the server. This account is used to advance funds to merchants when users lack sufficient funds, and can later seek reimbursement from the users. In practical applications, the end user of the terminal device can also be a user of the payment platform, such as a registered user of the payment platform's application. The terminal device can use the payment platform's payment application to make payments.

[0108] The amount advanced by the resource account of a third-party payment application can be the full amount (if the payer's account has no funds at all) or the difference (if the payer's account has paid part of the funds).

[0109] As one implementation method, after receiving a payment processing request, the server can parse the request and extract information such as the payer ID, payee ID, and amount; it can then query the payer's user account available balance (which may include combined payment channels); if the balance is greater than or equal to the amount, the payment is directly deducted from the user's account and credited to the merchant's account; if the balance is less than the amount, all available funds are first deducted from the user's account, then the difference is calculated, deducted from the platform's advance payment account, and credited to the merchant's account. This transaction can be marked as "platform-funded," and an asynchronous recovery task can be initiated subsequently. Regardless of whether an advance payment is made, the system ensures that the payee's account ultimately receives the full amount. Alternatively, after parsing the payment request and obtaining information such as the amount to be paid, the server can directly attempt to deduct the amount from the payer's user account. If the full amount cannot be deducted, the entire or remaining amount can be deducted from the advance payment account. The process of deducting from the user account can be skipped before checking the balance. This can be understood as follows: since the server has already checked the user account balance when determining whether the current transaction meets the preset conditions after obtaining the payment confirmation information, the server can reuse this judgment result after obtaining the payment request, without having to perform the balance check and comparison steps again. This can reduce the time spent by merchants when placing orders and improve transaction processing efficiency.

[0110] In one embodiment of this specification, when a user's account has insufficient funds, the resource account of the third-party payment application makes up the difference, ensuring that the payee's account receives the full amount. This effectively avoids transaction failures caused by insufficient temporary balances of the user, maintaining the certainty of the merchant's funds and improving the user's payment success rate and smooth experience.

[0111] If, during the actual deduction process, the funds in the end-user's payer's account are insufficient to pay for the current transaction, and funds are advanced to the merchant from the resource account of the third-party payment application, after the current transaction deduction process is completed, if the end-user's payer's account subsequently has available resources, funds can be deducted from the payer's account to the resource account of the third-party payment application to repay the previously advanced resources. As one implementation method, after deducting at least a portion of the resources represented by the amount to be transacted from the resource account of the third-party payment application, the method may further include: if the payer's account has resources, then the resources deducted from the payer's account representing the at least portion of the resources represented by the amount to be transacted are added to the resource account of the third-party payment application.

[0112] With user authorization, the server can monitor the payer's account balance and, if the payer's account has available resources, execute a deduction process. Alternatively, the server can query the payer's account balance at a preset time, such as a user-specified time or a preset time after the transaction, or execute a process to deduct the advanced resources from the payer's account. Alternatively, the server can send a repayment reminder to the terminal device at a preset time, allowing the terminal user to perform a repayment action, and based on the user's repayment action, the server can execute a deduction process.

[0113] For example, after making an advance payment, the server can create an advance payment recovery task, linking information such as user ID, advance payment amount, and transaction ID; it can also initiate scheduled tasks (such as every 5 minutes) or event-driven processes (such as user top-ups or credit assessment updates) to trigger recovery checks; it can query the user's current available balance or deduction limit; if the available funds are greater than or equal to the advance payment amount, or if the account's available funds are greater than zero, the amount can be deducted from the user's account; and an equivalent amount can be added to the platform's advance payment account. After execution, the recovery task can be marked as completed or deleted. If the available funds are insufficient, deductions can be made in batches or the process can wait for the next check until the full amount is repaid.

[0114] After the actual resource transfer is completed, the server can send a notification message indicating that the deduction has been completed to the terminal device. This message can be sent to the terminal device via application notifications, SMS, pop-up messages, etc. The notification message may include the account information of the actual payment. If the transaction was completed using resources from a third-party payment application's resource account, the notification message may also include a prompt indicating that the transaction has been completed, or it may include a prompt reminding the user to repay, such as reminding the user to repay before a specified date. From the terminal device's perspective, the terminal device can first display the initial payment result information, and then display the notification message, or the notification message may not be displayed directly, but only after the user selects to display it.

[0115] The payment technologies described in one or more embodiments of this specification may include, for example, Near Field Communication (NFC), Wi-Fi, 3G / 4G / 5G, POS machine card swiping technology, QR code scanning technology, barcode scanning technology, Bluetooth, infrared, Short Message Service (SMS), Multimedia Message Service (MMS), etc.

[0116] While one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is merely one possible execution order among many steps and does not represent the only possible execution order. The order of some steps may be adjusted according to actual needs, or some steps may be omitted. When the claims involve method steps, changes in the order of such steps, or parallel execution between steps, are also within the scope of protection of the claims.

[0117] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they have not been described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0118] Based on the same idea, one embodiment of this specification also provides a payment processing method with a terminal device as the execution subject. Figure 3 This is a flowchart illustrating a payment processing method provided in one embodiment of this specification. From a programming perspective, the entity executing the process can be a program mounted on a terminal device. For example... Figure 3 As shown, the process may include the following steps: Step 302: Obtain tag information from the merchant's device via short-range communication; the tag information contains information for triggering the transaction process.

[0119] In this context, "terminal device" can refer to the device used by the payer, such as a smartphone or smartwatch. "Merchant device" can be the device used by the merchant, such as a POS machine, cash register, or turnstile. Both the terminal device and the merchant device can have short-range communication capabilities. Short-range communication can include technologies such as NFC, Bluetooth, and Ultra-Wideband (UWB), with communication distances typically within a few centimeters, tens of centimeters, or a few meters. In one implementation, the terminal device can act as the initiating party in the communication, and the merchant device can act as the passive party. The terminal device can read tag information from the merchant device.

[0120] Tag information can be information existing on the merchant's device before short-range communication occurs between the terminal device and the merchant's device. Tag information can be fixed, remain fixed for a short period, or change constantly; different transactions can correspond to different tag information. Tag information can be structured data packets broadcast or sent by the merchant's device, and can contain key parameters required to trigger a transaction (such as merchant ID, device ID, amount code, etc.).

[0121] Step 304: Parse the tag information and send payment confirmation information to the server; the payment confirmation information is confirmation information indicating that the terminal user of the terminal device agrees to make payment for the current transaction.

[0122] The server is capable of executing the methods described in the above embodiments.

[0123] After obtaining the tag information, the terminal device can parse the content within the tag information and launch the corresponding payment application. The launched payment application can then execute corresponding processes, such as generating payment confirmation information. Parsing can refer to the terminal device performing protocol decoding, field extraction, and semantic reconstruction of the tag information.

[0124] Terminal devices can send payment confirmation information to the server based on tag information. This payment confirmation information can be sent automatically by the terminal device upon user authorization, or it can be sent based on a user-specified action. The payment confirmation information can refer to a transaction initiation signal sent by the terminal device to the server after user authorization, indicating that the user has agreed to the payment. This information does not contain a payment code or credential information used to identify the payment account.

[0125] After receiving payment confirmation information, the server can execute a process to determine whether the transaction meets preset conditions, such as whether the user's account balance is sufficient and predicting whether the current transaction can be successful. The server can send payment result information indicating payment completion to the terminal device before the resource transfer for the current transaction is completed. See the descriptions in the foregoing embodiments for details.

[0126] Step 306: Obtain the first payment result information fed back by the server; the first payment result information is sent by the server before the resource transfer is completed.

[0127] The initial payment result information returned by the server can be information displayed on the terminal device, or it can be an information display command. The specific information to be displayed can already exist locally on the terminal device. After receiving the command, the terminal device can display payment result information indicating that the payment is complete, such as text or symbols.

[0128] The terminal device can display a page containing payment result information, or it can display payment result information through pop-ups, H5 pages, etc.

[0129] For example, a user brings their device close to a merchant's device (such as an NFC tag); the device reads the tag information (such as an NDEF message); the device's operating system or payment application can parse the tag content and extract information such as the merchant ID and amount; if the user has authorized the transaction (such as being logged in, having passed biometric authentication, or having authorized password-free payment), the device can automatically construct payment confirmation information (which may include user identification, transaction context, etc.); the confirmation information is sent to the payment server via an HTTPS request or other protocols; the device can obtain the server's response, and if it receives the first payment result information from the server, it can display a "Payment successful" or "Payment completed" message in the notification bar or within the app.

[0130] Taking a subway turnstile as an example, suppose a user enters the subway station, and there is an NFC tag next to the turnstile. The user taps the tag with their phone, and the phone automatically reads the information in the tag, launching the corresponding payment application. This payment application can be launched on the front end or the back end, sending payment confirmation information to the server. The server determines that the user has good credit and sufficient account resources, and can immediately return the first payment result information. Assuming the phone pops up a "Payment Completed" notification within 200ms, the user can pass through directly; the actual deduction is completed 800ms later, but the user has already left without noticing.

[0131] The above is an illustrative scheme of a payment processing method with a terminal device as the execution subject according to this embodiment. It should be noted that this technical solution belongs to the same concept as the above-described payment processing method with a server as the execution subject. For details not described in detail, please refer to the description of the above-described payment processing method with a server as the execution subject.

[0132] According to the above explanation, Figure 4 This is a swimlane diagram of a payment processing method provided in one embodiment of this specification, such as... Figure 4 As shown, the solution includes a user confirmation stage and a merchant order placement stage, which may specifically include the following steps: Users can bring their terminal device close to the merchant's device to make payments via short-range communication. Step 402 involves bringing the terminal device close to the merchant's device to obtain tag information from the merchant's device.

[0133] After obtaining the tag information, the terminal device can execute step 404: parse the tag information and generate payment confirmation information.

[0134] You can also perform step 406: send payment confirmation information to the server.

[0135] After the server obtains the payment confirmation information sent by the terminal device, it can execute step 408: Based on the payment confirmation information, determine whether the current transaction meets the preset conditions and obtain the judgment result.

[0136] After receiving the user's payment confirmation, the server can restore the corresponding payer user and the merchant information associated with the merchant device (payee), calculate whether the user's assets are sufficient (single channel, combination, etc.), determine whether the merchant dimension information meets the requirements, and conduct a complete assessment from aspects such as credit, security, and payment ability to obtain the judgment result.

[0137] The server can also temporarily store the judgment result.

[0138] After receiving the payment confirmation information sent by the terminal device, the server can also execute step 410 in parallel: determining the transaction identifier information corresponding to the terminal device based on the payment confirmation information. It can also execute step 412: sending the transaction identifier information back to the merchant device.

[0139] This transaction identifier information can trigger the merchant's device to execute the acquiring process. After obtaining the payment identifier information, the merchant's device can execute step 414: execute the acquiring process based on the obtained transaction identifier information and generate a payment processing request. It can also execute step 416: send the payment processing request to the server.

[0140] After receiving the payment processing request, the server can perform step 418: matching the payment processing request with the payment confirmation information.

[0141] If it is determined that the payment processing request matches the payment confirmation information, and that they pertain to the same transaction, and the judgment result obtained in step 408 indicates that the current transaction meets the preset conditions, then the server can execute step 420: sending the first payment result information to the terminal device. This allows the terminal device to know in advance that the payment has been completed.

[0142] In practical applications, with merchant authorization, the server can also send result information with the same meaning as the first payment result to the merchant's device, allowing the merchant's device to know the payment completion information in advance. Alternatively, the server can choose not to send result information to the merchant's device before the deduction process is completed, and only send the result information after the deduction process is finished or the merchant's account receives the funds.

[0143] If the judgment result indicates that the current transaction does not meet the preset conditions, the server may not send the first payment result information to the terminal device, but may send the result information to the terminal device after the actual deduction is completed.

[0144] After obtaining the first payment result information, the terminal device can also execute step 422: display the first payment result information.

[0145] After the server determines that the payment processing request matches the payment confirmation information, it can proceed to step 424: execute the deduction process, and generate second payment result information after the deduction is completed. It can also proceed to step 426: send the second payment result information to the merchant's device.

[0146] In practical applications, the server can allocate, deduct, and settle funds from users' accounts and deliver them to merchants. If users currently lack payment channels or have insufficient funds, a third party can advance funds to the merchant to ensure the merchant's financial security. Subsequently, the server can initiate timely collection from the user, and complete the transaction deduction when the user's account has sufficient funds.

[0147] Based on the same idea, the embodiments of this specification also provide the apparatus corresponding to the above method.

[0148] Figure 5 For one embodiment of this specification, the corresponding Figure 2 A schematic diagram of the structure of a payment processing device. (See diagram below.) Figure 5 As shown, the device may include: The confirmation information acquisition module 502 is used to acquire payment confirmation information sent by the terminal device; the payment confirmation information is confirmation information indicating that the terminal user of the terminal device agrees to make payment for the current transaction; the payment confirmation information is sent by the terminal device after obtaining tag information from the merchant device through short-range communication. The judgment module 504 is used to determine whether the current transaction meets the preset conditions based on the payment confirmation information, and to obtain the judgment result; the preset conditions are conditions that indicate that the end user can obtain the payment result first and then provide resources. The result sending module 506 is used to send first payment result information to the terminal device if the judgment result indicates that the current transaction meets the preset conditions and a payment processing request for the payment confirmation information is received from the merchant device; the first payment result information is sent before the resource transfer for the payment processing request is completed.

[0149] Optionally, the device is further configured to send transaction identifier information for identifying the payment account of the terminal user to the merchant device based on the payment confirmation information, so that the merchant device can send a payment processing request to the server based on the transaction identifier information.

[0150] Alternatively, after obtaining the tag information, the terminal device may send transaction identification information for identifying the terminal user's payment account to the merchant device via short-range communication, so that the merchant device may send a payment processing request to the server based on the transaction identification information.

[0151] Alternatively, after the merchant device senses the terminal device that has acquired the tag information, it sends a payment processing request to the server based on the pre-stored transaction identifier information used to determine the payment account of the terminal user.

[0152] Optionally, if the determination result indicates that the current transaction meets preset conditions, and a payment processing request for the payment confirmation information is received from the merchant device, then first payment result information is sent to the terminal device, including: If the judgment result indicates that the current transaction meets the preset conditions, then the payment confirmation information is temporarily stored. If a payment processing request is received, it is determined whether the payment processing request matches the key information of the payment confirmation information; the key information includes transaction amount information, merchant device identification information, and terminal device identification information. If the payment processing request matches the key information of the payment confirmation information, then the first payment result information is sent to the terminal device.

[0153] Optionally, if the determination result indicates that the current transaction meets the preset conditions, and after obtaining the payment processing request for the payment confirmation information sent by the merchant device, the device is further configured to: execute a resource transfer process based on the transaction parties information and the amount information to be transacted contained in the payment processing request; and send second payment result information to the merchant device after the resource transfer process for the payment processing request is completed.

[0154] Optionally, the merchant device includes a cash register and an auxiliary payment device; the cash register and the auxiliary payment device are communicatively connected; the auxiliary payment device has a short-range communication function for providing the tag information to the terminal device; the cash register is used to send the payment processing request.

[0155] The step of sending the second payment result information to the merchant device after the resource transfer process for the payment processing request is completed may include: sending the second payment result information to the cashier device after the resource transfer process for the payment processing request is completed.

[0156] The device is further configured to: send third payment result information to the auxiliary payment device before the resource transfer for the payment processing request is completed; the third payment result information is payment result information with the same meaning as the first payment result information.

[0157] Optionally, the device is further configured to: if the determination result indicates that the current transaction does not meet the preset conditions, and after obtaining the payment processing request for the payment confirmation information sent by the merchant device, execute a resource transfer process based on the payment processing request; and after the resource transfer process is completed, send fourth payment result information to the terminal device.

[0158] Optionally, determining whether the current transaction meets preset conditions includes: determining whether the terminal user meets a first preset condition; determining whether the merchant on the merchant device meets a second preset condition; wherein the first preset condition includes at least one of the terminal user having sufficient resources and the terminal user being a trusted user; the second preset condition includes at least one of the merchant being a trusted merchant, the merchant's transaction amount within a preset time period being less than or equal to a preset limit, and the merchant being a preset contracted merchant.

[0159] Optionally, determining whether the current transaction meets the preset conditions further includes: determining whether the transaction amount corresponding to the current transaction is less than or equal to a preset amount; or determining whether the product corresponding to the current transaction is a product of a preset category.

[0160] Optionally, the resource transfer process based on the transaction information of both parties and the amount to be transacted contained in the payment processing request includes: determining the payer's account and the payee's account based on the transaction information; deducting the amount of resources represented by the amount to be transacted from the payer's account and adding it to the payee's account based on the amount to be transacted; if it is not possible to successfully deduct the full amount of resources represented by the amount to be transacted from the payer's account, then deducting at least a portion of the amount of resources represented by the amount to be transacted from the resource account of the third-party payment application and adding it to the payee's account.

[0161] Optionally, after deducting at least a portion of the resource quantity represented by the amount to be transacted from the resource account of the third-party payment application, the device is further configured to: if the payer's account has resources, add the resources deducted from the payer's account as the resource quantity represented by the at least a portion of the amount to be transacted to the resource account of the third-party payment application.

[0162] The above is an illustrative scheme of a payment processing apparatus according to this embodiment. It should be noted that the technical solution of this apparatus and the technical solution of the aforementioned payment processing method belong to the same concept. Details not described in detail in the technical solution of this apparatus can be found in the description of the technical solution of the aforementioned payment processing method. This apparatus can be used as a server.

[0163] Figure 6 For one embodiment of this specification, the corresponding Figure 3 A schematic diagram of the structure of a payment processing device. (See diagram below.) Figure 6 As shown, the device may include: Information acquisition module 602 is used to acquire tag information from merchant equipment via short-range communication; the tag information includes information for triggering the transaction process; The confirmation information sending module 604 is used to parse the tag information and send payment confirmation information to the server; the payment confirmation information is confirmation information indicating that the terminal user of the terminal device agrees to make payment for the current transaction; the server is capable of executing the payment processing method provided in the above embodiments; The result information acquisition module 606 is used to acquire the first payment result information fed back by the server; the first payment result information is sent by the server before the resource transfer is completed.

[0164] The above is an illustrative scheme of a payment processing device according to this embodiment. It should be noted that the technical solution of this device and the technical solution of the payment processing method described above belong to the same concept. Details not described in detail in the technical solution of this device can be found in the description of the technical solution of the payment processing method described above. This device can be used as a terminal device.

[0165] It is understood that the modules mentioned above refer to computer programs or program segments used to perform one or more specific functions. Furthermore, the distinction between these modules does not imply that the actual program code must also be separate.

[0166] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in the same or different software and / or hardware, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units, etc. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0167] Based on the same idea, an embodiment of this specification also provides a device corresponding to the above method.

[0168] Figure 7 A structural block diagram of a computing device 700 provided according to one embodiment of this specification is shown.

[0169] The computing device 700 includes: a memory 710 and a processor 720; The memory 710 is used to store computer programs / instructions, and the processor 720 is used to execute the computer programs / instructions, which, when executed by the processor 720, implement the steps of the payment processing method described above.

[0170] Specifically, the components of the computing device 700 include, but are not limited to, a memory 710 and a processor 720. The processor 720 is connected to the memory 710 via a bus 730, and the database 750 is used to store data.

[0171] The computing device 700 also includes an access device 740, which enables the computing device 700 to communicate via one or more networks 760. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 740 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0172] In one embodiment of this specification, the above-described components of the computing device 700 and Figure 7 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 7 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0173] The computing device 700 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 700 can also be a mobile or stationary server.

[0174] The processor 720 executes the computer instructions to implement the steps of the payment processing method described above.

[0175] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the payment processing method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the payment processing method described above.

[0176] An embodiment of this specification also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the payment processing method as described above.

[0177] The above is an illustrative embodiment of a computer-readable storage medium. It should be noted that the technical solution of this storage medium and the technical solution of the payment processing method described above belong to the same concept. Details not described in detail in the technical solution of the storage medium can be found in the description of the technical solution of the payment processing method described above.

[0178] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the payment processing method described above.

[0179] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the payment processing method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the payment processing method described above.

[0180] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the embodiments of apparatus, devices, media, and products, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The apparatus, devices, media, products, and methods provided in the embodiments of this specification are corresponding to each other, and therefore the apparatus, devices, media, and products also have similar beneficial technical effects as the corresponding methods. Since the beneficial technical effects of the methods have been described in detail above, the beneficial technical effects of the corresponding apparatus, devices, media, and products will not be repeated here.

[0181] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0182] 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 methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to hardware circuit structures. 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 a digital system themselves to "integrate" it onto a PLD, 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.

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

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

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

[0186] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, the invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the 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.

[0187] 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, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0188] 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, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0189] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

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

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

[0192] 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 character 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.

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

[0194] The above description is merely an embodiment of this application and is not intended to limit 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 principle of this application should be included within the scope of the claims of this application.

Claims

1. A payment processing method, applied to a server, comprising: Obtain payment confirmation information sent by the terminal device; The payment confirmation information is a confirmation message indicating that the terminal user of the terminal device agrees to make payment for the current transaction; The payment confirmation information is sent by the terminal device after obtaining the tag information from the merchant's device through short-range communication; Based on the payment confirmation information, determine whether the current transaction meets the preset conditions, and obtain the determination result; The preset conditions refer to the conditions under which the end user can obtain the payment result first and then receive the resources; If the judgment result indicates that the current transaction meets the preset conditions, and a payment processing request for the payment confirmation information is received from the merchant device, then the first payment result information is sent to the terminal device. The first payment result information is sent before the resource transfer for the payment processing request is completed.

2. The method according to claim 1, further comprising: Based on the payment confirmation information, the server sends transaction identification information to the merchant device to identify the payment account of the terminal user, so that the merchant device can send a payment processing request to the server based on the transaction identification information; Alternatively, after obtaining the tag information, the terminal device may send transaction identification information for identifying the terminal user's payment account to the merchant device via short-range communication, so that the merchant device may send a payment processing request to the server based on the transaction identification information; Alternatively, after the merchant device senses the terminal device that has acquired the tag information, it sends a payment processing request to the server based on the pre-stored transaction identifier information used to determine the payment account of the terminal user.

3. The method according to claim 1, wherein if the determination result indicates that the current transaction meets preset conditions, and a payment processing request for the payment confirmation information is received from the merchant device, then sending first payment result information to the terminal device includes: If the judgment result indicates that the current transaction meets the preset conditions, then the payment confirmation information is temporarily stored. If a payment processing request is received, it is determined whether the payment processing request matches the key information of the payment confirmation information; the key information includes transaction amount information, merchant device identification information, and terminal device identification information. If the payment processing request matches the key information of the payment confirmation information, then the first payment result information is sent to the terminal device.

4. The method according to claim 1, further comprising, if the determination result indicates that the current transaction meets preset conditions, and after obtaining the payment processing request for the payment confirmation information sent by the merchant device, the method includes: Based on the transaction information of both parties and the amount to be transacted contained in the payment processing request, a resource transfer process is executed; After the resource transfer process for the payment processing request is completed, the second payment result information is sent to the merchant device.

5. The method according to claim 4, wherein the merchant device includes a cash register and an auxiliary payment device; the cash register and the auxiliary payment device are communicatively connected; the auxiliary payment device has a short-range communication function for providing the tag information to the terminal device; and the cash register is used to send the payment processing request. The step of sending the second payment result information to the merchant device after the resource transfer process for the payment processing request is completed includes: sending the second payment result information to the cashier device after the resource transfer process for the payment processing request is completed; The method further includes: sending third payment result information to the auxiliary payment device before the resource transfer for the payment processing request is completed; the third payment result information is payment result information with the same meaning as the first payment result information.

6. The method according to claim 1, further comprising: If the judgment result indicates that the current transaction does not meet the preset conditions, and after obtaining the payment processing request sent by the merchant device for the payment confirmation information, a resource transfer process is executed based on the payment processing request; After the resource transfer process is completed, the fourth payment result information is sent to the terminal device.

7. The method according to claim 1, wherein determining whether the current transaction meets the preset conditions includes: Determine whether the terminal user meets the first preset condition; Determine whether the merchant of the merchant device meets the second preset condition; The first preset condition includes at least one of the following: the terminal user has sufficient resources and the terminal user is a trusted user; the second preset condition includes at least one of the following: the merchant is a trusted merchant, the merchant's transaction amount within a preset time period is less than or equal to a preset limit, and the merchant is a preset contracted merchant.

8. The method according to claim 7, wherein determining whether the current transaction meets the preset conditions further includes: Determine whether the pending transaction amount for the current transaction is less than or equal to the preset amount; Alternatively, determine whether the product corresponding to the current transaction belongs to a preset category.

9. The method according to claim 4, wherein executing the resource transfer process based on the transaction party information and the amount information to be transacted contained in the payment processing request includes: Based on the information of both parties to the transaction, determine the payer's account and the payee's account; Based on the amount information to be transacted, the amount of resources represented by the amount information to be transacted is deducted from the payer's account and increased to the payee's account; If the amount of resources represented by the transaction amount cannot be fully deducted from the payer's account, then at least a portion of the amount of resources represented by the transaction amount will be deducted from the resource account of the third-party payment application and added to the payee's account.

10. The method of claim 9, after deducting at least a portion of the resource quantity represented by the amount information to be transacted from the resource account of the third-party payment application, further comprising: If the payer's account has resources, then the resources represented by at least a portion of the transaction amount information are added to the resource account of the third-party payment application after deducting the resources from the payer's account.

11. A payment processing method applied to a terminal device, comprising: Tag information is obtained from the merchant's device via short-range communication; the tag information includes information used to trigger the transaction process. The tag information is parsed, and payment confirmation information is sent to the server; The payment confirmation information is a confirmation message indicating that the terminal user of the terminal device agrees to make payment for the current transaction; the server is capable of executing the method described in claim 1; Obtain the first payment result information fed back by the server; the first payment result information is sent by the server before the resource transfer is completed.

12. A payment processing apparatus, comprising: The confirmation information acquisition module is used to acquire payment confirmation information sent by the terminal device; the payment confirmation information is confirmation information indicating that the terminal user of the terminal device agrees to make payment for the current transaction; the payment confirmation information is sent by the terminal device after obtaining tag information from the merchant device through short-range communication. The judgment module is used to determine whether the current transaction meets preset conditions based on the payment confirmation information, and to obtain a judgment result; The preset conditions refer to the conditions under which the end user can obtain the payment result first and then receive the resources; The result sending module is used to send first payment result information to the terminal device if the judgment result is that the current transaction meets the preset conditions and a payment processing request for the payment confirmation information is received from the merchant device. The first payment result information is sent before the resource transfer for the payment processing request is completed.

13. A payment processing apparatus, comprising: The information acquisition module is used to acquire tag information from the merchant's device via short-range communication; the tag information includes information used to trigger the transaction process. A confirmation information sending module is used to parse the tag information and send payment confirmation information to the server; the payment confirmation information is confirmation information indicating that the terminal user of the terminal device agrees to make payment for the current transaction; the server is capable of executing the method described in claim 1; The result information acquisition module is used to acquire the first payment result information fed back by the server; the first payment result information is sent by the server before the resource transfer is completed.

14. A computing device, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 11.

15. A computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 11.

16. A computer program product comprising a computer program / instructions that, when executed by a processor, implement the steps of the method according to any one of claims 1 to 11.

Images