Induction payment service processing method, device and equipment

Abstract

This specification discloses a contactless payment business processing scheme in its embodiments. The method applied to the server and / or user end of a payment application includes: responding to a user's mobile terminal approaching a merchant's sensing device, determining a payment confirmation page, and providing the payment confirmation page to the mobile terminal so that the user can initiate a confirmation request through the payment confirmation page; before the user initiates the confirmation request, determining relevant user payment information, and providing the user payment information to the sensing device or a merchant's POS device connected to the sensing device so that the merchant can initiate a payment request in advance based on the user payment information; and triggering corresponding processing logic based on whether the payment request or the confirmation request is received first to advance the payment process.

Description

Technical Field

[0001] This specification relates to the field of contactless payment technology, and in particular to contactless payment business processing methods, devices, and equipment. Background Technology

[0002] Near Field Communication (NFC) is a short-range, high-frequency radio technology that operates at a frequency of 13.56 MHz within a range of 20 centimeters. It evolved from contactless radio frequency identification (RFID) and interconnection technologies, providing a highly secure and fast communication method for various electronic products.

[0003] With the widespread use of smartphones that support NFC, NFC technology is being applied more extensively in the payment field. For example, when merchants deploy NFC devices at the checkout counter, users can make payments by interacting with the NFC device using their NFC-enabled phones (often by tapping it), which is quite convenient.

[0004] In some practical application scenarios, when using NFC payment, after "tap", the user of the payment application on the mobile phone will be prompted to confirm the payment page. The user's confirmation process often has an adverse impact on the efficiency of the entire payment process.

[0005] Therefore, a more efficient NFC payment solution is needed to further improve the user experience. Summary of the Invention

[0006] This specification provides one or more embodiments of a contactless payment service processing method, apparatus, and device to solve the following technical problem: to find a more efficient NFC payment solution to further improve the user experience.

[0007] To solve the above-mentioned technical problems, one or more embodiments of this specification are implemented as follows: This specification provides one or more embodiments of a contactless payment service processing method, applied to the server and / or user end of a payment application, the method comprising: In response to the user's mobile terminal approaching the merchant's sensing device, a confirmation payment page is determined and provided to the mobile terminal so that the user can initiate a confirmation request through the confirmation payment page; Before the user initiates the confirmation request, the corresponding user payment information is determined and provided to the sensing device or the merchant POS device connected to the sensing device, so that the merchant can initiate a payment request in advance based on the user payment information. Depending on whether the payment request or the confirmation request is received first, the corresponding processing logic is triggered to advance the payment process.

[0008] This specification provides one or more embodiments of a contactless payment processing method, applied to a merchant's contactless device, the method comprising: In response to the user's mobile terminal approaching the merchant's sensing device, the server and / or user terminal of the payment application are triggered to determine the payment confirmation page, so that the user can initiate a confirmation request to the server and / or user terminal through the payment confirmation page; The merchant receives user payment information provided by the server and / or the user before the user initiates the confirmation request, so that the merchant can initiate a payment request in advance based on the user payment information. The payment process is initiated by the server and / or the user, which trigger corresponding processing logic based on whether the payment request or the confirmation request is received first.

[0009] This specification provides one or more embodiments of a contactless payment processing device, applied to the server and / or user end of a payment application, the device comprising: The confirmation request support module, in response to the user's mobile terminal approaching the merchant's sensing device to perform a sensing operation, determines the confirmation payment page and provides the confirmation payment page to the mobile terminal so that the user can initiate a confirmation request through the confirmation payment page; The payment request support module determines the corresponding user payment information before the user initiates the confirmation request, and provides the user payment information to the sensing device or the merchant POS device connected to the sensing device, so that the merchant can initiate a payment request in advance based on the user payment information. The payment process advancement module triggers corresponding processing logic based on whether the payment request or the confirmation request is received first, in order to advance the payment process.

[0010] This specification provides one or more embodiments of a contactless payment processing device, applied to a merchant's contactless device, the device comprising: The sensing interaction trigger module responds to the user's mobile terminal approaching the merchant's sensing device to trigger the payment application's server and / or user terminal to determine the payment confirmation page, so that the user can initiate a confirmation request to the server and / or user terminal through the payment confirmation page; The payment information receiving module receives user payment information provided by the server and / or the user before the user initiates the confirmation request, so that the merchant can initiate a payment request in advance based on the user payment information. The payment process is initiated by the server and / or the user, which trigger corresponding processing logic based on whether the payment request or the confirmation request is received first.

[0011] This specification provides one or more embodiments of a contactless payment processing device, applied to the server and / or user end of a payment application, the contactless payment processing device comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: In response to the user's mobile terminal approaching the merchant's sensing device, a confirmation payment page is determined and provided to the mobile terminal so that the user can initiate a confirmation request through the confirmation payment page; Before the user initiates the confirmation request, the corresponding user payment information is determined and provided to the sensing device or the merchant POS device connected to the sensing device, so that the merchant can initiate a payment request in advance based on the user payment information. Depending on whether the payment request or the confirmation request is received first, the corresponding processing logic is triggered to advance the payment process.

[0012] This specification provides one or more embodiments of a contactless payment processing device, applied to a merchant's contactless payment device, the contactless payment processing device comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: In response to the user's mobile terminal approaching the merchant's sensing device, the server and / or user terminal of the payment application are triggered to determine the payment confirmation page, so that the user can initiate a confirmation request to the server and / or user terminal through the payment confirmation page; The merchant receives user payment information provided by the server and / or the user before the user initiates the confirmation request, so that the merchant can initiate a payment request in advance based on the user payment information. The payment process is initiated by the server and / or the user, which trigger corresponding processing logic based on whether the payment request or the confirmation request is received first.

[0013] The above-described at least one technical solution adopted in one or more embodiments of this specification can achieve the following beneficial effects: it can parallelize the merchant preparation process as quickly as possible while waiting for the user's confirmation request, including enabling the merchant to obtain the user's payment information in advance and initiate the payment request in advance. The payment application will also adapt to the various possible arrival orders of the confirmation request and the payment request, and adopt differentiated processing logic accordingly to continue to advance the payment process. Therefore, for contactless payment scenarios such as NFC payment, it helps to improve the execution efficiency of the entire payment process, helps to further improve the user experience, and helps to better promote contactless payment. 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 A flowchart illustrating a contactless payment service processing method provided in one or more embodiments of this specification; Figure 2 This is a schematic diagram of the business processing flow corresponding to an application scenario provided by one or more embodiments of this specification, in which the merchant's payment request arrives before the user's confirmation request. Figure 3 This is a schematic diagram of the business process for a scenario in which a user's confirmation request arrives before a merchant's payment request, provided in one or more embodiments of this specification. Figure 4 A flowchart illustrating an automatic conversion processing scheme for a payment confirmation page, provided for one or more embodiments of this specification; Figure 5 This is a flowchart illustrating a scheme for differentiating user account usage based on the order of request arrival, provided for one or more embodiments of this specification. Figure 6 A flowchart illustrating another contactless payment business processing method provided in one or more embodiments of this specification; Figure 7 A schematic diagram of the structure of a contactless payment processing device provided for one or more embodiments of this specification; Figure 8 A schematic diagram of another contactless payment processing device provided in one or more embodiments of this specification; Figure 9 A schematic diagram of the structure of a contactless payment processing device provided for one or more embodiments of this specification; Figure 10 This is a schematic diagram of the structure of another contactless payment processing device provided in one or more embodiments of this specification. Detailed Implementation

[0016] This specification provides embodiments of contactless payment processing methods, apparatus, devices, and storage media.

[0017] 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 application, and not all embodiments. Based on the embodiments of this specification, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this application.

[0018] To facilitate understanding, the applicant's specific concerns will be addressed in more detail, drawing on the description in the background technology section. With offline consumption increasingly replacing cash payments with digital payments, various digital payment capabilities are constantly evolving and upgrading. Besides QR code payments, other payment methods are emerging, such as contactless payments (primarily including NFC, which can be figuratively called "tap-to-pay"), facial recognition, and palm recognition. Among these, tap-to-pay (typically including NFC payments) is gradually expanding in the market due to its advantages of zero barriers to entry, no prior preparation, and no information entry required. To attract users, tap-to-pay needs to go further than existing QR code and other payment methods, providing a better user experience and allowing users to pay with a simple tap, truly experiencing a more comfortable and convenient payment experience than QR code payments. However, due to the limitations in speed and information capacity of information interaction methods such as NFC and Bluetooth, in order to ensure the safety of users' funds, in some scenarios, as attempted by the applicant, after tapping the payment device, a confirmation page will pop up on the user's end of the payment application. Only after the user confirms the payment can the merchant actually initiate a payment request to deduct funds from the user's account. As a result, users and merchants may perceive that tap-to-pay is not as fast as expected, that is, the efficiency problem mentioned in the background technology occurs.

[0019] To address the aforementioned issues, the applicant designed a two-stage rapid payment model. This model allows for pre-processing of payment-related steps (represented as the first stage) without the user's or merchant's awareness, while the user remains on the payment confirmation page. The merchant can initiate the payment in advance (but not immediately, temporarily storing it within the payment application). Upon user confirmation, the merchant's temporarily stored payment is then processed (represented as the second stage), completing the entire transaction. This saves the user's confirmation time by allowing the user's payment confirmation and the merchant's payment initiation to occur in parallel. Furthermore, based on this fundamental idea, the applicant has further refined the solution to ensure smooth user-side response and the security of user-related information, resulting in a more specific implementation plan that can be selected according to actual needs.

[0020] Based on this overall approach, the solution proposed in this application will be further explained below.

[0021] Figure 1 This is a flowchart illustrating a contactless payment business processing method provided in one or more embodiments of this specification. The method is applied to the server and / or user end of a payment application. For ease of description, it can be referred to as a payment application without distinguishing between the server and the user end. The process can be executed entirely by the server or entirely by the user end, or it can be partially executed by the server and partially by the user end.

[0022] The user terminal mainly refers to the application client installed on the user terminal. Of course, it can also be a mini-program or an application that runs on a browser, etc. In short, it refers to the terminal that runs on the user terminal.

[0023] This process also involves one or more devices on the merchant side. The "users" mentioned above refer to consumers making purchases at the merchant's location, in contrast to the merchant. Merchant-side devices include at least sensing devices with functions such as NFC. These sensing capabilities can be integrated into the merchant's POS device, in which case the POS device is considered the sensing device. Alternatively, the POS device and the sensing device can be separate devices. In this case, the POS device's contactless payment capabilities can be expanded by connecting and adapting it to the sensing device.

[0024] In one or more embodiments of this specification, the sensing device is specifically an NFC device. The POS device and the NFC device are provided by different service providers (usually independent companies that may not have a cooperative relationship). The POS device is a basic device typically used by merchants at the checkout counter, commonly a desktop or handheld POS machine, which supports one or more basic payment methods, such as bank card payment, membership card payment, and QR code payment, but does not yet support NFC-based tap-to-pay. The NFC device can be provided by the payment application service provider, providing NFC payment support capabilities. Users can bring their NFC-enabled smartphones or smartwatches (which have the payment application installed) close to the NFC device to perform payment-related transactions based on NFC functionality. It should be noted that, in addition to NFC, sensing can also be achieved through other short-range wireless interaction methods such as infrared or even Bluetooth. This application focuses on NFC because of the needs of current actual business operations, and the solution in this application may also be applicable to other sensing scenarios.

[0025] Figure 1 The process includes the following steps: S102: In response to the user's mobile terminal approaching the merchant's sensing device, a confirmation payment page is determined and provided to the mobile terminal so that the user can initiate a confirmation request through the confirmation payment page.

[0026] In one or more embodiments of this specification, the sensing device can be deployed independently or connected to the merchant's POS terminal (for ease of description, the following embodiments mainly illustrate the latter deployment method). Users prepare for contactless payment by bringing their mobile devices, such as smartphones, close to the sensing device. To make the timing of the operation clearer for the user, the merchant can provide more explicit prompts. For example, the merchant triggers the payment process through the POS terminal, which then sends a command to the sensing device. The sensing device then prompts the user to tap the device to complete the payment. With this prompt, the user can bring their mobile device close to the sensing device, and if the distance is close enough (tapping is a reliable and simple method), the payment will be successfully made.

[0027] The term "merchant" here can refer to a merchant's employee (e.g., a cashier), or it can refer to the merchant's POS equipment or sensor equipment itself (since they are all the merchant's equipment) or the business logic executed on it. The latter case can also include situations where users operate the system themselves.

[0028] The payment application's client is mounted on the user's mobile device. Before proceeding to the payment confirmation page, the payment application decides whether a confirmation page is necessary based on the current situation. If the decision is yes, it continues with subsequent steps. However, if security is high or the transaction is not critical, the decision may be no, in which case a payment confirmation page is unnecessary, and user confirmation (i.e., initiating a confirmation request, as mentioned below) is not required. Instead, the payment process can proceed directly based on the merchant's payment request. The specific decision-making process can be tailored to actual needs; this application does not impose specific limitations, as this is not the focus of this application.

[0029] In one or more embodiments of this specification, a payment confirmation page refers to a page that, in a contactless payment scenario, is determined when a security risk is detected in the user's payment environment. This page requires the user to click for confirmation and is provided to the user to confirm their payment intention. The specific content and layout of the payment confirmation page can be designed as needed. For example, it may include a "Confirm and Pay" button. This page will be displayed on the user's mobile terminal or the merchant's contactless device. The user clicks this button to initiate a confirmation request, indicating that they indeed intend to pay. However, if the user does not want to pay (perhaps due to accidentally being near the contactless device and successfully sensing it, or perhaps the user originally intended to pay but changed their mind at the last minute), they can choose not to initiate a confirmation request. In this case, the subsequent payment process will not be completed normally and can be interrupted at an appropriate point.

[0030] S104: Before the user initiates the confirmation request, determine the corresponding user payment information and provide the user payment information to the sensing device or the merchant POS device connected to the sensing device, so that the merchant can initiate a payment request in advance based on the user payment information.

[0031] In the applicant's previous solution, merchants were only allowed to initiate payment requests after user confirmation; otherwise, they were not even allowed to obtain the corresponding user payment information. Specifically, in this scenario, merchants might even have to wait for the payment application's server (for greater reliability) to receive the user's confirmation request before either the server or the user's client would provide the user's payment information to the merchant. Only then could the merchant initiate a payment request. The user's confirmation process takes time, and the confirmation and provision of user payment information, as well as the merchant's initiation of the payment request, also consume time. Due to this time consumption, users might perceive the subsequent process as slow after confirmation. Combined with the user's own confirmation action, this could make the overall payment process feel disjointed.

[0032] Therefore, in this application's solution, these times are brought forward as much as possible, allowing the corresponding actions to be executed earlier. For example, the confirmation process can be executed in parallel with the user's confirmation process, or even earlier, so that the subsequent payment process can be completed faster after the user's confirmation, avoiding delays caused by waiting for user confirmation. The "forwarding" mentioned in step S104 is relative to the previously adopted solution, which eliminates the need to wait for user confirmation and thus advances the process.

[0033] In one or more embodiments of this specification, user payment information may include credentials used by the user for payment, such as at least one of payment code value, user account, user identity information, and user authorization information. To improve security, this information may be provided to the merchant after privacy protection, and does not necessarily have to be provided in plaintext. User payment information may be remotely pushed by the server to the sensing device or the merchant's POS device, or, if the user's mobile terminal is still within the sensing range of the sensing device, the mobile terminal may also transmit the user payment information to the sensing device through sensing; then, the sensing device or the merchant's POS device may initiate a payment request to the server or the user to request deduction from the corresponding user (i.e., to make the user pay), so as to complete the transaction between the merchant and the user.

[0034] In one or more embodiments of this specification, the user's confirmation process is highly uncontrollable due to factors such as the user's own will and habits. Therefore, the main consideration is to prepare as early as possible from the device's perspective, so that the merchant's actions are as early as possible before the user's actions. For example, the execution time of the confirmation payment page can be referenced, and the user's payment information can be provided to the sensing device or the merchant's POS device connected to the sensing device as soon as possible (e.g., both are performed simultaneously, or when the confirmation payment page is determined, etc.) so as to trigger the merchant to automatically initiate the payment request based on the user's payment information (i.e., initiated automatically by the corresponding device without manual triggering by the store clerk or user).

[0035] S106: Depending on whether the payment request or the confirmation request is received first, the corresponding processing logic is triggered to advance the payment process.

[0036] In one or more embodiments of this specification, there are at least two possible scenarios for receiving payment requests and confirmation requests: the first is that the payment request is received first, followed by the confirmation request; the second is that the confirmation request is received first, followed by the payment request. Corresponding processing logic can be set for these two scenarios (the logic for each scenario can differ, even significantly, as illustrated later), to ensure the payment process proceeds correctly. Of course, other possible scenarios include receiving both the payment request and the confirmation request simultaneously, or at least one request not being received at all.

[0037] This application focuses on the two scenarios mentioned earlier that involve the order of receipt. In these two scenarios, a relatively safe and reliable processing logic could include: if a request is received first, wait to receive the other request, and only proceed with the payment process after both requests have been received. This balances efficiency and security. Subsequent payment processes could include deducting funds from the corresponding user, as well as verifying confirmation requests and assessing merchant risk.

[0038] The two-stage division method was mentioned earlier. Of course, other landmark business actions can also be used as the dividing line, such as confirming the payment page. In this case, the improvement of this application is mainly reflected in the latter stage.

[0039] pass Figure 1 This method allows for the parallelization of the merchant's preparation process while awaiting user confirmation. This includes enabling merchants to obtain user payment information and initiate payment requests in advance. The payment application adapts to the various possible arrival orders of confirmation and payment requests, employing differentiated processing logic to advance the payment process. Therefore, for contactless payment scenarios such as NFC payments, this helps improve the overall efficiency of the payment process and further enhances the user experience. This two-stage, high-speed payment method effectively reduces the perceived time spent on a single payment for both users and merchants, thus facilitating the wider adoption of contactless payments.

[0040] based on Figure 1 In addition to the method described herein, this specification also provides some specific implementation schemes and extension schemes of this method, which will be further explained below.

[0041] Based on the preceding explanation, for ease of understanding, the following provides a practical application scenario for a two-stage rapid payment solution. This scenario involves four parties: the first party is the user, specifically the user and their mobile phone; the second party can be collectively referred to as the merchant, specifically the merchant's staff and the basic POS equipment at their cash register; the third party is the NFC device (also a merchant's device, but listed separately here to distinguish it from traditional POS equipment), which connects to the POS equipment to extend its NFC payment capabilities; the fourth party can be collectively referred to as the payment application, specifically including the payment application's user client and server, with the user client installed on the user's mobile phone.

[0042] The solution mainly includes the following steps: When a merchant's employee clicks to initiate the payment process on the POS device, the NFC device connected to the POS device prompts the user to tap the device to pay. Users take out their phones, tap them against the NFC device, and the payment application is automatically accessed on their phones. The payment application's client or server determines whether a payment confirmation page needs to be displayed based on the context of the user's current payment. If it is determined that a payment confirmation page needs to be displayed, the client or server can simultaneously push the user's payment information to the POS device. The POS device or NFC device can then initiate a payment request to the client or server based on the user's payment information. In parallel, the payment confirmation page will be displayed to the user on the client, and the user can initiate a confirmation request to the client or server by clicking on the payment confirmation page. Next, based on the order in which the payment request and the user confirmation request arrive, combined with... Figure 2 , Figure 3 The two possible processing logics are explained.

[0043] Figure 2 This is a schematic diagram of the business processing flow corresponding to an application scenario provided by one or more embodiments of this specification, in which the merchant's payment request arrives before the user's confirmation request.

[0044] exist Figure 2 As can be seen, before the user initiates a confirmation request, the payment application has already returned the user's payment information to the NFC device, and the merchant has also promptly initiated a payment request, which the payment application receives first. Furthermore, in this scenario, the payment application will temporarily store the payment request, waiting for the user's confirmation request to arrive before proceeding with the payment process. Optionally, while waiting for the confirmation request, the payment process can be initiated in advance based on the payment request, completing the payment process only when the confirmation request finally arrives. This is more efficient. If the confirmation request ultimately fails to arrive, the payment process can be rolled back or the payment can be canceled directly.

[0045] Similarly, Figure 3 This is a schematic diagram of the business process in one or more embodiments of this specification, showing a user's confirmation request arriving before the merchant's payment request.

[0046] exist Figure 3 The difference lies in the fact that after the payment application decides to confirm the payment page, the user confirms very promptly. This results in the payment application receiving the user's confirmation request first, and only then does it return the user's payment information to the NFC device, allowing the merchant to initiate the payment request. Furthermore, in this scenario, the payment application will temporarily store the confirmation request, waiting for the merchant's payment request to arrive before proceeding with the payment process.

[0047] In one or more embodiments of this specification, if a payment request is received first, a payment result is returned to the sensing device or the merchant's POS device connected to the sensing device in response to the merchant's active query; or, as the payment process progresses, the payment result is asynchronously notified to the sensing device or the merchant's POS device connected to the sensing device; for example, in Figure 2 In this case, the payment application temporarily stores the payment request, returns a payment processing prompt to the merchant, and then asynchronously notifies the merchant of the payment result after the payment is completed.

[0048] If a confirmation request is received first, the payment result is synchronously returned to the sensing device or the merchant's POS device connected to the sensing device, adapting to the progress of the payment process. For example, in Figure 3 In this case, the payment application temporarily stores the confirmation request and then proceeds with the payment process after the merchant's payment request arrives. Therefore, the payment result can be returned to the merchant synchronously without the need for asynchronous processing for the merchant.

[0049] As can be seen from the above embodiments, there may be situations where the user's confirmation request arrives first. Although the merchant can prepare in advance in parallel to reduce waiting time, from the user's perspective, they may still feel that they have to wait a little while after confirmation before the payment is completed. To reduce this inconvenient user experience, one or more embodiments of this specification provide a flowchart of an automatic conversion processing scheme for the payment confirmation page. See [link to flowchart]. Figure 4 .

[0050] Figure 4 The process includes the following steps: S402: The payment application determines a confirmation payment page containing a conversion script and provides the confirmation payment page to the mobile terminal.

[0051] In one or more embodiments of this specification, the conversion script is used to: after providing the payment confirmation page to the mobile terminal, and after the user initiates a confirmation request through the payment confirmation page, execute the conversion script on the mobile terminal to convert the payment confirmation page into a payment success notification page, so as to directly notify the user that the payment was successful.

[0052] It's important to note the timing of the payment success notification. This notification is actually executed in advance; the payment hasn't actually been successful yet. The specific timing can be determined based on the necessary elements required for a successful payment. An example is the solution outlined below.

[0053] S404: After the user initiates a confirmation request through the payment confirmation page, if the mobile terminal is still within the sensing range of the sensing device, the conversion script is executed on the mobile terminal in response to the sensing device triggering the mobile terminal through sensing.

[0054] In step S404, after the user's payment information is provided to the sensing device or the merchant's POS device connected to the sensing device, the merchant has the conditions to initiate a payment request. Therefore, there is a high probability that the payment request will be initiated normally. Accordingly, this part of the elements is taken as a necessary element for the payment to be successful. Since the user has also initiated a confirmation request, although the subsequent payment process has not yet progressed, there is a high probability that the payment will be successful. Therefore, by executing the conversion script, the user can be directly notified of success in advance without the need to push the payment success page.

[0055] If the merchant has already received the user's payment information, they can immediately attempt to trigger the mobile terminal via a sensing device to automatically execute the conversion script. Similarly, more reliably, this triggering can be performed promptly after the merchant initiates the payment request.

[0056] Similarly, this can be triggered by the server, so that the transaction can still be successfully completed even if the mobile device moves out of the sensing range. For example, the server can trigger the transaction as soon as it receives the merchant's payment request, without waiting for the payment process to complete.

[0057] S406: The mobile terminal executes the conversion script to convert the payment confirmation page into a payment success notification page, so as to directly notify the user that the payment was successful.

[0058] Thus, from the user's perspective, the payment will appear to be successfully completed smoothly upon confirmation, and the visual effect on the mobile device will be very fluid because there will be no actual page redirection; rather, the content will dynamically change within the same page. Such a notification is highly likely to match the actual result.

[0059] In the rare case where payment fails, the logic can be supplemented with the specific reason for the failure to avoid user misunderstanding and without causing any financial loss. For example, if it's due to the user's fault, the transaction can be automatically converted to credit payment, delaying the deduction and settlement. Alternatively, the user can be notified that the transaction has been cancelled and rolled back. If it's due to the merchant's fault, the merchant can be notified that the transaction has been cancelled. These rare cases have almost no impact on the vast majority of users; therefore, this solution will effectively improve the user experience.

[0060] In some of the embodiments described above, merchants obtain user payment information in advance and can initiate payment requests ahead of time. The server may also advance the payment process. To further enhance security and allow for more flexible implementation, one or more embodiments of this specification also provide a flowchart illustrating a scheme for differentiated user account usage based on the order of request arrival. See [link to flowchart]. Figure 5 .

[0061] Figure 5 The process includes the following steps: S502: When determining the corresponding user payment information, the corresponding user payment information is determined based on the relevant information of the user's first account.

[0062] Relevant information includes, for example, the account itself or the corresponding payment code value.

[0063] S504: When advancing the payment process, if the payment request is received first, the payment process is advanced based on the relevant information of the first account.

[0064] S506: If the confirmation request is received first, the payment process is advanced based on the relevant information of the user's second account associated with the first account, wherein the first account is derived from the second account.

[0065] Both the first and second accounts belong to the current user. Compared to the second account, the first account may be a lighter-weight account (e.g., with a smaller amount of money or a lower account level) and / or an account with weaker privacy (e.g., concealing or obfuscating a lot of the user's real information). In comparison, the exposure of relevant information in the first account is more serious for the user and is more likely to threaten the user's interests and security. Therefore, in cases where the risk is relatively higher, the first account should be used first, while in cases where the risk is low, the system can intelligently and automatically switch to the second account.

[0066] Based on this approach, in step S504, a payment request is received first, but the user's confirmation request has not yet been received. Therefore, the user's true intention is uncertain, which can be considered a relatively high-risk situation. Thus, the payment process proceeds based on the information from the first account. In step S506, a confirmation request is received first, confirming the user's true intention. This can be considered a low-risk situation. Therefore, the process automatically switches to proceeding based on the information from the second account. This effectively reduces the possibility of exposing the second account's information (especially avoiding exposure to the merchant) without affecting the payment process.

[0067] In step S508, the example is a first account separated from the second account. Other methods can also be used, such as the user setting up a separate first account and then associating it with the second account; or the payment application generating a temporary account for the user as the first account and then associating it with the second account; and so on. The aim is to maximize the isolation between the information of the first account and the information of the second user to avoid mutual impact on privacy and security.

[0068] S508: After proceeding with the payment process based on the relevant information of the first account, the first account is merged back into the second account after the corresponding payment is successful.

[0069] The second account can be an account that the user explicitly uses, making the first account invisible to the user. For example, based on the solution in step S508, even if the first account is involved in the process, what the user actually experiences (such as relevant process prompts, subsequent bills, etc.) is still only related to the second account. In this way, the user's understanding cost is reduced, while security is enhanced.

[0070] The above explanation primarily focuses on the payment application perspective. Based on the same approach, one or more embodiments of this specification also provide a flowchart illustrating another contactless payment processing method, applied to a merchant's sensing device. This is described from the perspective of the sensing device. See [link / reference]. Figure 6 .

[0071] Figure 6 The process includes the following steps: S602: In response to the user's mobile terminal approaching the merchant's sensing device, the server and / or user terminal of the payment application are triggered to determine the payment confirmation page, so that the user can initiate a confirmation request to the server and / or user terminal through the payment confirmation page.

[0072] S604: Receive user payment information provided by the server and / or user before the user initiates the confirmation request, so that the merchant can initiate a payment request in advance based on the user payment information; wherein, the payment process is advanced by the server and / or user triggering corresponding processing logic based on whether the payment request or the confirmation request is received first.

[0073] Based on the preceding explanation, understand Figure 6 The process is straightforward and will not be elaborated upon here.

[0074] Based on the same idea, one or more embodiments of this specification also provide apparatus and devices corresponding to the above methods, such as... Figures 7-10As shown. The apparatus and equipment are capable of performing the above methods and related alternatives accordingly.

[0075] Figure 7 This specification provides a schematic diagram of the structure of a contactless payment processing device according to one or more embodiments, applied to the server and / or user end of a payment application. The device includes: The confirmation request support module 702, in response to the user's mobile terminal approaching the merchant's sensing device to perform a sensing operation, determines a confirmation payment page and provides the confirmation payment page to the mobile terminal so that the user can initiate a confirmation request through the confirmation payment page; The payment request support module 704 determines the corresponding user payment information before the user initiates the confirmation request, and provides the user payment information to the sensing device or the merchant POS device connected to the sensing device, so that the merchant can initiate a payment request in advance based on the user payment information. The payment process advancement module 706 advances the payment process by triggering corresponding processing logic based on whether the payment request or the confirmation request is received first.

[0076] Optionally, the user's mobile terminal is brought close to the merchant's sensing device for sensing after the merchant triggers the payment process through the merchant's POS device, prompting the sensing device to prompt the user to perform the sensing action.

[0077] Optionally, when the payment request support module 704 determines the payment confirmation page, it provides the user payment information to the sensing device or the merchant POS device connected to the sensing device, so as to trigger the merchant to automatically initiate the payment request based on the user payment information.

[0078] Optionally, if the payment process advancement module 706 receives the payment request first, it temporarily stores the payment request and advances the payment process after waiting for the confirmation request to arrive; or, while waiting for the confirmation request to arrive, it advances the payment process ahead of time based on the payment request.

[0079] Optionally, if the payment process advancement module 706 receives the confirmation request first, it temporarily stores the confirmation request and waits for the payment request to arrive. After the payment request arrives, the payment process proceeds.

[0080] Optionally, the confirmation request support module 702 determines a confirmation payment page containing a conversion script. The conversion script is used to: after the confirmation payment page is provided to the mobile terminal, and after the user initiates a confirmation request through the confirmation payment page, execute the conversion script on the mobile terminal to convert the confirmation payment page into a payment success prompt page, so as to directly prompt the user that the payment was successful.

[0081] Optionally, the payment request support module 704 determines the corresponding user payment information based on the relevant information of the user's first account; If the payment process advancement module 706 receives the payment request first, it will advance the payment process based on the relevant information of the first account. If the confirmation request is received first, the payment process is advanced based on the relevant information of the user's second account associated with the first account.

[0082] Optionally, the first account is obtained by separating it from the second account; After the payment process is advanced based on the relevant information of the first account, the payment process advancement module 706 merges the first account back into the second account after the corresponding payment is successful.

[0083] Figure 8 This is a schematic diagram of another contactless payment processing device provided in one or more embodiments of this specification, applied to a merchant's contactless device, the device comprising: The sensing interaction trigger module 802, in response to the user's mobile terminal approaching the merchant's sensing device to perform a sensing operation, triggers the server and / or user terminal of the payment application to determine the payment confirmation page, so that the user can initiate a confirmation request to the server and / or user terminal through the payment confirmation page; The payment information receiving module 804 receives user payment information provided by the server and / or the user terminal before the user initiates the confirmation request, so that the merchant can initiate a payment request in advance based on the user payment information. The payment process is initiated by the server and / or the user, which trigger corresponding processing logic based on whether the payment request or the confirmation request is received first.

[0084] Figure 9 This specification provides a schematic diagram of the structure of a contactless payment processing device according to one or more embodiments, applicable to the server and / or user end of a payment application. The contactless payment processing device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: In response to the user's mobile terminal approaching the merchant's sensing device, a confirmation payment page is determined and provided to the mobile terminal so that the user can initiate a confirmation request through the confirmation payment page; Before the user initiates the confirmation request, the corresponding user payment information is determined and provided to the sensing device or the merchant POS device connected to the sensing device, so that the merchant can initiate a payment request in advance based on the user payment information. Depending on whether the payment request or the confirmation request is received first, the corresponding processing logic is triggered to advance the payment process.

[0085] Figure 10 This is a schematic diagram of the structure of a contactless payment processing device provided in one or more embodiments of this specification, applied to a merchant's contactless payment device. The contactless payment processing device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: In response to the user's mobile terminal approaching the merchant's sensing device, the server and / or user terminal of the payment application are triggered to determine the payment confirmation page, so that the user can initiate a confirmation request to the server and / or user terminal through the payment confirmation page; The merchant receives user payment information provided by the server and / or the user before the user initiates the confirmation request, so that the merchant can initiate a payment request in advance based on the user payment information. The payment process is initiated by the server and / or the user, which trigger corresponding processing logic based on whether the payment request or the confirmation request is received first.

[0086] Based on the same idea, one or more embodiments of this specification also provide a non-volatile computer storage medium for use in the server and / or user end of a payment application, wherein the medium stores computer-executable instructions configured as follows: In response to the user's mobile terminal approaching the merchant's sensing device, a confirmation payment page is determined and provided to the mobile terminal so that the user can initiate a confirmation request through the confirmation payment page; Before the user initiates the confirmation request, the corresponding user payment information is determined and provided to the sensing device or the merchant POS device connected to the sensing device, so that the merchant can initiate a payment request in advance based on the user payment information. Depending on whether the payment request or the confirmation request is received first, the corresponding processing logic is triggered to advance the payment process.

[0087] One or more embodiments of this specification also provide another non-volatile computer storage medium for use in a merchant's sensing device, the medium storing computer-executable instructions configured as follows: In response to the user's mobile terminal approaching the merchant's sensing device, the server and / or user terminal of the payment application are triggered to determine the payment confirmation page, so that the user can initiate a confirmation request to the server and / or user terminal through the payment confirmation page; The merchant receives user payment information provided by the server and / or the user before the user initiates the confirmation request, so that the merchant can initiate a payment request in advance based on the user payment information. The payment process is initiated by the server and / or the user, which trigger corresponding processing logic based on whether the payment request or the confirmation request is received first.

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

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

[0090] 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, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or any combination of these devices.

[0091] For ease of description, the above devices are described in terms of function, divided into various units. Of course, in implementing this specification, the functions of each unit can be implemented in one or more software and / or hardware.

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

[0093] This specification is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this specification. 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.

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

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

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

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

[0098] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic 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.

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

[0100] This specification can be described in the general context of computer-executable instructions that are executed by a computer, such as program modules. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This specification 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.

[0101] The various embodiments in this specification are described in a progressive manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the embodiments of apparatus, devices, and non-volatile computer storage media are basically similar to the method embodiments, so the descriptions are relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0102] 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 the specific or sequential order shown to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0103] The above description is merely one or more embodiments of this specification and is not intended to limit this specification. Various modifications and variations can be made to the one or more embodiments of this specification by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principle of one or more embodiments of this specification should be included within the scope of the claims of this specification.

Claims

1. A contactless payment transaction processing method, applied to the server and / or user end of a payment application, the method comprising: In response to the user's mobile terminal approaching the merchant's sensing device, a confirmation payment page is determined and provided to the mobile terminal so that the user can initiate a confirmation request through the confirmation payment page; Before the user initiates the confirmation request, the corresponding user payment information is determined and provided to the sensing device or the merchant POS device connected to the sensing device, so that the merchant can initiate a payment request in advance based on the user payment information. Depending on whether the payment request or the confirmation request is received first, the corresponding processing logic is triggered to advance the payment process.

2. The method as described in claim 1, wherein the user's mobile terminal approaches the merchant's sensing device to perform the sensing operation, is executed after the merchant triggers the payment process through the merchant's POS device, so that the sensing device prompts the user to perform the sensing operation.

3. The method as described in claim 1, wherein providing the user payment information to the sensing device or the merchant POS device connected to the sensing device specifically includes: When the payment confirmation page is determined, the user's payment information is provided to the sensing device or the merchant's POS device connected to the sensing device, so as to trigger the merchant to automatically initiate the payment request based on the user's payment information.

4. The method as described in claim 1, wherein triggering corresponding processing logic to advance the payment process based on whether the payment request or the confirmation request is received first, specifically includes: If the payment request is received first, the payment request is temporarily stored, and the payment process is initiated after the confirmation request arrives. Alternatively, while waiting for the confirmation request to arrive, the payment process is initiated ahead of schedule based on the payment request.

5. The method as described in claim 1, wherein triggering corresponding processing logic to advance the payment process based on whether the payment request or the confirmation request is received first, specifically includes: If the confirmation request is received first, the confirmation request is temporarily stored, and the payment request is awaited. After the payment request arrives, the payment process proceeds.

6. The method as described in claim 1 or 4, wherein determining the payment confirmation page specifically includes: A confirmation payment page containing a conversion script is determined. The conversion script is used to: after the confirmation payment page is provided to the mobile terminal, and after the user initiates a confirmation request through the confirmation payment page, execute the conversion script on the mobile terminal to convert the confirmation payment page into a payment success prompt page, so as to directly prompt the user that the payment was successful.

7. The method as described in claim 6, wherein executing the conversion script on the mobile terminal specifically includes: After the user payment information is provided to the sensing device or the merchant POS device connected to the sensing device, if the mobile terminal is still within the sensing range of the sensing device, the conversion script is executed on the mobile terminal in response to the triggering of the mobile terminal by the sensing device.

8. The method as described in claim 1, wherein determining the corresponding user payment information specifically includes: Based on the relevant information of the user's first account, determine the corresponding user payment information; The decision to proceed with the payment process is based on whether the payment request or the confirmation request is received first, triggering corresponding processing logic. This includes: If the payment request is received first, the payment process will proceed based on the relevant information of the first account; If the confirmation request is received first, the payment process is advanced based on the relevant information of the user's second account associated with the first account.

9. The method of claim 8, wherein the first account is derived from the second account; After proceeding with the payment process based on the relevant information of the first account, the method further includes: After the corresponding payment is successful, the first account will be merged back into the second account.

10. The method of claim 8 or 9, wherein the first account is a lighter-weight and / or less privacy-sensitive account compared to the second account.

11. The method as described in claim 1, wherein triggering corresponding processing logic to advance the payment process based on whether the payment request or the confirmation request is received first specifically includes: If the payment request is received first, the payment result is returned to the sensing device or the merchant's POS device connected to the sensing device in response to the merchant's active query; or, as the payment process progresses, the payment result is asynchronously notified to the sensing device or the merchant's POS device connected to the sensing device. If the confirmation request is received first, the payment result is synchronously returned to the sensing device or the merchant POS device connected to the sensing device, in accordance with the progress of the payment process.

12. The method of claim 1, wherein before determining the payment confirmation page, the method further comprises: The decision is made as to whether the payment page needs to be confirmed, and the result of the decision is confirmed as yes. The method further includes: If the decision result is negative, the payment process will proceed directly based on the received payment request without requiring the user to initiate the confirmation request.

13. The method according to any one of claims 1 to 5, wherein the sensing is based on NFC functionality, and the sensing device includes an NFC device.

14. A method for processing contactless payment transactions, applied to a merchant's contactless device, the method comprising: In response to the user's mobile terminal approaching the merchant's sensing device, the server and / or client of the payment application are triggered to determine the payment confirmation page, so that the user can initiate a confirmation request to the server and / or client through the payment confirmation page; The merchant receives user payment information provided by the server and / or the user before the user initiates the confirmation request, so that the merchant can initiate a payment request in advance based on the user payment information. The payment process is initiated by the server and / or the user, which trigger corresponding processing logic based on whether the payment request or the confirmation request is received first.

15. A contactless payment processing device, applied to the server and / or user end of a payment application, the device comprising: The confirmation request support module, in response to the user's mobile terminal approaching the merchant's sensing device to perform a sensing operation, determines the confirmation payment page and provides the confirmation payment page to the mobile terminal so that the user can initiate a confirmation request through the confirmation payment page; The payment request support module determines the corresponding user payment information before the user initiates the confirmation request, and provides the user payment information to the sensing device or the merchant POS device connected to the sensing device, so that the merchant can initiate a payment request in advance based on the user payment information. The payment process advancement module triggers corresponding processing logic based on whether the payment request or the confirmation request is received first, in order to advance the payment process.

16. In the apparatus of claim 15, the operation of the user's mobile terminal approaching the merchant's sensing device is performed after the merchant triggers the payment process through the merchant's POS device, causing the sensing device to prompt the user to perform the sensing.

17. The apparatus of claim 15, wherein the payment request support module, upon determining the payment confirmation page, provides the user payment information to the sensing device or the merchant POS device connected to the sensing device, thereby triggering the merchant to immediately and automatically initiate the payment request based on the user payment information.

18. The apparatus of claim 15, wherein if the payment process advancement module receives the payment request first, it temporarily stores the payment request and advances the payment process after waiting for the confirmation request to arrive; or, while waiting for the confirmation request to arrive, it advances the payment process ahead of schedule according to the payment request.

19. The apparatus of claim 15, wherein if the payment process advancement module receives the confirmation request first, it temporarily stores the confirmation request and waits for the payment request to arrive; After the payment request arrives, the payment process proceeds.

20. The apparatus of claim 15 or 18, wherein the confirmation request support module determines a confirmation payment page including a conversion script, the conversion script being configured to: after the confirmation payment page is provided to the mobile terminal, and after the user initiates a confirmation request through the confirmation payment page, convert the confirmation payment page into a payment success notification page by executing the conversion script on the mobile terminal, so as to directly notify the user of payment success.

21. The apparatus of claim 15, wherein the payment request support module determines the corresponding user payment information based on the relevant information of the user's first account; If the payment process advancement module receives the payment request first, it will advance the payment process based on the relevant information of the first account. If the confirmation request is received first, the payment process is advanced based on the relevant information of the user's second account associated with the first account.

22. The apparatus of claim 21, wherein the first account is derived from the second account; After the payment process is advanced based on the relevant information of the first account, the payment process advancement module merges the first account back into the second account after the corresponding payment is successful.

23. A contactless payment processing device, applied to a merchant's sensing equipment, the device comprising: The sensing interaction trigger module responds to the user's mobile terminal approaching the merchant's sensing device to trigger the payment application's server and / or user terminal to determine the payment confirmation page, so that the user can initiate a confirmation request to the server and / or user terminal through the payment confirmation page; The payment information receiving module receives user payment information provided by the server and / or the user before the user initiates the confirmation request, so that the merchant can initiate a payment request in advance based on the user payment information. The payment process is initiated by the server and / or the user, which trigger corresponding processing logic based on whether the payment request or the confirmation request is received first.

24. A contactless payment processing device, applied to the server and / or user end of a payment application, the contactless payment processing device comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: In response to the user's mobile terminal approaching the merchant's sensing device, a confirmation payment page is determined and provided to the mobile terminal so that the user can initiate a confirmation request through the confirmation payment page; Before the user initiates the confirmation request, the corresponding user payment information is determined and provided to the sensing device or the merchant POS device connected to the sensing device, so that the merchant can initiate a payment request in advance based on the user payment information. Depending on whether the payment request or the confirmation request is received first, the corresponding processing logic is triggered to advance the payment process.

25. A contactless payment processing device, applied to a merchant's contactless device, the contactless payment processing device comprising: At least one processor; as well as, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to perform: In response to the user's mobile terminal approaching the merchant's sensing device, the server and / or client of the payment application are triggered to determine the payment confirmation page, so that the user can initiate a confirmation request to the server and / or client through the payment confirmation page; The merchant receives user payment information provided by the server and / or the user before the user initiates the confirmation request, so that the merchant can initiate a payment request in advance based on the user payment information. The payment process is initiated by the server and / or the user, which trigger corresponding processing logic based on whether the payment request or the confirmation request is received first.

Images