Payment method and apparatus, and device

Abstract

Embodiments of the present specification disclose a payment method and apparatus, and a device, which are applied to a client of a payment application. For both parties, i.e., the payer and the payee, of the payment, hardware requirements are reduced, convenience is improved, payments of a large amount can be well supported, and the user experience is better. The solution comprises: receiving an evocation instruction, an initiation means of the evocation instruction comprising: a mobile device where a client is located reading a near-field communication label of a payee, obtaining a corresponding code value, and sending the evocation instruction and providing the code value to the client; in response to the evocation instruction, obtaining related information of the payee on the basis of the code value; when a current payment is a large amount payment, on the basis of the related information, triggering a server of a payment application to obtain a dynamic code of the payee, and, on the basis of the dynamic code of the payee, perform corresponding large amount payment processing; and receiving a payment result returned by the server.

Description

Payment method, device and equipment Technical Field

[0001] This specification relates to the field of electronic payment technology, and in particular to a payment method, device, and equipment. Background Art

[0002] With the development of electronic payment technology and the popularization of smart mobile devices, QR code-based payment has become one of the main means of payment for small payments in people's daily lives, bringing great convenience to both payers and recipients.

[0003] There are currently two main user operation methods for QR code-based payments, taking the user as the payer and the merchant as the payee as an example. The first method is: the user generates and displays the payment code on their terminal (usually a smartphone), and the merchant uses a barcode scanner or other scanning device to scan the payment code to complete the payment. This method belongs to the payee's main scanning scenario. The second method is: the merchant displays (either electronically or physically) their payment code, and the user uses the camera of their terminal to scan the payment code to complete the payment. This method belongs to the payee's main scanning scenario.

[0004] With the rise of wearable devices represented by smart watches, more and more users are using smart watches to make payments. Since smart watches are worn on the wrist, users can simply reach out and operate them without having to take their phones out of their pockets or bags, which further enhances convenience.

[0005] Currently, many smartwatches do not have cameras. Therefore, when using such smartwatches to make payments based on QR codes, since they cannot scan the merchant's payment code, the second method mentioned above cannot be used. Instead, the first method mentioned above can only be used, which is to display the payment code on the smartwatch so that the merchant can scan the code. However, in actual applications, since many small businesses (such as convenience stores, small vendors, etc.) do not have barcode scanning equipment such as barcode scanners, they only print and post their own payment codes for users to scan and pay, and do not support the first method mentioned above. Therefore, in such small business scenarios, users often find it difficult to use wearable devices such as smartwatches that do not have cameras to make payments based on QR codes. Moreover, smartwatches currently do not support large-value payments, and even when using smartphones to make large-value payments based on QR codes, they are often limited or the required user operations are relatively cumbersome.

[0006] Based on this, for small merchant scenarios, there is a need for solutions that help users use wearable devices to conveniently make large payments.

[0007] Summary of the Invention

[0008] One or more embodiments of the present specification provide a payment method, which is applied to a client of a payment application, the method comprising: receiving a wake-up instruction, wherein the initiation method of the wake-up instruction comprises: the mobile device where the client is located reads the short-range wireless communication tag of the payee, obtains a corresponding code value, sends the wake-up instruction to the client and provides the code value; in response to the wake-up instruction, obtains relevant information of the payee according to the code value; in the case where this payment is a large-amount payment, triggers the server of the payment application to obtain and perform corresponding large-amount payment processing according to the dynamic code of the payee according to the relevant information; and receives the payment result returned by the server.

[0009] One or more embodiments of the present specification provide a payment device, which is applied to a client of a payment application, and the device includes: an instruction receiving module, which receives a wake-up instruction, wherein the initiation method of the wake-up instruction includes: the mobile device where the client is located reads the short-range wireless communication tag of the payee, obtains the corresponding code value, sends the wake-up instruction to the client and provides the code value; a code value parsing module, which responds to the wake-up instruction and obtains relevant information of the payee according to the code value; a payment triggering module, which, when the current payment is a large-amount payment, triggers the server of the payment application to obtain and perform corresponding large-amount payment processing according to the dynamic code of the payee based on the relevant information; and a result receiving module, which receives the payment result returned by the server.

[0010] One or more embodiments of this specification provide a payment device, which is applied to a client of a payment application. The device includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein:

[0011] The memory stores instructions that can be executed by the at least one processor, and the instructions are executed by the at least one processor so that the at least one processor can: receive a wake-up instruction, wherein the initiation method of the wake-up instruction includes: the mobile device where the client is located reads the short-range wireless communication tag of the payee, obtains the corresponding code value, sends the wake-up instruction to the client and provides the code value; in response to the wake-up instruction, obtains relevant information of the payee according to the code value; in the case that this payment is a large-amount payment, based on the relevant information, triggers the server of the payment application to obtain and perform corresponding large-amount payment processing according to the dynamic code of the payee; and receives the payment result returned by the server.

[0012] One or more embodiments of the present specification provide a non-volatile computer storage medium storing computer-executable instructions, which are applied to a client of a payment application, wherein the computer-executable instructions are configured to: receive a wake-up instruction, wherein the initiation method of the wake-up instruction includes: the mobile device where the client is located reads the short-range wireless communication tag of the payee, obtains a corresponding code value, sends the wake-up instruction to the client and provides the code value; in response to the wake-up instruction, obtains relevant information of the payee according to the code value; based on the relevant information, simulates a predetermined process of scanning and paying when the payee is the code scanner; by executing the simulated predetermined process, initiates a payment request to the server corresponding to the payee on behalf of the payee to obtain the payment result returned by the server.

[0013] At least one of the above-mentioned technical solutions adopted in one or more embodiments of this specification can achieve the following beneficial effects: small merchants can conveniently support wearable device-based payments by setting up a short-range wireless communication tag with their own relevant information (for example, identity or payment code value, etc.). Users can specifically read the short-range wireless communication tag through a wearable device to obtain relevant information of the small merchant. Furthermore, even if the user's wearable device does not have a code scanning function, the small merchant does not have a code scanning machine and does not actually scan the user's code, it can further trigger the server to obtain the payee's dynamic code based on the dynamic code based on the relevant information and realize large-value payments based on the dynamic code. The whole process has very low user operation requirements and is very convenient. It also guarantees the risk control requirements involved in large-value payments and tries to avoid the spillover of key information involved in large-value payments. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0015] FIG1 is a flow chart of a payment method provided in one or more embodiments of this specification.

[0016] FIG2 is a flow chart of a solution for a server to obtain a payee's dynamic code provided in one or more embodiments of this specification.

[0017] FIG3 is a flowchart of a solution for finely controlling services by using the payer to confirm the use of a dynamic code, provided in one or more embodiments of this specification.

[0018] FIG4 is a flow chart of a solution for reliability control of an actual payment amount provided in one or more embodiments of this specification.

[0019] FIG5 is a schematic diagram of an application scenario of the method of FIG1 provided in one or more embodiments of this specification.

[0020] FIG6 is a flowchart of a solution for performing large-amount payment for a specific scenario in the main scenario of FIG5 , provided by one or more embodiments of this specification.

[0021] FIG7 is a flowchart of a solution for performing large-amount payments for another subdivided scenario under the main scenario of FIG5 provided by one or more embodiments of this specification.

[0022] FIG8 is a schematic diagram of the structure of a payment device provided in one or more embodiments of this specification.

[0023] FIG9 is a schematic diagram of the structure of a payment device provided in one or more embodiments of this specification. DETAILED DESCRIPTION

[0024] The embodiments of this specification provide a payment method, apparatus, device, and storage medium.

[0025] In order 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 in conjunction with the drawings in the embodiments of this specification. Obviously, the embodiments described are only part of the embodiments of this application, not all of the embodiments. Based on the embodiments of this specification, all other embodiments obtained by ordinary technicians in this field without making creative efforts should fall within the scope of protection of this application.

[0026] As can be seen from the introduction of background technology, many small businesses, due to limitations in operating costs or venues, do not have barcode scanning equipment such as barcode scanners, resulting in payment scenarios that do not support merchant-led scanning. When users (i.e., payers) use mobile devices without cameras or cameras that support barcode scanning, it is difficult to implement user-led scanning, thus posing a dilemma. Moreover, current mobile devices, especially smart watches, do not support large-value payments, which further inconveniences users. In order to solve these problems, this application introduces the use of NFC tags in conjunction with the payee's dynamic code, so that large-value payments can be conveniently made on mobile devices such as smart watches. Furthermore, the solution is further optimized to improve business flexibility from the user's perspective under large-value payments, and to strengthen mutual trust between the payee and the payee.

[0027] Based on this general idea, the solution of this application will be described in detail below.

[0028] FIG1 is a flow chart of a payment method provided in one or more embodiments of this specification. This method can be applied to a client of a payment application, which is located on a mobile device. The advantages of this solution can be particularly reflected for wearable devices, especially those that do not have a camera that supports code scanning. Wearable devices are represented by smart watches. In addition, other wearable devices that support short-range wireless communication (such as smart bracelets) may also use this solution. For ease of description, the following embodiments are mainly described using smart watches as an example.

[0029] The process in FIG1 includes steps S102 to S108 .

[0030] S102: receiving a wake-up instruction, wherein the initiation method of the wake-up instruction includes: the mobile device where the client is located reads the short-range wireless communication tag of the payee, obtains a corresponding code value, sends the wake-up instruction to the client and provides the code value.

[0031] In one or more embodiments of the present specification, the payee (for example, the small merchant mentioned above) is pre-deployed with a short-range wireless communication tag, which contains relevant information of the payee (for example, reflected in a corresponding code value, which may not be plain text, so that the security is better). Based on the relevant information, the identity of the payee can be determined (if necessary, more information may be determined, such as authorization information, amount to be paid, etc.), such as the merchant name or payment account number, etc. The server of the payment application can transfer the amount paid by the payer to the payee based on the identity.

[0032] The relevant information is, for example, the information contained in the payee's payment code (currently usually a QR code). In order to facilitate different payment methods, the payee can, on the basis of providing a payment code for users to scan and pay, further deploy a short-range wireless communication tag for use by payers who are inconvenient or unable to scan the code. In this case, for example, the proximity of the short-range wireless communication tag also displays: the payee's payment code generated according to the code value, and the payer can flexibly choose the short-range wireless communication tag or payment code for interaction according to the situation of his or her own device. It is possible to write the code value into the short-range wireless communication tag first, or to generate the payment code based on the code value first. The preliminary preparations for these two methods can be carried out independently.

[0033] In one or more embodiments of this specification, since many mobile devices support near field communication (NFC) function and the cost of NFC tags is relatively low, NFC tags can be used as short-range wireless communication tags. In this case, the short-range wireless communication is specifically near field communication.

[0034] In one or more embodiments of this specification, when a payer wants to make a payment, they can hold their smartwatch near the payee's NFC tag. The corresponding NFC module within the smartwatch can then read the code value contained in the NFC tag. A microprocessor or related module within the smartwatch can then invoke the payment application client on the smartwatch and provide the code value read by the NFC module to the payment application client. This process is easy for the payer and, if desired, can even be accomplished without using the smartwatch dial, providing a better user experience.

[0035] S104: In response to the call instruction, obtain relevant information of the payee according to the code value.

[0036] In one or more embodiments of this specification, the code value can be parsed locally on the client, or the client can parse the code value through the server to obtain relevant information about the payee. This helps the client directly understand the current payee and helps improve payment security. Of course, the code value itself can also be used as relevant information about the payee.

[0037] S106: In the case that this payment is a large-value payment, based on the relevant information, the server of the payment application is triggered to obtain and perform corresponding large-value payment processing based on the dynamic code of the payee (mainly referring to the key content contained in the dynamic code).

[0038] The payment amount can be manually entered by the payer on the client, or read from the payee's NFC tag via the client's mobile device. If the payment amount is not less than a specified amount threshold, the payment is considered a large amount.

[0039] In one or more embodiments of this specification, for non-high-value payments, a static code may be used instead of a dynamic code. Both the dynamic and static codes are the payee's codes. In contrast, a static code remains static or only changes after a long period of time, while a dynamic code is updated more frequently based on time or the number of payments, for example, every two minutes or for each high-value payment.

[0040] The static code contains relevant information about the payee and can be used to determine the payee's account number. When using a static code, the code value obtained by the mobile device reading the payee's NFC tag in step S102 is the static code. The dynamic code can also contain relevant information about the payee, as well as data such as a timestamp and signature. In some special scenarios of the solution of this application, the dynamic code can also include personalized extension fields, which will be explained in examples below.

[0041] Currently, wearable devices such as smartwatches do not support large-value payments. Traditional large-value payment solutions often require the payer to re-trigger the payment, or require the payer or payee to receive and enter a verification code for re-verification, resulting in redundant execution of some services or cumbersome user operations. This application solves these problems by using the payee's dynamic code and controlling the specific timing of the dynamic code intervention on the server side.

[0042] The server can obtain the payee's dynamic code from the client at the client's trigger, without requiring the payee to redundantly perform business steps, or it can obtain the dynamic code independently of the client. The latter solution is preferred, as it helps to narrow the scope of the dynamic code, control the dynamic code on the service provider's side, and improve interaction efficiency. For the payer and the payee, this process is less intrusive or even unnecessary, providing a better experience, greater security, and greater reliability. Furthermore, it provides the payee and the payee with personalized means to flexibly control business operations based on the dynamic code.

[0043] For example, suppose that a method of obtaining the payee's dynamic code from the client is adopted. Then the short-range wireless communication tag may include: the payee's dynamic code generated or applied for by the payee and dynamically updated in the short-range wireless communication tag. The writing action can be automatically triggered based on whether the validity period of the dynamic code has expired, or it can be executed immediately when a large payment is about to occur (for example, the payee has determined the amount to be paid, and the amount to be paid is a large amount). If the application can be from the server or a third party outside the server, for example, the third party is other merchant system service providers, in this case, the server can also have a cooperative relationship with the merchant system service provider to support the use of dynamic codes.

[0044] Based on the premise of this example, the above-mentioned triggering of the payment application server to obtain and perform corresponding large-value payment processing based on the payee's dynamic code according to relevant information may specifically include: determining the payee's dynamic code based on the reading result of the short-range wireless communication tag, interacting with the payment application server based on relevant information and the payee's dynamic code (for example, the dynamic code can be sent to the server), so that the server obtains the payee's dynamic code and performs corresponding large-value payment processing based on the payee's dynamic code.

[0045] For another example, assuming that a method of obtaining a dynamic code that does not rely on the client is adopted, see Figure 2 , which is a flow chart of a solution for a server to obtain a payee's dynamic code according to one or more embodiments of this specification.

[0046] The solution in FIG2 includes steps S202 to S208 .

[0047] S202: Display the payment amount input page.

[0048] The example here uses the payee manually entering the payment amount. Automatically determining the payment amount without relying on the payee's manual input is also possible.

[0049] S204: Receive the large payment amount that is not less than the specified amount threshold entered by the payer through the payment amount input page to confirm that this payment is a large payment.

[0050] In one or more embodiments of the present specification, after the payer enters the payment amount, it can be determined whether the current payment is a large-amount payment. If so, the subsequent steps involving dynamic codes are enabled. In this case, the code written in the payee's short-range wireless communication tag can be a static code. After obtaining the payee's relevant information based on the static code, the payer is asked to enter the payment amount.

[0051] In addition, a payment solution based on dynamic codes can also be adopted by default. In this case, there is no need to explicitly determine whether the payment is a large-value payment. For example, a dynamic tag can be used as a short-range wireless communication tag, in which the dynamic code can be maintained and updated in a timely manner, so that the server can obtain the dynamic code more conveniently by directly interacting with the client.

[0052] S206: Initiate payment to the server of the payment application according to the relevant information, so that the server generates or obtains a dynamic code from other service providers as the dynamic code of the payee, and prompts the client.

[0053] If the server cannot obtain the dynamic code directly from the client (in this case, the client actually initiates payment based on the static code server), it can generate the dynamic code itself or apply for it from other service providers (such as the third-party merchant system service providers mentioned above).

[0054] In one or more embodiments of the present specification, since the payment will be changed from being based on a static code (the code originally read by the payer's mobile device based on short-range communication) to being based on a dynamic code (the code initiated by the server), the payer has the right to know. In order to improve security, the above-mentioned prompt can be proactively given to the client, so that the payer can realize based on the prompt that the server needs to perform special processing this time to adapt to the requirements of large-amount payments.

[0055] S208: Receive the corresponding confirmation of the payee on the client, and according to the result of the corresponding confirmation, trigger the server to continue to perform the corresponding large-amount payment processing according to the dynamic code of the payee.

[0056] In one or more embodiments of the present specification, in addition to indicating consent for the server to continue operations based on the dynamic code, the corresponding confirmation may also allow the payer to perform more flexible business control accordingly. In this case, the result of the corresponding confirmation may carry the payer's personalized business control field to perform fine control over the business involved in this large-value payment. This helps to converge such control authority to a portion of payment transactions (for example, only large-value payment transactions, which are usually only a small portion of payment transactions), and allows the business processing of non-large-value payments to remain lightweight from the payer's perspective, so as to avoid unnecessary waste of resources, thereby optimizing resource allocation for the payment service provider as a whole and helping to make resources play a more full and focused role.

[0057] In one or more embodiments of this specification, by switching to the use of dynamic codes, the server can implement risk control requirements in large-value payment scenarios based on dynamic codes, thereby enabling wearable devices to also support large-value payments. For example, this can include reviewing and auditing large-value inflows to the payee, ensuring the security of large-value outflows to the payee, proactively mitigating the risk of static code attacks, and narrowing the window of exposure for payment-related information.

[0058] S108: Receive the payment result returned by the server.

[0059] The server can also notify the payee or other third parties involved of the corresponding results.

[0060] Through the method of Figure 1, small merchants can conveniently support wearable device-based payments by setting up short-range wireless communication tags with their own relevant information (such as identity or payment code values, etc.). Users can specifically read the short-range wireless communication tags through wearable devices to obtain relevant information of the small merchant. Furthermore, even if the user's wearable device does not have a code scanning function, the small merchant does not have a code scanning machine and does not actually scan the user's code, it can also trigger the server to obtain the payee's dynamic code based on the dynamic code based on the relevant information and realize large-scale payments based on the dynamic code. The whole process has very low user operation requirements and is very convenient. It also guarantees the risk control requirements involved in large-scale payments and tries to avoid the spillover of key information involved in large-scale payments.

[0061] Based on the method of FIG1 , this specification also provides some specific implementation plans and extension plans of the method, which will be described below.

[0062] As mentioned above, the introduction of dynamic codes can help payers to perform more flexible business control. To facilitate intuitive understanding, one or more embodiments of this specification provide a flow chart of a solution for finely controlling business by using the payer to confirm the use of dynamic codes, see Figure 3.

[0063] The process in FIG3 includes steps S302 to S306 .

[0064] S302: In response to the payment initiated by the client, the server generates or obtains a dynamic code from other service providers as the dynamic code of the payee, and prompts the client, wherein the prompt includes a personalized extension field for the product corresponding to this large-amount payment.

[0065] The prompt here is mainly to inform the payer that a dynamic code will be enabled because this is a large-value payment. However, through this interactive action, the present application further provides the payer with the ability to actively control the business, that is, through the personalized business control field mentioned above, which can be a personalized product extension field in this example. Of course, it can also be other control fields for refined personalization, for example, for automatically generating financial (or other capability) certificates based on this large-value payment, which can be directly used in other scenarios such as visas and endorsements. For example, such a control field is called a capability personalized extension field.

[0066] S304: The client receives the payer's assignment operation on the personalized extension field of the product on the client, and confirms to the server based on the assigned personalized extension field of the product, wherein the extension involves product reservation and / or product customization.

[0067] The payer can optionally assign a value to the product's personalized extension fields, making them effective for the current payment process. In this case, the client receives the payer's assignment of the product's personalized extension fields and, based on the assigned values, sends a confirmation with an additional personalization request to the server.

[0068] For the personalized extension field of goods. For example, it can be a series of goods reservation field. If the product that the payer is currently paying for is one of the series of goods, and the subsequent products will be withdrawn one after another, the payer can actively operate the series of goods reservation field when making payment, so as to conveniently realize the reservation of the subsequent goods at the same time as the payment, so as not to miss the subsequent goods easily; further, it is possible to add a product attribute customization field to the series of goods reservation field as a personalized extension field of goods, so as to pre-select the products that may be launched later in the series that meet the customization conditions (it is also possible that the products actually launched later do not meet the customized attributes, and such products will not hit the payer's reservation).

[0069] As a result, a single payment can achieve more long-term and richer effects, bring convenience to the payer, and help create business processing logic lines of different levels and granularity for large-value payments and non-large-value payments.

[0070] S306: The server continues to perform corresponding large-amount payment processing according to the payee's dynamic code and the personalized extension field of the product.

[0071] In one or more embodiments of this specification, it can be seen from the previous description that the payer can be allowed to manually enter the payment amount, thereby realizing the payer's active control over the payment process. Specifically, for example, a payment amount input page is displayed on the client to receive the payment amount entered by the payer. The payer can operate on the dial of the smart watch and enter the payment amount in the payment amount input page. The client then initiates a payment request to the corresponding server based on the received payment amount, which is limited by the payment amount (for example, equal to or less than the payment amount). Of course, the step of entering the payment amount can also be decided by the payer whether to execute it. If it is not executed, the payer does not need to operate on the dial, and the payment process is simpler and smoother, and the user experience is better.

[0072] The preceding discussion primarily focuses on enhancing security and trust from the perspective of the payer (user). In practical applications, to strengthen trust between the payer and the payee, the risks posed by possible anomalies on the payer's side also need to be considered. Based on this consideration, one or more embodiments of this specification also provide a flow chart illustrating a scheme for reliability control of the actual payment amount, thereby simultaneously protecting the interests of both the payer and the payee and strengthening trust between them. See Figure 4 , which can be implemented in conjunction with the process in Figure 1 .

[0073] The process in FIG4 includes steps S402 to S410 .

[0074] S402: The mobile device where the client is located is close to the near-field wireless communication tag, and reads the amount to be paid written by the payee in the near-field wireless communication tag.

[0075] The amount to be paid can be written immediately or pre-written. For example, the amount corresponding to one or more products can be written, and when reading, the user can select the product or quantity through the client or manual operation. Without requiring the user to perform such additional operations, this latter method is particularly suitable for scenarios where the amount to be paid is fixed, such as selling a single product such as tickets.

[0076] When executing the above-mentioned step of triggering the payment application server to obtain and perform corresponding large-amount payment processing according to the dynamic code of the payee, the following steps can be additionally performed.

[0077] S404: Displaying a payment amount related page to receive the payment amount entered or confirmed by the payer on the payment amount related page.

[0078] The amount to be paid is the amount agreed upon by the user as the payee, and the amount to be paid is the amount agreed upon by the payer. This provides both parties with a means to actively control the amount so that they can reach an agreement later.

[0079] S406: Obtain the amount to be paid determined by the mobile device through the reading.

[0080] S408: Determine whether the payment amount received from the payer is not less than the amount to be paid.

[0081] If the two amounts are equal, both parties have reached an agreement and can proceed with the payment. If the two amounts are greater, the payee may have entered the payment amount incorrectly. In this case, a corresponding reminder can be issued to facilitate further verification by the payee to avoid loss of interest.

[0082] S410: If yes, initiate a payment subject to the amount to be paid to the server of the payment application, so that the actual payment amount of the payer one or more times is equal to the amount to be paid.

[0083] If the payment amount received is less than the amount to be paid (it may be an operational error by the payer or the payee), the payee may lose the interests. In this case, the payer can be prompted to make corrections before initiating the payment request. Alternatively, an additional payment service for the difference between the payment amount and the amount to be paid can be initiated for the payer. After the payer confirms (for example, simply inquire with the payee and then confirm), the payment is processed. The payer has made payments multiple times, so that the payment service caused by the payer's operational error can also be split and processed normally without rolling back the service. This helps reduce the risk of misunderstandings and conflicts between the two parties and has a higher tolerance for possible operational errors on both sides.

[0084] According to the above description, more intuitively, one or more embodiments of this specification further provide a schematic diagram of an application scenario of the method of FIG. 1 , see FIG. 5 .

[0085] In the application scenario shown in Figure 5, the user acts as the payer and the merchant acts as the payee. The merchant provides its own QR code for payment and also provides a corresponding NFC tag for nearby deployment, for example, by attaching it to the QR code sign without obstructing the QR code. Users can optionally use a wearable device such as a smartwatch to trigger the use of a dynamic code through NFC communication based on the NFC tag to make large payments without relying on the QR code for payment. Other users who do not have such wearable devices can use a smartphone to scan the QR code for payment. In this case, large payments may not be supported or may require relatively complex operations for the user to make large payments.

[0086] Furthermore, one or more embodiments of this specification also provide flowcharts of large-amount payment solutions for one sub-scenario and another sub-scenario under the main scenario of Figure 5, see Figures 6 and 7 respectively. Assume that the wearable device is specifically a smart watch.

[0087] In the detailed scenario of Figure 6, the code pre-written into the merchant's NFC tag is the merchant's static code, and the dynamic code is actively obtained by the server and does not need to be exposed to the client. The process in Figure 6 includes the following steps:

[0088] The user activates the NFC reading function on their smartwatch, which has a payment application client installed on it. When making a payment at a merchant, the user places the smartwatch near the merchant's NFC tag. The smartwatch uses its NFC reading function to read a code value (a static code) from the merchant's NFC tag. The smartwatch invokes the payment application client installed on it and provides the code value to the client. The client requests the payment application server to resolve the code value. The server resolves the code value, obtains relevant information about the merchant, and returns it to the client. The user enters a large payment amount on the client, which then causes the client to initiate payment to the server. If the server determines that a dynamic code is required for this payment, it requests a code from the merchant's system service provider and obtains the merchant's dynamic code from the merchant's system service provider (the server can also generate a dynamic code on its own). The server prompts the client to let the user know that a dynamic code will be used for this payment. The client responds to the user's confirmation operation with feedback to the server. The server then continues processing the large payment based on the dynamic code to complete the payment, synchronizes the payment result with the merchant's system service provider, and returns it to the client.

[0089] In the detailed scenario of Figure 7, the merchant's dynamic code is directly and dynamically written into the merchant's NFC tag, so that the server does not need to apply for a code from the merchant service system provider. The process in Figure 7 includes the following steps:

[0090] The merchant's code-generating device applies to the merchant's system service provider for a code, and obtains the merchant's dynamic code issued by the merchant's system service provider. The merchant's code-generating device supports NFC communication, and the dynamic code is written into the NFC dynamic tag contained in the merchant's code-generating device; the user turns on the NFC reading function of the smart watch he wears in advance, and the smart watch is installed with a payment application client; when the user makes a payment at the merchant, he places the smart watch close to the merchant's code-generating device; the smart watch uses its NFC reading function to read the code value (dynamic code) from the merchant's code-generating device; the smart watch calls up the payment application client installed on it and provides the code value to the client; the client requests the payment application server to parse the code value; the server parses the code value, obtains the merchant's relevant information, and returns it to the client; the user enters a large payment amount on the client, which in turn enables the client to initiate payment to the server; the server continues to process the large payment based on the dynamic code to complete the payment, synchronizes the payment result to the merchant's system service provider, and feeds back to the client.

[0091] Based on the same idea, one or more embodiments of this specification also provide apparatuses and devices corresponding to the above method, as shown in Figures 8 and 9. The apparatuses and devices can execute the above method and related optional solutions accordingly.

[0092] Figure 8 is a structural diagram of a payment device provided by one or more embodiments of this specification, wherein the device is applied to the client of a payment application, and the device includes: an instruction receiving module 802, which receives a wake-up instruction, wherein the initiation method of the wake-up instruction includes: the mobile device where the client is located reads the short-range wireless communication tag of the payee, obtains the corresponding code value, sends the wake-up instruction to the client and provides the code value; a code value parsing module 804, which responds to the wake-up instruction and obtains relevant information of the payee according to the code value; a payment triggering module 806, which triggers the server of the payment application to obtain and perform corresponding large-amount payment processing according to the dynamic code of the payee according to the relevant information when this payment is a large-amount payment; and a result receiving module 808, which receives the payment result returned by the server.

[0093] Optionally, the near-field wireless communication tag includes: a dynamic code of the payee generated or applied for by the payee and dynamically updated and written into the near-field wireless communication tag; the payment trigger module 806 determines the dynamic code of the payee based on the reading result of the near-field wireless communication tag; and interacts with the server of the payment application based on the relevant information and the dynamic code of the payee, so that the server obtains the dynamic code of the payee and performs corresponding large-amount payment processing based on the dynamic code of the payee.

[0094] Optionally, the payment trigger module 806 initiates payment to the server of the payment application based on the relevant information, so that the server generates or applies for a dynamic code from other service providers as the dynamic code of the payee, and prompts the client; receives the corresponding confirmation of the payee on the client, and triggers the server to continue to perform corresponding large-amount payment processing according to the dynamic code of the payee based on the result of the corresponding confirmation.

[0095] In some embodiments, the prompt includes a personalized extension field of the product corresponding to this large-value payment; the payment trigger module 806 receives the payee's assignment operation on the personalized extension field of the product on the client; based on the assigned personalized extension field of the product, confirmation is made to the server so that the server performs corresponding large-value payment processing based on the personalized extension field of the product; wherein, the extension involves product reservation and / or product customization.

[0096] In some embodiments, the payment trigger module 806 displays a payment amount input page before triggering the server of the payment application to obtain and perform corresponding large-amount payment processing based on the dynamic code of the payee according to the relevant information; and receives the large payment amount entered by the payee through the payment amount input page, which is not less than the specified amount threshold, to confirm that this payment is a large-amount payment.

[0097] In some embodiments, the mobile device where the client is located reads the short-range wireless communication tag of the payee, including: the mobile device where the client is located reads the amount to be paid written by the payee in the short-range wireless communication tag; the payment trigger module 806 obtains the amount to be paid determined by the mobile device through the reading; determines whether the payment amount received from the payee is not less than the amount to be paid; if so, initiates a payment subject to the amount to be paid to the server of the payment application, so that the actual payment amount of the payee one or more times is equal to the amount to be paid.

[0098] In some embodiments, the proximity position of the near-field wireless communication tag also displays: the payment code generated by the payee based on the code value.

[0099] In some embodiments, the mobile device is a wearable device.

[0100] In some embodiments, the wearable device includes: a smart watch that does not have a camera that supports code scanning.

[0101] In some embodiments, the short-range wireless communication tag is an NFC tag.

[0102] Figure 9 is a structural diagram of a payment device provided by one or more embodiments of this specification, which is applied to a client of a payment application, and the 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 so that the at least one processor can: receive a wake-up instruction, wherein the initiation method of the wake-up instruction includes: the mobile device where the client is located reads the short-range wireless communication tag of the payee, obtains the corresponding code value, sends the wake-up instruction to the client and provides the code value; in response to the wake-up instruction, obtains relevant information of the payee according to the code value; in the case where this payment is a large-amount payment, triggers the server of the payment application to obtain and perform corresponding large-amount payment processing according to the dynamic code of the payee according to the relevant information; and receives the payment result returned by the server.

[0103] Based on the same idea, one or more embodiments of this specification also provide a non-volatile computer storage medium, storing computer-executable instructions, which are applied to the client of the payment application, and the computer-executable instructions are configured to: receive a wake-up instruction, wherein the initiation method of the wake-up instruction includes: the mobile device where the client is located reads the short-range wireless communication tag of the payee, obtains the corresponding code value, sends the wake-up instruction to the client and provides the code value; in response to the wake-up instruction, obtains the relevant information of the payee according to the code value; in the case that this payment is a large-amount payment, based on the relevant information, triggers the server of the payment application to obtain and perform corresponding large-amount payment processing according to the dynamic code of the payee; and receives the payment result returned by the server.

[0104] In the 1990s, technological improvements could be clearly distinguished as either hardware improvements (for example, improvements to circuit structures like diodes, transistors, and switches) or software improvements (improvements to process flows). However, with the advancement of technology, many process flow improvements today can now be considered direct improvements to hardware circuit structures. Designers almost always create the corresponding hardware circuit structure by programming the improved process flow into the hardware circuit. Therefore, it cannot be said that a process flow improvement cannot be implemented using hardware modules. For example, a programmable logic device (PLD), such as a field programmable gate array (FPGA), is an integrated circuit whose logical function is determined by user programming. Designers can "integrate" a digital system on a PLD by programming it themselves, without having to hire a chip manufacturer to design and manufacture a dedicated integrated circuit chip. Moreover, nowadays, instead of manually fabricating integrated circuit chips, this programming is mostly done using "logic compiler" software. This is similar to the software compiler used when developing programs. Before compilation, the original code must also be written in a specific programming language, called a hardware description language (HDL). There is not just one HDL, but many, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, RHDL (Ruby Hardware Description Language), etc. The most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art will also understand that by simply programming the method flow in one of these hardware description languages ​​and then programming it into an integrated circuit, a hardware circuit that implements the logic method flow can be easily obtained.

[0105] The controller can be implemented in any suitable manner. For example, the controller 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 Silicone Labs C8051F320. The memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also know that in addition to implementing the controller in a purely computer-readable program code format, the controller can be implemented in the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers by logically programming the method steps. Therefore, such a controller can be considered a hardware component, and the devices included therein for implementing various functions can also be considered as structures within the hardware component. Or even, the devices for implementing various functions can be considered as both software modules that implement the method and structures within the hardware component.

[0106] The systems, devices, modules, or units described in the above embodiments may be implemented by computer chips or entities, or by products having certain functions. A typical implementation device is a computer. Specifically, the computer may be, for example, a personal computer, a laptop computer, a cellular phone, a camera phone, a smartphone, a personal digital assistant, a media player, a navigation device, an email device, a game console, a tablet computer, a wearable device, or a combination of any of these devices.

[0107] For the convenience of description, the above devices are described as being divided into various units according to their functions. Of course, when implementing this specification, the functions of each unit can be implemented in the same or multiple software and / or hardware.

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

[0109] This specification is described with reference to the flowcharts and / or block diagrams of the methods, devices (systems), and computer program products according to the embodiments of this specification. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of the processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor, or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device produce a device for implementing the functions specified in one or more processes in the flowchart and / or one or more boxes in the block diagram.

[0110] It should also be noted that the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, commodity, or apparatus that includes a series of elements includes not only those elements but also other elements not explicitly listed, or includes elements inherent to such process, method, commodity, or apparatus. In the absence of further limitations, an element defined by the phrase "comprises a ..." does not exclude the presence of other identical elements in the process, method, commodity, or apparatus that includes the element.

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

[0112] The various embodiments in this specification are described in a progressive manner. Similar portions between the various embodiments can be referenced to each other, and each embodiment focuses on the differences from the other embodiments. In particular, the device, apparatus, and non-volatile computer storage medium embodiments are generally similar to the method embodiments, so their descriptions are relatively simplified. For relevant details, refer to the descriptions of the method embodiments.

[0113] The foregoing description of this specification describes specific embodiments. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims can be performed in an order different from that described in the embodiments and still achieve the desired results. Furthermore, the processes depicted in the accompanying drawings do not necessarily require the specific order shown or the sequential order to achieve the desired results. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0114] The foregoing description is merely one or more embodiments of this specification and is not intended to limit this specification. It will be apparent to those skilled in the art that various modifications and variations may be made to one or more embodiments of this specification. Any modifications, equivalent substitutions, or improvements made within the spirit and principles of one or more embodiments of this specification are intended to be within the scope of the claims of this specification.

Claims

1. A payment method, applied to a client of a payment application, comprising: A wake-up instruction is received, wherein the initiation method of the wake-up instruction includes: the mobile device where the client is located reads the short-range wireless communication tag of the payee, obtains a corresponding code value, sends the wake-up instruction to the client and provides the code value; In response to the invoking instruction, obtaining relevant information of the payee according to the code value; If the current payment is a large amount payment, the server of the payment application is triggered to obtain the dynamic code of the payee and perform corresponding large amount payment processing according to the relevant information; Receive the payment result returned by the server.

2. The method of claim 1, wherein: The near-field wireless communication tag includes: a dynamic code of the payee generated or applied for by the payee and dynamically updated and written into the near-field wireless communication tag; The triggering of the payment application server to obtain the dynamic code of the payee according to the relevant information and perform corresponding large-amount payment processing according to the dynamic code of the payee includes: Determining the dynamic code of the payee according to the reading result of the short-range wireless communication tag; According to the relevant information and the dynamic code of the payee, the server of the payment application is interacted with so that the server obtains the dynamic code of the payee and performs corresponding large-amount payment processing according to the dynamic code of the payee.

3. The method of claim 1, wherein: The triggering of the payment application server to obtain the dynamic code of the payee according to the relevant information and perform corresponding large-amount payment processing according to the dynamic code of the payee includes: Initiate payment to the server of the payment application according to the relevant information, so that the server generates or applies for a dynamic code from other service providers as the dynamic code of the payee, and prompts the client; Receive the corresponding confirmation from the payee on the client, and based on the result of the corresponding confirmation, trigger the server to continue to perform corresponding large-amount payment processing based on the dynamic code of the payee.

4. The method of claim 3, wherein: The prompt includes a personalized extension field for the commodity corresponding to the current large-amount payment; The corresponding confirmation of the payee on the client includes: receiving a value assignment operation of the payer on the client for the personalized extended field of the commodity; According to the assigned personalized extension field of the commodity, confirmation is made to the server so that the server performs corresponding large-amount payment processing according to the personalized extension field of the commodity; The extension involves product reservation and / or product customization.

5. The method of claim 1, wherein: Before triggering the server of the payment application to obtain and perform corresponding large-amount payment processing according to the dynamic code of the payee based on the relevant information, the method further includes: Display the payment amount input page; The recipient receives the large payment amount that is not less than the specified amount threshold entered by the payee through the payment amount input page to confirm that this payment is a large payment.

6. The method of claim 5, wherein: The mobile device where the client is located reads the short-range wireless communication tag of the payee, including: The mobile device where the client is located reads the amount to be paid written by the payee into the near-field wireless communication tag; The server that triggers the payment application obtains and performs corresponding large-amount payment processing according to the dynamic code of the payee, including: Obtaining the amount to be paid determined by the mobile device through the reading; Determining whether the payment amount received from the payer is not less than the amount to be paid; If the payment amount received from the payee is not less than the amount to be paid, a payment limited by the amount to be paid is initiated to the server of the payment application so that the actual payment amount of the payee once or multiple times is equal to the amount to be paid.

7. The method of claim 1, wherein: The proximity position of the near-field wireless communication tag also displays: the payment code generated by the payee according to the code value.

8. The method according to any one of claims 1 to 7, wherein: The mobile device is a wearable device.

9. The method of claim 8, wherein: The wearable device includes: a smart watch that does not have a camera that supports code scanning.

10. The method according to any one of claims 1 to 7, wherein: The short distance wireless communication tag is an NFC tag.

11. A payment device, applied to a client of a payment application, the device comprising: The instruction receiving module receives a wake-up instruction, wherein the initiation method of the wake-up instruction includes: the mobile device where the client is located reads the short-range wireless communication tag of the payee, obtains a corresponding code value, sends the wake-up instruction to the client and provides the code value; A code value parsing module, in response to the call instruction, obtains relevant information of the payee according to the code value; The payment trigger module, when the current payment is a large amount payment, triggers the server of the payment application to obtain and perform corresponding large amount payment processing according to the dynamic code of the payee according to the relevant information; The result receiving module receives the payment result returned by the server.

12. The device of claim 11, wherein: The near-field wireless communication tag includes: a dynamic code of the payee generated or applied for by the payee and dynamically updated and written into the near-field wireless communication tag; The payment trigger module determines the dynamic code of the payee according to the reading result of the short-range wireless communication tag; According to the relevant information and the dynamic code of the payee, the server of the payment application is interacted with so that the server obtains the dynamic code of the payee and performs corresponding large-amount payment processing according to the dynamic code of the payee.

13. The device of claim 11, wherein: The payment trigger module initiates payment to the server of the payment application according to the relevant information, so that the server generates or applies for a dynamic code from other service providers as the dynamic code of the payee, and prompts the client; Receive the corresponding confirmation from the payee on the client, and based on the result of the corresponding confirmation, trigger the server to continue to perform corresponding large-amount payment processing based on the dynamic code of the payee.

14. The device of claim 13, wherein: The prompt includes a personalized extension field for the commodity corresponding to the current large-amount payment; The payment trigger module receives the payer's assignment operation on the client to the personalized extension field of the commodity; According to the assigned personalized extension field of the commodity, confirmation is made to the server so that the server performs corresponding large-amount payment processing according to the personalized extension field of the commodity; The extension involves product reservation and / or product customization.

15. The device of claim 11, wherein: The payment trigger module displays a payment amount input page before triggering the server of the payment application to obtain and perform corresponding large-amount payment processing according to the dynamic code of the payee based on the relevant information; The recipient receives the large payment amount that is not less than the specified amount threshold entered by the payee through the payment amount input page to confirm that this payment is a large payment.

16. The device of claim 15, wherein: The mobile device where the client is located reads the short-range wireless communication tag of the payee, including: The mobile device where the client is located reads the amount to be paid written by the payee into the near-field wireless communication tag; The payment trigger module obtains the amount to be paid determined by the mobile device through the reading; Determining whether the payment amount received from the payer is not less than the amount to be paid; If the payment amount received from the payee is not less than the amount to be paid, a payment limited by the amount to be paid is initiated to the server of the payment application so that the actual payment amount of the payee once or multiple times is equal to the amount to be paid.

17. The device of claim 11, wherein: The proximity position of the near-field wireless communication tag also displays: the payment code generated by the payee according to the code value.

18. The device according to any one of claims 11 to 17, wherein: The mobile device is a wearable device.

19. The device of claim 18, wherein: The wearable device includes: a smart watch that does not have a camera that supports code scanning.

20. The device according to any one of claims 11 to 17, wherein: The short distance wireless communication tag is an NFC tag.

21. A payment device, applied to a client of a payment application, the device comprising: at least one processor; as well as, a memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, the instructions being executed by the at least one processor to enable the at least one processor to execute: A wake-up instruction is received, wherein the initiation method of the wake-up instruction includes: the mobile device where the client is located reads the short-range wireless communication tag of the payee, obtains a corresponding code value, sends the wake-up instruction to the client and provides the code value; In response to the invoking instruction, obtaining relevant information of the payee according to the code value; If the current payment is a large amount payment, the server of the payment application is triggered to obtain the dynamic code of the payee and perform corresponding large amount payment processing according to the relevant information; Receive the payment result returned by the server.

Images